There comes a time in every development cycle when you must choose the foundation on which your software will be built. While there are many options, they typically fall into three categories: bare metal, real-time operating systems (RTOS), or general-purpose operation systems (GPOS).
Bare metal systems don’t use an operating system. Instead, the application code runs directly on the hardware without operating system support. Your code interacts with and accesses hardware directly.
An RTOS operating system is designed to serve real-time applications that provide predictable execution times and time-sensitive applications. Their key characteristics are responsiveness and determinism.
A GPOS is designed to run a wide range of software applications. These operating systems are characterized by their user-friendly interfaces and the broad spectrum of services they provide. Examples of GPOS include Windows, Linux, and MacOS.
The foundation you choose for your electronic system can have dire consequences for cost, time-to-market, and even quality. Let’s look at how to choose between bare metal, RTOS, and GPOS.
When to choose bare metal
Bare-metal solutions work well when the processor hardware is resource-constrained. Constrained resources include processor bus width, RAM, FLASH, and processor speed. For example, you’ll find little support for an RTOS on 8-bit and 16-bit microcontrollers. You’ll also find that few operating systems fit within 32 kilobytes of flash space or on processors with only 2 kilobytes of RAM.
Resource constraints aren’t the only consideration for choosing bare metal. You may also want to select a bare-metal solution if your system has highly constrained real-time requirements. Operating systems often have overhead associated with their kernel that can cause jitter and delays in response times. Direct access to the hardware can help you manage timing and determinism while ensuring low latency.
Bare-metal solutions are best for low-end microcontroller-based systems that are disconnected systems with strict real-time requirements.
When to choose an RTOS
An RTOS is a great solution when your available hardware is not resource-constrained. These include hardware systems like 32-bit microcontrollers and low-end application processors. To use an RTOS, your system should have at least 64 kilobytes of flash memory, 4 kilobytes of RAM, and a processor clock of 80 MHz or above. While you may be able to get away with less, you will spend more time fighting the RTOS and hardware than developing your application.
An RTOS is typically used for systems with more complex timing requirements than bare-metal systems. These systems often need to manage real-time requirements while handling communication stacks like TCP/IP, MQTT, USB, Wi-Fi, etc. While it may be possible to develop these types of systems using bare-metal solutions, having an RTOS simplifies the design, accelerates time to market, and makes software maintenance easier.
Another critical aspect of an RTOS is the capabilities the operating system adds to software development, such as task management, task synchronization, scheduling, and intertask communication. An RTOS can allow you to prioritize tasks that can preempt each other, allowing far more sophisticated application design.
RTOS solutions are best for mid to high-performance microcontrollers and low-end application processors where high reliability and timing are essential.
When to choose GPOS
A general-purpose operating system fits well when you have an application processor or full microprocessor available. When you look at a GPOS, you will most likely be using some flavor of embedded Linux. The hardware will typically be a 32-bit application processor running at bus speeds of 200 MHz or greater with megabytes of memory storage and RAM, if not gigabytes.
A GPOS is an excellent solution for complex applications with less critical timing and determinism. A GPOS often provides a wide range of services, such as user-friendly interfaces, communication stacks, ease of software updates, etc. These features can help you better manage the system without knowledge or expertise in the underlying hardware. They also tend to be easier to set up and manage. More developers have domain knowledge in GPOS, but the electronics are often much more expensive than microcontroller solutions.
GPOS solutions are best for applications and microprocessors where determinism and system timing aren’t critical.
Conclusions
When choosing the foundation for your electronic system, you’ll find that three general solutions are available: bare metal, RTOS, and GPOS. The best solution depends on the hardware you have available, the reliability you want, and the timing requirements of the system. In some cases, you may find that more than one would fit. In those cases, you must consider your development costs and the long-term maintenance and support.
Don’t forget to consider the scalability of your system and its potential for future expansion. Systems that may need to evolve, accommodating more complex features or additional hardware, might be better served by an OS that can handle such growth. Finally, consider the community and vendor support available for each option, as this can significantly impact your ability to troubleshoot, update, and secure your system over its lifecycle.
