Advertisement

POSIX in the age of IoT computing

Kim Rowe, Rowebots

June 29, 2014

Kim Rowe, RowebotsJune 29, 2014

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.


Figure 4: The figure shows the basic trade off of bandwith versus distance for various protocols. Wide areas are served with 2G/GPRS, 3G and LTE while WiFi, Bluetooth 4.0, Zigbee Pro, Zigbee IP, 6loWPAN, UHF and 802.15.4 serve more local needs.

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.

< Previous
Page 1 of 2
Next >

Loading comments...