Many larger microprocessor (MPU) designs are built using embedded Linux. Real-time operating systems (RTOSes) are used only in cases where hard real-time performance is required. Regardless of the MPU operating system – either embedded Linux or an MPU RTOS – all use POSIX as the standard for application programming interface (API) calls. Larger operating systems such as Windows and desktop Linux also support these same API calls.
Microcontrollers (MCUs) have reached the point where most are capable of running an operating system, but none can run Linux, Linux variants, or Windows due to the resources required. The developers of small MPU and MCU systems have no choice but to run bare metal or run an RTOS because they can't run Linux. This article discusses the various options I use for MCU RTOS selection and the criteria by which this selection might be made.
The first choice to be made is whether the application needs a full RTOS or just the kernel component. A kernel is not an RTOS, but this can be a confusing issue because of the inappropriate naming chosen for some popular kernels, ‘freeRTOS’ for example.
An RTOS includes the kernel component, which provides scheduling, communication and synchronization, timers, and interrupt handling. In addition, the RTOS provides an I/O mechanism, which presumably offers uniform access to devices, software stacks for a broad set of connectivity options, file systems, display options, off the shelf examples, documentation, and tools for debugging applications running on the RTOS. Table 1 shows how some of the popular RTOSes rate in terms of virtual memory support.
From this table we can see that the MCU OS versions will run on an MPU but do not support virtual memory. All MCU OS variants support memory protection units and may use the MMU for protection on larger processors.
One of the big issues for development in larger companies is the ability to preserve your investment in applications software. This is done with platform-based development or lean product development, with POSIX as the single standard common API for all larger operating systems. With the rise of embedded Linux, and all MPU RTOSs with virtual memory (VM) supporting this standard, this means that POSIX is the API or platform of choice, making it easier to preserve investment in applications software. It provides software reuse, risk reduction, and great flexibility and portability, and allows non-embedded engineers to easily program MCUs,.
For MCU and small MPU operating system offerings, POSIX APIs can extend this software and knowledge reuse into the MCU, MPU, and FPGA area. This approach has been successfully used by some, but more often than not this is a marketing response. Actual functionality that is operational as a layer resting on top of another kernel is often incomplete and defective. More details are provided in the tables I have included the end of this article. The tables compares the various RTOS offerings by some of the criteria discussed here: modularity, time to market, platform type, I/O limitations, Internet Protocol support, USB support, memory size required, and security, among others.
Modularity is key in environments with limited resources. To be able to easily include or exclude modules is important to control size. Along with this comes a modular boot sequence so that the startup sequencing can be controlled and the developer has a means to provide “instant on” capabilities even if there is still initialization happening in the background.
Another significant issue is time to market . By purchasing components, the risk can be reduced and the time to market significantly reduced. Sometimes free components are available but often ‘free’ is not really free. Integration and testing time is 50% of a typical software project, so integrating disparate components can be expensive even if individual components are free. For this reason, it is best to get off the shelf components or components that can be very easily adapted. Not only today's components should be considered, but be sure there is a roadmap going forward so that you can evolve your product without risk of expensive development.
Another aspect of application development is platform selection and it too is tied to time to market. By choosing a standard API like POSIX there is a wealth of benefits that can substantially reduce time to market as well as minimize total cost of ownership for ongoing development efforts. POSIX increases quality because the extensive set of tests can be used and because they were written by a diverse set of people, and not biased by an individual developer.
Limitations to the I/O models are common. Ideally a unified POSIX I/O model is best because it offers greater portability and a univeral means to do I/O. When I/O models are trying to follow a standard but are not unified, problems occur and unexpected behavior results, which leads to development delays and latent defects. This is one of the issues with POSIX layers.
Given that you should purchase components to reduce time-to-market and that standards-based offerings are desirable, making sure that the environment you choose has a proven set of protcols for Internet connectivity is key. The trend today is towards the Internet of Things (IoT) or Machine to Machine (M2M) communication. To make sure that you can address product requirements not only now but in the future in this area, and be sure that the basic and advanced Internet protocols are off the shelf.
The most common protocol for microcontrollers over the past few years has been USB. Your device may not need it today but it is very possible that it will be a future requirement.
For several reasons, size is a major consideration when considering an MCU RTOS or a small MPU RTOS. First the program must fit in the MCU. If it doesn't, slower, expensive external memory is required. This size criteria applies to program memory, initialized variables (in Flash and RAM), and program RAM, which contains stacks and the heap for the system. Smaller sizes with the same features minimize bill of materials (BOM) costs and improve product margins. Implementation sizes sometimes vary dramatically when comparing identical features.
Your system might not need security today but certainly will need it in some future version. It is best to be prepared. Internet connections typically are secured by TLS today (SSL v3 is obsolete). Virtual private networks (VPNs) are sometimes used but are difficult to setup, and use IPsec as part of the network stack. Remote access via SSH is common as is secure file transfer. SNMP has a security option v3 protocol, and if doing large Internet-based deployments it will likely be necessary. One of the biggest vulnerabilities is remote field service – secure boot is a must have if you are going to provide this ability to your customers.
How to use the Comparison Tables
The tables below compare the various offerings. The data in these tables is derived from the vendors’ web sites and by asking questions of the vendors as part of new product development. The criteria were broadened to cover aspects that were not specific to the product being constructed to ensure relevance to a broad set of developers.
Cost is an important consideration in these decisions. Given the variability in the costing a very rough estimate is provided but it is recommended that precise costing be obtained from the vendors as prices will vary.
The comparison tables do not include many new protocols and services required for Internet of Things (IoT) or Machine to Machine (M2M) communication systems. They are generally not well represented in MCU environments.
The criteria used to complete the tables are as follow:
- If a vendor offers the module and it is produced by them, it is recorded as a ‘yes’.
- If a vendor offers the module directly and it is produced by a third party, it is a 3rd party offering.
- If a vendor offers a module and it is some subset of what users would normally expect, it is recorded with the specific subset indicated. For example, most security packages include SSL/TLS, SSH and SFTP, but if only SSL is available then it is recorded as SSL only.
- If the vendor does not offer the module it is blank.
- Any modules that are special release options are recorded as ‘factory’.
- If an item is a roadmap item avalable within 3 months, it is recorded as a ‘yes’ if it is on schedule.
- If an item is going to be available in 3-12 months it is recorded as a roadmap item.
- Modules which will be available beyond 12 months are recorded as blank.
Some fields have many options, more detailed investigation may be required to resolve all the various options.Some features are claimed by vendors but did not match our experiencewith the product. In the case of a conflict our judgement of the featurewas used (i.e., modularity claimed but poor in our experience).
Fromthese tables, you can compare to see if the vendors have what you neednow and what you need in the future, either as an offering now or as aroadmap item. All the data in the table was updated for October 31,2013. If you wish to add other vendors, this table should be suitablefor the comparison.
Sergey Kolesnik has spent more than 20 years developing embedded systems and softwarefor a broad set of devices in industrial automation, smart cards,telecommunications, Internet systems, energy metering and more. Sergeygraduated from the Polytechnic University, Odessa, UKR with anEE-Electrical Drives and Industrial Automation. Sergey is currently themanager of the Microprogramming Department at Telecard-Pribor Ltd. Hecan be contacted at or .