BROWSE BY TECHNOLOGY



RTC SUPPLEMENTS


EDITORIAL

How Ever-Smaller Things Get Really Big

BY TOM WILLIAMS, EDITOR-IN-CHIEF

  • Page 1 of 1
    Bookmark and Share

Time was you could put together an embedded controller on a single board with a 32-bit microcontroller, some memory, an I/O device like a UART and a couple of lights and switches. Then it would sit there and maintain the temperature and monitor the volume of your kettle full of whatever. Today you can still develop an embedded system on a single board, some even smaller than before, but the landscape looks like a vast metropolis of functions and connectivity.

The central unit today is often more than just a multicore (most commonly, quad core) 32-bit processor. It at least includes integrated graphics and a variety of cache and other assorted on-chip memory and memory controllers. Increasingly, such central units are SoCs with additional processing units such as DSPs and often programmable logic, FPGA fabrics connected with a high-speed internal bus. There are on-chip components for system services like power management, debug interface and security. There are internal buses connecting to on-chip peripherals like PCIe, UART, SPI, USB and others. There are network interfaces like 10GB Internet. The lists go on. Wi-Fi and other connectivity abounds. Then there’s video, audio, maybe other smaller core for dedicated purposes, timers, all kinds of other I/O. The small boards themselves are loaded with memory, flash and many have interfaces for SSD. Often, a large portion of the board space is taken up simply by the connectors needed—unless there is a COM-like interface to another carrier board. Need I continue?

The other shoe to drop is of course, the software needed to even get started with development of these complex devices. At the very least, developers selecting them expect to be supplied with support libraries with proven drivers, for all on-chip peripherals and communication modes, communication between on-chip cores and basic board support utilities. That alone can be a tall order for the manufacturer. I was once interviewing a well-known silicon vendor about the introduction of one of these microcontroller-based SoC families when I asked, “What portion of your employees are software engineers?” They wouldn’t tell me.

But it is becoming increasingly incumbent on silicon companies to offer more ready-to-go development support in the form of pre-qualified operating systems, network stacks and protocols, compilers, functional algorithm libraries, In addition, such developers need access to development tool chains with editors, debuggers, profilers, analysis tools and the like in order to start adding value and win the competitive battle for time-to-market. And the trend is also growing to supply evaluation boards and/or board-based SDKs or platforms. And the pressure is also on for that semiconductor vendor to be the single point of support for all this to avoid the well-known cross finger pointing among various vendors when there is a problem—all of which contributes to frustration and adds to time-to-market. Selection of a central unit for a planned new design will rest heavily on the answers vendors can supply to questions about these issues.

The explosion of integrated functionality and the co-explosion of system and application software have been accompanied by a parallel implosion of size and power consumption. At the same time, we hardly need mention again that the nature and scope of what we refer to as embedded systems has changed radically as well with the obvious examples of tablets and smartphones but also with the explosion of all manner of mobile and connected devices—both consumer and industrial—on the Internet of Things. It is almost a natural law that software functionality expands to eventually pose a burden on existing hardware to the point where the hardware must be improved. Again, this has been and is the case for modern mobile, connected consumer and industrial devices.

These devices are in the process of coalescing on graphical user interfaces with the similarities between the user experience of iOS and Android reaching a level of commonality. As Windows 10 carves out a bigger niche in the IoT, that commonality of experience can be expected to grow (Was that Bill Gates sticking a pin in a wax doll?). It thus seems inevitable that operating systems like iOS, Android and Windows 10, along with the underlying Linux and Java capabilities offered by Android, will become dominant in the world of embedded systems and the IoT with RTOSs playing an important but subordinate role.

The performance of today’s processors has become so fast that many of what were once considered “real-time” demands can be adequately serviced by something like the present Linux kernel. For those applications and devices that still have hard and deterministic real-time requirements, an actual RTOS with interrupts and scheduling, etc., can often be assigned to one of the multiple processor cores, given its own I/O and memory and be able to operate under the veil of an OS such as Android within the context of whatever other apps are running, some of which will require these real-time services. Indeed, the world has gotten much bigger in the process of getting smaller.