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 system (RTOS), or general purpose operation system (GPOS).
Bare metal systems don’t use an operating system. Instead, the application code runs directly on the hardware without operating system support. In this case, your code would directly interact with and access hardware.
An RTOS operating system is designed to serve real-time applications that provide predictable execution times, and time-sensitive applications. Their key characteristic is 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 on costs, 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 (MCUs). You’ll also find that few operating systems can fit within 32KB of flash space or on processors with only 2KB 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 chosen for low-end, MCU-based, disconnected systems.
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 MCUs or low-end application processors. To use an RTOS, your system should have at least 64KB of flash, 4KB of RAM, and a processor clock of 80MHz or above. While you may be able to get away with less, you’ll find that you 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, and so forth. While it may be possible to develop these types of systems using bare metal solutions, having an RTOS will simplify the design, accelerate time-to-market, and make software maintenance easier.
Another critical aspect of an RTOS is the capabilities they add 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 chosen for mid- to high-performance MCUs and low-end application processors where high reliability and timing are essential.
When to choose GPOS
A GPOS fits well when you have an application processor or full-blown microprocessor (MPU) available. When you look at a GPOS, you will most likely be using some flavor of embedded Linux. The hardware will typically be some 32-bit application processor running at bus speeds of 200MHz or above, 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, and so on. These features can help you better manage the system without having 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 MCU solutions.
GPOS solutions are best for applications and MPUs where determinism and system timing aren’t critical.
Conclusion
When choosing the foundation for your electronic system, you’ll find that just three general solutions are available: bare metal, RTOS, and GPOS. Which solution you use 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.
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • FEBRUARY 2024 #403 – Get a PDF of the issue
Sponsor this Article
