How to Select the Right RTOS and Microcontroller Platform for the IoT

By Jacob Beningo

Contributed By Digi-Key's North American Editors

Developing an Internet of Things (IoT) device can be more challenging than many developers or companies realize. The very act of connecting an embedded system to the cloud dramatically increases the timing complexity for the system. An increase in timing complexity means that developers need a better way to manage how their software will decide what code should be running when. The best way to avoid writing custom schedulers or dealing with the timing at the bare metal level is to instead use a real-time operating system (RTOS) to help us manage the timing complexities.

One challenge with using an RTOS today is that many developers are coming from a bare metal environment without an operating system (OS), and selecting the right RTOS for a given application can be challenging. A quick survey of the RTOS market online would find that there are over 100 RTOSs available that developers can use that vary from open source to certified commercial RTOSs. So how does one go about selecting an RTOS and get started?

In this article, we are going to walk through how to evaluate which RTOS is best for your application and then examine development platforms from STMicroelectronics and Renesas that can be used to get started.

Factors to consider when selecting an RTOS

Real-time operating systems form the foundation on which developers build their application code. Selecting the right RTOS is critical to ensuring that the application is being built upon a sturdy and proven foundation. However, it’s often the case that RTOS selection is based on just a single parameter: cost.

While cost is an important factor to consider, it should not be the only one. A development team could easily spend ten times the cost of a commercial RTOS if they struggle to port, implement, or lack support for the RTOS that they select, not to mention the time that could be lost on a project. In general, there are eight different categories that a development team should consider when selecting an RTOS for their application. These include:

  • Legal liability and exposure
  • Performance
  • Features
  • Cost
  • Ecosystem
  • Middleware
  • RTOS vendor
  • Engineering preference

Within each category there may be several criteria that should be evaluated for each RTOS. For example, in the legal liability category, teams may want to consider the following:

  • RTOS infringement liability
  • Indemnification
  • Warranty
  • The need to have the RTOS reviewed from a legal standpoint

In the performance category, developers might consider the following:

  • Executable memory footprint
  • RAM footprint
  • Highest degree of determinism
  • Run-time efficiency

Each main category can be examined by the development and executive team to determine which criteria the RTOSs should be evaluated for. Once the criteria are set, several different RTOSs can be evaluated using a Kepner-Tregoe (KT) matrix. This is a rational model for decision making that helps gather, prioritize, and evaluate information with an emphasis on the assessment and prioritization of risk. It removes personal bias from the decision making process and helps one arrive at the best possible choice, with minimal negative consequences. Let’s examine how we can use a KT matrix to select an RTOS.

Using a KT matrix to select an RTOS

The RTOS selection KT matrix can be setup as shown in Figure 1 and Figure 2. The idea is that for each of our selection categories we identify our selection criteria and list them in a single column. We can identify a weight for each criterion that ranks how important that criterion is for us on a scale from 1 to 5, with 5 being critically important (e.g., cost) and 1 being not as important (e.g., legal liability). Columns can then be created for each member of the team to rank how important each criterion is for each RTOS under consideration. Each criterion can then be weighted, summed, and a non-biased, numerical result will be generated. The RTOS with the highest value is the RTOS that best fits the criteria.

Figure 1: The top half of the RTOS selection KT matrix. This includes evaluation of liability exposure, RTOS performance, features and cost. (Image source: Beningo Embedded Group)

Figure 2: The bottom half of the RTOS selection KT matrix, which includes evaluating the ecosystem, middleware, vendor and the business. (Image source: Beningo Embedded Group)

The examples shown in Figures 1 and 2 are quite extensive in the number of criteria that are being evaluated. This is probably beyond what most development teams would be interested in evaluating, but the number of criteria can be easily removed by setting the weight to 0 or hiding the row in the spreadsheet.

Platforms upon which to launch RTOS development

One area in which developers might struggle to evaluate an RTOS is determining whether it meets their performance and capabilities needs. In many cases a developer won’t know unless they dig deep in their evaluation and get their hands dirty by using the RTOS. It turns out that an extremely easy and inexpensive way to evaluate and test an RTOS is to leverage an existing development platform that uses it. Let’s look at a few platforms that support the popular open source FreeRTOS and Express Logic’s ThreadX operating systems.

The first platform that we will examine is STMicroelectronics’ STM32Cube platform. The STM32Cube platform supports FreeRTOS as part of STMicroelectronics’ STM32CubeMx and STM32CubeIDE development environments. These tools allow a developer to enable FreeRTOS by simply checking the FreeRTOS box, and then using a FreeRTOS configuration tool to set all the configuration values within it. This allows a developer to get up and running with FreeRTOS very quickly so they can start to evaluate its features and performance characteristics.

Within the STMicroelectronics toolchain there are many different development boards to choose from. One of the tried and true development boards that has been extremely popular over the years is the STM32F429 Discovery board (STM32F429I-DISC1) (Figure 3).

The STM32F429 is an Arm® Cortex®-M4 processor running at speeds up to 168 megahertz (MHz). The microcontroller supports 2 megabytes (Mbytes) of flash and 256 kilobytes (Kbytes) of SRAM, which is enough code and memory to develop a pretty advanced application. The development board also includes an LCD, several LEDs and expandable I/O.

Figure 3: The STM32F429I Discovery board is a low-cost development board that uses an Arm Cortex-M4 processor to provide plenty of processing power for developers looking to evaluate an RTOS. (Image source: STMicroelectronics)

For developers who are working with RTOS-based IoT edge devices that may also need to perform machine learning, the STM32F7 Discovery board (STM32F746G-DISCO) would be a better fit (Figure 4). The STM32F7 Discovery board is based on an Arm Cortex-M7 processor, which includes a cache, runs at clock speeds up to 216 MHz and includes 1 Mbyte flash and 340 Kbytes of SRAM. The development board also includes a 4.3 inch 480 x 272 pixel display, Ethernet, SD slot, USB, and microphone, and speaker connections to name a few.

Figure 4: The STM32F746G Discovery board is a low-cost development board that uses an Arm Cortex-M7 processor to allow developers to not just evaluate an RTOS, but also any machine learning inferences they may need to use on their IoT edge device. (Image source: STMicroelectronics)

One last development board that should be considered is the STM32L0 Nucleo Board (NUCLEO-L073RZ) (Figure 5). The STM32L0 Nucleo board is based on the Arm Cortex-M0+, which is designed for the lowest possible energy consumption, making it perfect for low-power, battery-operated IoT edge devices. The STM32L0 microcontroller runs at clock speeds up to 24 MHz and includes 192 Kbytes of flash and 20 Kbytes of SRAM. This is very close to the minimum characteristics anyone would want if they were to run an RTOS. The development board is bare bones, with just one user switch and an LED.

Figure 5: The NUCLEO-L073RZ STM32L0 development board is based on an Arm Cortex-M0+ processor designed to provide high performance for low-power devices. (Image source: STMicroelectronics)

The second platform that we will examine is the Renesas Synergy™ Platform. It is unique in the embedded industry in that it comes with extensive third-party software and development tools from established providers.

For example, if someone were using an STMicroelectronics development board and wanted to use Express Logic’s ThreadX RTOS with the IAR Systems Embedded Workbench compiler and development environment, they would need to approach IAR for the compiler and Express Logic for the RTOS, and purchase licenses to use them. However, if a developer purchases just a single microcontroller that is part of the Renesas Synergy Platform, they automatically get these tools and RTOS to work with, in addition to other middleware.

For developers who are looking to test ThreadX on a high-end processor, the Renesas Synergy SK-S7G2 development board (YSSKS7G2E30) is an excellent choice (Figure 6). The SK-S7G2 is based on an Arm Cortex-M4 processor that runs at 240 MHz and includes 3 Mbytes of flash and 640 Kbytes of RAM. This development board comes loaded, including an LCD, plenty of LEDs, I/O expansion, CAN, PMOD expansion, and easy access to serial ports and additional I/O.

Figure 6: The Renesas Synergy SK-S7G2 development board comes with commercial development tools that include the Express Logic ThreadX RTOS. (Image source: Renesas)

An alternative development board that can be used to test out ThreadX is the Renesas Synergy TB-S5D5 (YSTBS5D5E10) (Figure 7). The TB-S5D5 board is a low-cost development board that includes an Arm Cortex-M4 processor running at 120 MHz with 1 Mbytes of flash and 384 Kbytes of SRAM. The development board has minimal features in order to minimize cost. It includes a user button, capacitive touch, and an LED.

Figure 7: The Renesas Synergy TB-S5D5 development board provides developers with 1 Mbyte of code flash and 384 Kbytes of SRAM for testing out ThreadX. (Image source: Renesas)

Other interesting options for developers, especially those that are interested in IoT applications, are the Renesas Synergy AE-Cloud1 IoT Kit, YSAECLOUD1 (Figure 8 ), and the Renesas Synergy AE-Cloud2 Cellular IoT Kit, YSAECLOUD2 (Figure 9).

The Synergy Cloud1 IoT Kit provides developers with the ability to connect to the cloud through Wi-Fi, while the Cloud2 Cellular Kit allows the developer to also connect through a cellular network. Both development boards are based on the S5D9 processor and include onboard sensors and LEDs that can be monitored and controlled from the cloud. The kits also come with preinstalled software that includes ThreadX and allows a developer to test out an entire connectivity solution with their RTOS. (This can help a developer to evaluate the middleware section of the KT matrix discussed earlier.)

Figure 8: The Renesas Synergy AE-Cloud1 IoT Kit is a development board specifically designed for IoT devices that will connect to the cloud through Wi-Fi. It includes the ability to control LEDs and monitor sensor values from a cloud provider like Amazon Web Services (AWS) or Microsoft Azure. (Image source: Renesas)

Figure 9: The Renesas Synergy AE-Cloud2 Cellular IoT Kit is a development board designed for IoT devices that will connect to the cloud through Wi-Fi or cellular. It includes the ability to control LEDs and monitor sensor values from a cloud provider like AWS or Azure. (Image source: Renesas)

One important note on platforms: When evaluating an RTOS on one, make sure that you are performing an apples-to-apples comparison. For example, if you evaluate FreeRTOS on the STM32F429 Discovery board running at 168 MHz, make sure that you either use the same development board or one running at the same clock speed to evaluate your other RTOSs.

Tips and tricks for using an RTOS

Every RTOS has its own “tips and tricks”, but there are several rules of thumb that can be applied to RTOSs generically:

  • Statically allocate tasks and RTOS objects. Dynamically allocating tasks and objects requires the use of memory allocation (malloc()) which is non-deterministic and can cause heap fragmentation issues leading to poor performance or even system crashes in the worst case.
  • Change the default stack size based on your application needs. Many RTOSs provide a default stack value that is oversized for most tasks, which results in wasted RAM. Manually configure the default stack size but also make sure that you tune the stack size for each task based on its function and needs.
  • Functions that are called from a task should be reentrant. This ensures that if the function is called from multiple tasks there won’t be a risk for corrupting the other task’s data if it was interrupted by a higher priority task.
  • Use memory block pools if they are available. A memory block pool is a memory pool that has deterministic behavior and can be used during run-time to dynamically allocate memory. This is a better option than using malloc(), but most open source operating systems do not include this memory management capability.
  • Minimize the number of tasks used in the application. There is a temptation with an RTOS to create lots of tasks, but creating tasks that are not needed can dramatically reduce available memory due to the need for the task control block and the separate stack space associated with it.


As the IoT drives the need for increasing software complexity in embedded systems, the use of an RTOS has become a requirement in order to help developers grapple with this complexity and abstract it out. The trick however is not to select just any RTOS. Since not all RTOSs are created equal, considerable time and effort can be wasted if the RTOS is fighting the developers’ purposes.

Instead, developers need to take a proactive approach to their RTOS selection and carefully evaluate all the different aspects of not just the RTOS, but also peripheral considerations such as the RTOS vendor and the support that is available when issues are encountered. An effective approach is to start with a KT matrix to carefully evaluate RTOSs under consideration, and then run the RTOS of choice on microcontroller platforms that can fully support it to make sure it’s the right one for the application.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Jacob Beningo

Jacob Beningo is an embedded software consultant. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees, including a Masters of Engineering from the University of Michigan.

About this publisher

Digi-Key's North American Editors