Choosing an RTOS
Occasionally, when someone first learns of the term real-time OS, they mistakenly believe that an RTOS is the only way to achieve real-time behavior in an embedded system. While this is certainly understandable (especially given the name), it couldn’t be further from the truth. Sometimes, it is best to think of an RTOS as a potential solution, rather than the solution to be used for everything. Generally speaking, for an MCU-based RTOS to be the ideal solution for a given problem, it needs to have a Goldilocks-level of complexity—not too simple, but not too complicated.
If there is an extremely simple problem, such as monitoring two states and triggering an alert when they are both present, the solution could be a straightforward hardware solution (such as an AND gate). In this case, there may be no reason to complicate things further, since the AND gate solution is going to be very fast, with high determinism and extreme reliability. It will also require very little time for development.
Now, consider a case where there are only one or two tasks to be performed, such as controlling the speed of a motor and watching an encoder to ensure the correct distance is traversed. This could certainly be implemented in discrete analog and digital hardware, but having a configurable distance would add some complexity. Additionally, tuning the control loop coefficients would likely require twiddling the potentiometer settings (possibly for each individual board), which is undesirable in some or most cases, by today’s manufacturing standards. So, on the hardware solution side, we’re left with a CPLD or an FPGA to implement the motion control algorithm and track the distance traveled. This happens to be a very good fit for either since it is potentially small enough to fit into a CPLD, but in some cases, the cost of an FPGA might be unacceptable. This problem is also handled by MCUs regularly. If existing in-house resources don’t have the expertise required with hardware languages or toolchains, then a bare-metal MCU firmware solution is probably a good fit.
Let’s say the problem is more complicated, such as a device that controls several different actuators (for example, a motor or a solenoid valve). The device reads data from a range of sensors and stores those values in local storage. Perhaps the device also needs to sit on some sort of network, such as Ethernet, Wi-Fi, a controller area network (CAN), and so on. An RTOS can solve this type of problem quite well. The fact that there are many different tasks that need to be completed, more or less asynchronously with one another, makes it very easy to argue that the additional complexity the RTOS brings will pay off.
Some RTOS tasks are lower-priority and more complex, such as networking and filesystem processing. Other tasks are time-critical, such as controlling actuators and reading sensors. The RTOS helps us to ensure the lower-priority and more complex tasks won’t interfere with the time-critical tasks. Also, in many cases, there may be some form of control system that generally benefits from being run at well-defined time intervals—a strength of the RTOS.
Consider a system similar to the previous one, but now there are multiple networking requirements, such as serving a web page, dealing with user authentication in a complex enterprise environment, and pushing files to various shared directories that require different network-based file protocols. This level of complexity can be achieved using an RTOS, but again, depending on the available team resources, this might be better left to a full-blown OS to handle (either an RTOS or a general-purpose OS) since many of the complex software stacks required already exist. Sometimes, a multi-core approach might be taken, with one of the cores running an RTOS and the other running a general-purpose OS.
By now, it is probably obvious that there is no definitive way to determine exactly which real-time solution is correct for all cases. Each project and team will have its own unique requirements, backgrounds, skill sets, and contexts that set the stage for this decision. There are many factors that go into selecting a solution to a problem; it is important to keep an open mind and choose the solution that is best for your team and project at that point in time.
