Editor’s Note: In this Product How-To article, Kim Rowe describes how an MCU RTOS that makes use of the POSIX API can achieve the software reuse of training advantages of Linux. He uses his company’s Unisom RTOS as an example of how POSIX compliance provides a platform independent means for porting embedded apps between compliant MCU platforms.
POSIX has been the core API for most operating systems for many years, with the notable exception of Windows. During this time, the Portable Operating System for Unix (POSIX) API has been extended to include real-time and embedded system support, and this variant has gained prominence for embedded operating systems including embedded Linux.
Now, with the emergence of wireless communications communicating directly from machine to machine in what has now become known as the Internet of Things, the same trends that led to the development of POSIX as a platform independent means of porting applications indicate that it may play the same role in embedded IoTs.
How do these two sets of technologies intersect? How will the timeless POSIX API (Figure 1) influence the rapidly emerging IoT development? And how will IoT influence the slowly evolving POSIX standards?
This article addresses these key questions and provides practical examples of using POSIX APIs on microcontrollers (MCUs) and small microprocessors (MPUs) in order to evaluate the benefits and limitations of POSIX for the Internet of Things.
Embedded Linux history
Unix vendors needed a common standard for portability of applications, and the POSIX standard emerged to address problems of portability and tool incompatibility. Following this, RTOS solutions added POSIX to provide portability of applications and tap the pool of Unix programmers. Then Linux adopted the POSIX specification for Unix compatibility to get early acceptance. Starting almost from the inception of Linux, it made inroads into embedded systems.
The appeal of free source code with a proven set of APIs developed for the Unix world was attractive. Many upgrades for real-time computing were added over the years and this is how the world came to accept and focus on embedded Linux/POSIX as the solution for larger embedded systems.
Figure 1: The POSIX standards of 2003 and 2008 defined the various classes of POSIX API based operating systems. Starting from a multi-threaded kernel (PSE1), to a controller (PSE52) to a multiple process networked system (PSE53) and ending with a full blown development environment (PSE54) the standard attempted to clarify the various API sets which would meet user’s requirements.
As Linux developed in the early days, COTS hardware came to the fore to reduce staggering cost increases for dedicated hardware. The combination of embedded Linux and COTS hardware merged with various Windows applications and multicore technologies. Hypervisors came to the fore and multicore became popular with blended OS environments.
Hardware continued to get cheaper and faster making soft real-time systems addressable with bigger hardware and embedded Linux rather than traditional embedded RTOS environments Major RTOS companies switched focus from deeply embedded proprietary and POSIX offerings to embedded Linux to maintain market share. Embedded Linux was firmly established and seen as the best alternative for larger embedded systems.
RTOS solutions were targeted at smaller hard real-time systems, with some having POSIX APIs with various degrees of conformance, in part limited by the POSIX specifications of 2003 and 2008. In general, RTOS solutions were used less for hard real-time systems. Recently, powerful new MCU SoC solutions with larger memories, higher clock rates, low power consumption and directly accessed memory. It is with these MCUs that companies are developing solutions to power the Internet of things with their very low cost and high performance.
POSIX RTOS adaptation
Started as a means to standardize Unix interfaces POSIX evolved with real time interfaces and threading. The international standard POSIX standard has been adopted by virtually all operating systems in use and most real time operating systems including: ThreadX. QNX, VxWorks, Integrity, LynxOS and Unison OS.
While QNX, VxWorks, Integrity and LynxOS continued to focus on larger and larger systems with hypervisor integration. Unison evolved to support smaller devices and provide greater functionality and connectivity in a smaller footprint.
Figure 2: Comparing earlier generations of boards and MCUs of today, shows that MCUs have significantly more processing power and I/O but significantly less memory. Where the processing power of one a modern 32 bit MCU is equivalent to that of four 162boards (upper), the memory space available on a single 162board is equivalent to that on 16 MCUs (lower).
The change in ability to compute compared to available memory places a premium on applications and RTOS solutions which have tiny memory footprints and also makes processing intensive algorithms desirable. This change of compute/memory ratio coupled with the evolution of larger POSIX RTOSes towards larger virtual memory solutions explains why larger POSIX RTOSes are seldom viable on today's MCUs.
Why POSIX for MCUs and MPUs?
Today one of the major reasons to adopt MCU and small MPU POSIX RTOS solutions is that they are compatible with embedded Linux and other larger embedded RTOS products. By doing so, a single API is available to the development teams and platform based development for lines of products (lean product development) is easily achievable.
With one API you can develop one set of applications with different selectable features that run on all sizes of processors. This provides a significant risk reduction because applications are easily moved to other platforms, along with large cost and time reductions.
Reuse of software is the best way to save money on software development and time to market. For the embedded market, the cost and time is 1/10th of the cost of development. POSIX maximizes reuse. Also the uniform treatment of devices in POSIX environments (sockets and file I/O) eliminates custom device interfaces providing greater portability.
Are their costs associated with the open standard POSIX interfaces? In short, there are no performance or size penalties and programming is really unrestricted. Using proven C/C++ interfaces POSIX APIs can be used on size restricted platforms with complete functionality.
POSIX real-time limitations
The POSIX 2003 and 2008 specifications didn't anticipate the evolution of microcontrollers and the Internet of Things (IoT), where there is significant size, power and cost restrictions. As shown in Figure 1 PSE52 or PSE53 did not include the multi-threaded single process option which has evolved to include rich networking. PSE53 did not anticipate the IoT and the various protocols which it would spawn. PSE54 did not recognize that smaller systems would have shells for remote configuration, interpreters and more.
It has often been stated that when we have standards established, we don't need them. Although we have many things defined by POSIX and for larger systems these standards have been broadly adopted, for smaller systems, more work is required. As most standards, POSIX is evolving to support new user communities.
System Limitations. The challenges of POSIX and embedded Linux systems continue to be the real-time options, large memory size requirements, RAM based execution and “Size Weight and Power” or SWaP.
The real-time options in Linux have been addressed many ways. From hypervisor integration for RTOS co-existance to optimized algorithms progress has been made. Interrupt latency and jitter are still unpredictable and SRAM based execution is required, but powerful multi-core solutions help overcome limitations; but with multi-core SWaP increases.
Sizes of most embedded Linux systems exceed many Mbytes and most require 16MB minimum. In comparison, many MCU IoT products are delivered in less than 300KB. The cost and power required for these extra resources is significant even with energy harvesting and improving battery performance.
RAM-based execution is also a concern. Because the operating system must be taken from storage and moved to RAM before initialization, boot times are significant. An often used workaround is to keep an image in flash and boot the old image which improves system boot time by eliminating start up initialization. In comparison, MCUs run directly from flash eliminating the OS loading, and may optionally boot an existing image, creating a zero boot time system.
What IoT hath wrought
Started from a starting point many years ago as a collection of dedicated applications using cellular wireless connections, machine to machine communications to connect devices, these have all coalesced into what is called the Internet of Things with billons of devices making everything around us, both at home and in our workplaces, intelligent Figure 3 below compares the bandwidths of the various protocols used for IoTs. The fundamental assumptions associated with IoT applications are:
- Various wireless connections will be used
- Devices will range from tiny MCUs to high-performance systems with the emphasis on small low cost MCUs and small MPUs.
- Connections back to the cloud storage are required
Figure 3: A broad set of IoT protocols provide the two main characteristics to provide support for some segment of the IoT space. Typically a subscribe / publish service is included to support many devices with discontinuous service along with bidirectional data transfer. Leading candidates are indicated in blue.
With a large number of devices, specialized communications protocols, power consumption and memory footprint become very important. The bulk of these devices will be medium sized MCU based devices, likely mostly in the ARM Cortex M class of machines: big enough to communicate through the Internet using full security protocols, but small enough to be really inexpensive and low power.
In IoT, one of the key features is wireless communication. Many wireless protocols and many wireless gateways will be supported Wide area wireless (GPRS, 3G, LTE) and short range wireless will be offered with integrated gateways (Bluetooth 4.0, WiFi, 6loWPAN, Zigbee IP, Zigbee Pro, UHF, 802.15.4). Wireline access to the cloud will be provided for data storage and analytics. Figure 4 compares the network data rate and range of some of the protocols.
Other IOT requirements include:
- Memory footprint is critical, one size does not fit all. Some applications require a very tiny low power part while others require more processing and more memory.
- To achieve a small memory footprint, unnecessary features need to be removed and at the highest level module level modularity is a key feature to accomplish this.
- Optimization of each component or module for feature set minimization are required.
- Optimization options for each component to minimize size are required
- Security is key, but it must be integrated at the design of components, be space optimized to trade off security requirements versus space requirements, and use the current set of accepted best practices standards.
- Safety is important but this safety must be tailorable to the application in question.
- Complex technologies like virtualization are not required, these devices to not need this level of complexity.
- Technologies like multicore are rarely needed and would typically be used in larger gateways and routers to move data into the cloud.
- Discontinuous and continuous operation are required depending on the application
The complexity, time to market, requirements and development costs for these IoT devices make MCUs or small MPUs with an RTOS an ideal choice. Note that embedded Linux won't run in these environments.
Developers can get to market quickly with minimal cost with exceptional functionality using off the shelf POSIX compliant RTOS solutions. And by taking care in the choice of MCU RTOSes with regard to POSIX , a developer can achieve some of the benefits associated with a full Linux implementation, particularly software reuse and training, It maximizes software reuse and training while minimizing memory footprint size, time to market and also supports lean product development.The Internet of Things and POSIX
Larger IoT gateways anddevices can use the combination of existing POSIX APIs and the emergingIoT protocols. This may include standard Internet protocols and higherlevel protocols which offer various publish subscribe features and/ordata transmission protocols for big data collection.
Variouswireless connections can also be supported using the standard POSIXAPIs. These large nodes might use larger multi-core MPUs, Linux orlarger embedded operating systems and virtual memory.
Moredifficulties exist in the case of smaller systems because conformancewith the PSE52 specification is insufficient for implementing IoTapplications (no networking) and PSE53 requires an MMU. The provision ofa MPU to replace the MMU is required to run on a microcontroller andoften the elimination of the MPU is the most practical. Until thespecification catches up to the reality in the field, a fullimplementation of PSE52 plus features from PSE53 and PSE54 are requiredto deliver this functionality.
Another important message is thatsize matters and although POSIX is universal for most operating systems(embedded Linux or QNX for example), size constraints have beenignored. To be capable of running on small platforms, the size of thesystem is critical and to control the size of the system, modularity andoptimization is required for each piece of code (Figure 5 ).
Figure 5: Using modularity and optimization at multiple levels, system size and performance can be tuned to the application.
Modularityhappens on three levels: complete communication stacks or file systems(i.e. big pieces), driver level components (medium to small size pieces)and feature level options (medium to small pieces). With theelimination of all unnecessary components and features at all threelevels the net effect is exploiting modularity to the fullest tominimize the system size.
Optimization for each of thesecomponents is also required. By optimizing for space and/or performance,size and performance can be controlled and compile time options can beprovided to select appropriate size and performance characteristics. Inaddition, compile time options can change algorithmic implementations tofurther minimize size or maximize performance. Specific features shouldhave the capabilities to be removed through optimization settings aswell. .
To do this using POSIX APIs is achievable and bestaccomplished with up front design. Often, bloat creeps into systems andit is important to look for systems built from the ground up for minimalfootprints and tailorable performance. Total system redesign would berequired to implement this after the fact which could easily lead tofaulty behavior and highly complex implementations.
The powerconsumption of the system is also critical for some IoT applications. Tominimize power consumption, the hardware must support power down statesand the software must utilize these states whenever possible. Optionsshould be selectable programmatically to allow for dynamic powerminimization.
Secure POSIX systems are the norm. Standard ITsecurity can ensure that systems are not broken into and that data issecured. As soon as dynamic loading or interpreters are included, systemsecurity is degraded and is more difficult to ensure.
Safesystems can be built using POSIX although this generally has not beendone. Often safe systems are interpreted as those satisfying certaindevelopment standards. More powerful safe systems use design features totrap errors early and affect repair and recovery. In general this isapproach is in its infancy.
An MCU POSIX RTOS example
Anexample of a MCU RTOS that Unison fits into the POSIX and IoT world byproviding the embedded operating system and protocols necessary to buildapplications is Unison (Figure 6 ). The nano-kernel architecture (Figure 7 ) coupled with compile modularity and optimization ensure that the memory footprint can be minimized and optimized.
Inaddition, it offers a range of additional features: zero boot time,100% POSIX, I/O for broad sets of applications, wireless, security, afull suite of IoT protocols, lean product development options,modularity and optimization for size and performance tuning and simpleincremental enhancement with new protocols, I/O modules and IoTprotocols.
Figure6: Unison provides the embedded components, necessary documentation andexamples to build IoT systems using a broad set of IoT protocols andsensors.
Figure7: By using a nano-kernel approach with POSIX APIs, Unison offers thebest of all worlds for MCU and small MPU IoT applications. Modularityand optimization, incremental enhancement for new sensors and protocolsand lean product development with embedded Linux on larger multi-coreMPUs are achieved.
Unison and POSIX. Unison'sinitial release in 1987 used POSIX compliant interfaces and by 1993offered POSIX conformant interfaces for I/O and full compliance by 1995for standard I/O and multi-threading. New releases in 2007 focused onMCUs and MPUs, providing modular and tiny optimized versions for PSE51and PSE52 plus additional networking support. today, Unison 5.2.3 offersa wide set of POSIX APIs for a single process, multi-threadedenvironment with I/O (PSE52) with many networking and memory protectionfeatures from PSE53 as well as a shell and other features from PSE54.
Portinga Linux app to a POSIX RTOS. With 100% POSIX, porting can be fast andeasy. Standard API's don't require changing unless the existingapplication includes depreciated features or uses features that are notsupported. In most POSIX RTOS offerings, dealing with problems of size,multiple processes and signals are the main issues.
To deal withsize problems, rewrite and restructure to eliminate large buffers,provide more processing intensive algorithms which save memory ( forexample a hashing scheme rather than a sparse matrix ) and exploitmodularity and optimization features of the RTOS. Compile time optionscan also be used to minimize size.
To adapt to a world withoutmultiple processes is more difficult and may require significant work tostart threads instead of processes and communicate effectively. It isall doable within a few weeks for almost all applications with the timebeing application dependent. Signals can also be eliminated and thisrequires minor changes to replace signals with other POSIX calls.
Example #1: Intelligent eyewear
Shown in Figure 8 is an intelligent eyewear example. In this case, an existing Linuxapplication existed for MPU based hardware. The goal was to port thisapplication to the Unison OS for a variety of reasons including:
- Elimination of the high cost of Linux maintenance was a primary goal. Unison comes with supported releases.
- Elimination of the high complexity of Linux drivers and driver variants was also a primary goal. Unison comes with off the shelf drivers and is easily understood and enhanced with a small fraction of the complexity of Linux. Unison also has service offerings for driver augmentation and troubleshooting.
- Zero boot time was a nice to have, but not a driving factor.
Thebasic port took two person days to port the multi-threaded application.Enhancements and optimizations took another two person weeks.
Example #2: Wearable device analysis
Considerthe case of building a new wearable clothing device. One option is toimplement an Android wearable. This requires an MPU and the smallestoption is something similar to an Arm Cortex A9. In this case we get thefollowing results:
- BOM Cost – $40 (volume dependent)
- Power Consumption – very high
- Physical Size – large
- Weight – heavy (large battery)
An alternative implementation would use the Unison OS and an Arm Cortex M3 class machine.
- BOM Cost – $20 (volume dependent>
- Power Consumption – low
- Physical Size – interim size using smt medium, using BGA – tiny
- Weight – light (small battery)
Thesecond alternative offers all the software features along withsignificantly less expensive hardware. Unison OS has WiFi and Bluetoothfor connectivity, a range of IoT protocols for discontinous operationand the ability to easily and quickly integrate a broad set of sensors.The development time is less than three months using this approach.
POSIXis the leading set of operating system APIs and work well on embeddedIoT devices. By providing these standard APIs, time to market and totalcost of ownership are minimized. Software reuse is also maximized,significant rework is eliminated in many cases and training iseliminated.
For the Internet of Things (IoT), POSIX RTOSofferings for MCUs and MPUs are ideal. They significantly reduce time tomarket and total cost of ownership while matching technical requiressuch as small memory footprint, modularity, optimization, wirelesssupport and other requirements very well.
Unison OS is an MCUand MPU RTOS for IoT which has all the necessary features to portapplications from larger POSIX operating systems, embedded Linux orlarger POSIX RTOS offerings quickly and easily. Unison also fullysupports new development with a full range of IoT features for MCU andMPU development.
Kim Rowe is the founder of RoweBots ,which offers the Unison RTOS along with complete one-stop productdevelopment of Internet of Things systems to OEM developers targetingthe Internet of Everything. Kim has 30+ years of experience in systemsengineering and holds both an MBA and an MEng.Unison OS is an MCU andMPU RTOS for IoT which has all the necessary features to portapplications from larger POSIX operating systems, embedded Linux orlarger POSIX RTOS offerings quickly and easily. Unison also fullysupports new development with a full range of IoT features for MCU andMPU development.