One of the most important questions to ask yourself from the onset of the development of your project (or product) is the underlying operating system you intend to use, or whether you should even use one. The answer to this question ends up defining a number of aspects of your project, or it forces you to answer questions that you may not even have considered. Deciding on whether to use Linux or an RTOS, or whether to conduct development on bare-metal will directly impact hardware selection, specifically the CPU. Your CPU will be quite different if you were to go with Linux than if you were to choose an RTOS or do bare-metal development on your own. Also, choosing Linux over an RTOS or bare-metal may directly impact your toolchain setup. Sometimes, a microprocessor that supports Linux isn’t the barebones CPU specifically developed by the manufacturer. Instead, auxiliary components such as a power manager, a memory management unit (if not already present on the CPU), and any wireless peripherals (integrated WiFi/Bluetooth) are augmented by another vendor to form a System on Module (SOM) or System on Chip (SOC). These vendors then have their own toolchains that form the Board Support Package (BSP), which your team will need to get comfortable with in understanding and modifying to suit your needs.
How do you go about determining whether you should use Linux, an RTOS, or bare-metal development? While the answer is not entirely straightforward, you can ask yourself a few questions to assist your selection.
First, does your application have strict timing restrictions? If yes, then you generally can’t use Linux. While Linux is great at handling interrupts in a timely manner and does offer support for interfacing with a myriad of different hardware peripherals, it does not guarantee that any particular task (or process, in Linux-terms) will be executed in a deterministic amount of time. Therefore, your options are limited to using an RTOS or bare-metal. How do you decide between using an RTOS or bare-metal? If you have more than one task that’s running, which you generally will in any meaningful application, then you should go with an RTOS. An RTOS provides the necessary infrastructure to support different tasks and ensures that they will be complete in a deterministic amount of time. You don’t have to worry about writing your own pre-emptive scheduler since an RTOS provides a well-tested and mature scheduler for you. While some may argue that an RTOS takes up additional space in Flash and RAM to store and execute the RTOS, the overhead is minimal (see figure below for a comparison). However, if you have such strict timing requirements that even the variability, albeit minimal, that an RTOS provides is not suitable for your application, then you are better served implementing your application in bare-metal. Additionally, if you are using a processor or microcontroller that is relatively new to the market and an RTOS hasn’t been targeted for your microprocessor/controller, you may be better off writing your application in bare-metal.
What if your application doesn’t have strict timing requirements? Then, the second question you need to ask yourself is what stage are you in your project? Is it a prototype, or are you ready to begin mass production? If it’s the former, then you’re not really worried about cost and are looking to simply prove out your concept and implementation. In that case, you’re better off purchasing an inexpensive single board controller (SBC) that supports Linux, such as a Raspberry Pi. However, if you’ve already proven out your idea and are ready to enter mass production, your investors (or accountants) may not be happy with the $5 cost that the Raspberry Pi Zero will contribute towards the bill of materials (BOM). In that case, you’re better off choosing a cheaper microcontroller and running an RTOS. While the initial implementation cost will be high, you’ll be able to offset that cost with the high margins when you sell your product. Remember, Linux has a relatively high memory footprint when compared to an RTOS or a bare-metal implementation. If you’re going to run Linux on a CPU, you’ll need to select one that has enough Flash and RAM to store and execute Linux as well as your application. The memory footprint between bare-metal, RTOS, and Linux can be captured in the following figure.
Finally, will you need to support a shell into your device for in-field debugging? Or will you need support login by multiple users? If so, then you’re better off using Linux. While there do exist shell implementations of different RTOSes, if a mature shell (such as Bash) or multiple user support is high on your list of requirements, then you’re better off using the mature and well-tested utilities that are offered by Linux. Also, if you need a network stack or support for different wireless interfaces, then you’re better off using Linux over an RTOS or develop in bare-metal. While network stacks and hardware drivers do exist for different RTOSes, they usually incur an additional cost; these come bundled with Linux.
In summary, you should be asking yourself these questions in this particular order. If your application has strict requirements, then you should use an RTOS. If the minimal variability in timing or the minimal overhead that an RTOS provides is not tolerable for your application, or the processor or microcontroller you’re using is relatively new, then you will need to implement your application in bare-metal. If you don’t have strict requirements, but you’re required to minimize your BOM cost, then you will need to select a microcontroller or microprocessor that generally can’t support Linux without significant effort. In that case, you will need to use an RTOS or implement your application in bare-metal. Finally, if you don’t have timing requirements and the BOM cost is not of concern to you, then you’re better of using Linux. Linux offers many well-tested and mature drivers and utilities out-of-the box and across different packages that will ease the implementation of your application.
For further assistance on whether you should target Linux, an RTOS, or conduct development in bare-metal, please schedule a conversation at http://mab-labs.com/contact/.