Picking a portable Internet of Things operating system
Hardware/software architectures of the cloud and datacenter are well defined, so much so that “Wintel” and “Lintel” (Windows/Intel and Linux/Intel) became common jargon in networking circles in the middle part of the 2000s. This makes you wonder if an IoTopia can exist where common operating systems run as seamlessly on sensor modules as network servers. This level of portability sure would uncomplicate things.
Of course, in embedded we know this can’t be the case. Outside of the large number of microcontroller vendors and hardware architectures that serve the embedded market, running a full-blown OS on these devices is impractical if not impossible in most cases. Typical Microsoft or Linux OSs require tens or hundreds of megabytes of RAM. Some high-end ARM MCUs can support these footprints by storing an image in large NAND drives and copying it to DDR at bootup, but this is a departure (and not an inexpensive one) from traditional approaches whereby the image is stored and run directly from a processor’s internal memory or external NOR.
So there go my hopes of running Debian on an 8-bit stepper motor.
But what about a bottom up approach? For years, real-time operating system (RTOS) vendors have become adept at stripping unnecessary code and functionality from their base kernels for the most limited of systems, while also maintaining the ability to add on communications stacks, file systems, GUIs, and other libraries in an a la carte fashion. This modular design concept is behind, which is still being prepped for primetime, but also the foundation of solutions on the market such as Micro Digital’s and the Micrium and real-time kernels.
A typical real-time kernel ranges from 2 – 24 KB in size. But to be fair in our assessment, we should consider that even IoT edge devices will require connectivity, which can eat up a considerable amount of code space. Let’s weigh the impact in a build example provided by David Moore, Vice President and Director of Development at Micro Digital, in which he compiled the SMX kernel and a basic TCP/IP networking stack on the ARM Cortex-M4 MCU from STMicroelectronics, and ran them from internal processor memory.
SMX kernel, TCP/IP stack (for STM32F407)
Code: 70 KB -> 50KB
Data: 40 KB -> 30KB
The ranges provided in the above are to account for possible tuning. For example, demo code and some other additional options can be shut off to reduce code size, and the number and size of Ethernet frame buffers can be reduced to minimize the data footprint. Extra space is also consumed by heap, event buffers, etc., so all in all the code and data packages can probably be reduced to around 50 KB and 30 KB, respectively. This is compact enough to accommodate most small IoT devices.
On the higher end of the spectrum, David also compiled a larger release that included TCP/IP, Wi-Fi, USB host/device, file system, and GUI stacks in addition to the kernel on the ARM Cortex-M7 MCU, which together represent the functionality of a high-end IoT gateway. The results were:
SMX kernel, TCP/IP, WiFi, USB host, USB device, file system, GUI (for STM32F746)
Code: 300 KB
Data: 200 KB (not including LCD frame buffer)
With the exception of the GUI, whose frame buffer is located in external RAM, all of this runs from the STM32F746’s internal memory. By comparison with Linux and Windows OSs, both of the described RTOS implementations are tiny.
What’s in it for me (and IoT)?
If you get where I’m going with this, it’s much easier to scale up an RTOS than scale down general-purpose operating systems, which are limited to running on application processors. SMX RTOS, for instance, supports devices from low-end Cortex-M MCUs to high-performance Cortex-A-class application processors, all on the same codebase.
The benefit here for IoT developers is twofold in that not only can code be reused across different tiers of IoT systems, but it also precludes development teams from having to support additional OS environments. As Christian Legare, Executive Vice President of Micrium explained while discussing a healthcare IoT system that uses his company’s modular µC/OS in sensors, gateways, and a centralized database, this can have a big fiscal impact on IoT producers and consumers.
“The problem customers are facing is that if they go bare metal in a sensor and then a small RTOS in an intelligent sensor and then a more complete RTOS in a concentrator and then Linux in a gateway, it means the learning curve and maintenance for all of this software is tremendous,” Legare said. “Even if it’s open source and the source code is accessible, the development, the integration, the enhancement, the maintenance, etc., is a huge cost. If they can standardize on one software platform that can work on all of these IoT devices, then it’s a huge cost savings.
“If you want to have an operating system, real time or not, fit the spectrum of devices from intelligent sensors up to gateways and other concentrators on the cloud, you can’t do it with a single, monolithic OS. Linux and other OSs won’t fit,” he continued. “This is why you need a modular RTOS: So you can use only what you need for sensors, then move up to gateways and concentrators and be able to add the additional features that you need.”
The issue of scalability also directly relates to portability. Beyond the high-level architectural distinctions between ARM and Intel platforms being addressed by mbed and, for example, different chipset vendors developing with the same architecture often take different design approaches, especially as it relates to peripherals. To pick on Ethernet controllers, ask NXP, STMicroelectronics, Atmel, Microchip, Texas Instruments, and Xilinx how they implement theirs, and you might get six different answers.
It’s the duty of an IoT OS to abstract these differences in processor class and architecture, so when picking one, make sure it’s modular and ubiquitous.
Available processor ports for SMX RTOS and µC/OS can be found on theand websites.