POSIX in the age of IoT computing

Kim Rowe, Rowebots

June 29, 2014

Kim Rowe, RowebotsJune 29, 2014

The Internet of Things and POSIX
Larger IoT gateways and devices can use the combination of existing POSIX APIs and the emerging IoT protocols. This may include standard Internet protocols and higher level protocols which offer various publish subscribe features and/or data transmission protocols for big data collection.

Various wireless connections can also be supported using the standard POSIX APIs. These large nodes might use larger multi-core MPUs, Linux or larger embedded operating systems and virtual memory.

More difficulties exist in the case of smaller systems because conformance with the PSE52 specification is insufficient for implementing IoT applications (no networking) and PSE53 requires an MMU. The provision of a MPU to replace the MMU is required to run on a microcontroller and often the elimination of the MPU is the most practical. Until the specification catches up to the reality in the field, a full implementation of PSE52 plus features from PSE53 and PSE54 are required to deliver this functionality.

Another important message is that size matters and although POSIX is universal for most operating systems (embedded Linux or QNX for example), size constraints have been ignored. To be capable of running on small platforms, the size of the system is critical and to control the size of the system, modularity and optimization 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.

Modularity happens 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 the elimination of all unnecessary components and features at all three levels the net effect is exploiting modularity to the fullest to minimize the system size.

Optimization for each of these components is also required. By optimizing for space and/or performance, size and performance can be controlled and compile time options can be provided to select appropriate size and performance characteristics. In addition, compile time options can change algorithmic implementations to further minimize size or maximize performance. Specific features should have the capabilities to be removed through optimization settings as well. .

To do this using POSIX APIs is achievable and best accomplished with up front design. Often, bloat creeps into systems and it is important to look for systems built from the ground up for minimal footprints and tailorable performance. Total system redesign would be required to implement this after the fact which could easily lead to faulty behavior and highly complex implementations.

The power consumption of the system is also critical for some IoT applications. To minimize power consumption, the hardware must support power down states and the software must utilize these states whenever possible. Options should be selectable programmatically to allow for dynamic power minimization.

Secure POSIX systems are the norm. Standard IT security can ensure that systems are not broken into and that data is secured. As soon as dynamic loading or interpreters are included, system security is degraded and is more difficult to ensure.

Safe systems can be built using POSIX although this generally has not been done. Often safe systems are interpreted as those satisfying certain development standards. More powerful safe systems use design features to trap errors early and affect repair and recovery. In general this is approach is in its infancy.

An example of a MCU RTOS that Unison fits into the POSIX and IoT world by providing the embedded operating system and protocols necessary to build applications 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.

In addition, it offers a range of additional features: zero boot time, 100% POSIX, I/O for broad sets of applications, wireless, security, a full suite of IoT protocols, lean product development options, modularity and optimization for size and performance tuning and simple incremental enhancement with new protocols, I/O modules and IoT protocols.

Figure 6: Unison provides the embedded components, necessary documentation and examples to build IoT systems using a broad set of IoT protocols and sensors.

Figure 7: By using a nano-kernel approach with POSIX APIs, Unison offers the best of all worlds for MCU and small MPU IoT applications. Modularity and optimization, incremental enhancement for new sensors and protocols and lean product development with embedded Linux on larger multi-core MPUs are achieved.

Unison and POSIX. Unison's initial release in 1987 used POSIX compliant interfaces and by 1993 offered POSIX conformant interfaces for I/O and full compliance by 1995 for standard I/O and multi-threading. New releases in 2007 focused on MCUs and MPUs, providing modular and tiny optimized versions for PSE51 and PSE52 plus additional networking support. today, Unison 5.2.3 offers a wide set of POSIX APIs for a single process, multi-threaded environment with I/O (PSE52) with many networking and memory protection features from PSE53 as well as a shell and other features from PSE54.

Porting a Linux app to a POSIX RTOS. With 100% POSIX, porting can be fast and easy. Standard API's don't require changing unless the existing application includes depreciated features or uses features that are not supported. In most POSIX RTOS offerings, dealing with problems of size, multiple processes and signals are the main issues.

To deal with size problems, rewrite and restructure to eliminate large buffers, provide more processing intensive algorithms which save memory ( for example a hashing scheme rather than a sparse matrix ) and exploit modularity and optimization features of the RTOS. Compile time options can also be used to minimize size.

To adapt to a world without multiple processes is more difficult and may require significant work to start threads instead of processes and communicate effectively. It is all doable within a few weeks for almost all applications with the time being application dependent. Signals can also be eliminated and this requires 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 Linux application existed for MPU based hardware. The goal was to port this application 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.

The basic port took two person days to port the multi-threaded application. Enhancements and optimizations took another two person weeks.

Figure 8: Esight's Intelligent Eyewear is helping blind people see.

Example #2: Wearable device analysis
Consider the case of building a new wearable clothing device. One option is to implement an Android wearable. This requires an MPU and the smallest option is something similar to an Arm Cortex A9. In this case we get the following 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)

The second alternative offers all the software features along with significantly less expensive hardware. Unison OS has WiFi and Bluetooth for connectivity, a range of IoT protocols for discontinous operation and the ability to easily and quickly integrate a broad set of sensors. The development time is less than three months using this approach.

POSIX is the leading set of operating system APIs and work well on embedded IoT devices. By providing these standard APIs, time to market and total cost of ownership are minimized. Software reuse is also maximized, significant rework is eliminated in many cases and training is eliminated.

For the Internet of Things (IoT), POSIX RTOS offerings for MCUs and MPUs are ideal. They significantly reduce time to market and total cost of ownership while matching technical requires such as small memory footprint, modularity, optimization, wireless support and other requirements very well.

Unison OS is an MCU and MPU RTOS for IoT which has all the necessary features to port applications from larger POSIX operating systems, embedded Linux or larger POSIX RTOS offerings quickly and easily. Unison also fully supports new development with a full range of IoT features for MCU and MPU development.

Kim Rowe is the founder of RoweBots, which offers the Unison RTOS along with complete one-stop product development of Internet of Things systems to OEM developers targeting the Internet of Everything. Kim has 30+ years of experience in systems engineering and holds both an MBA and an MEng.Unison OS is an MCU and MPU RTOS for IoT which has all the necessary features to port applications from larger POSIX operating systems, embedded Linux or larger POSIX RTOS offerings quickly and easily. Unison also fully supports new development with a full range of IoT features for MCU and MPU development.

< Previous
Page 2 of 2
Next >

Loading comments...