Why would I consider using an RTOS for my embedded project?

Question

First the background, specifics of my question will follow:

At the company that I work at the platform we work on is currently the Microchip PIC32 family using the MPLAB IDE as our development environment. Previously we've also written firmware for the Microchip dsPIC and TI MSP families for this same application. The firmware is pretty straightforward in that the code is split into three main modules: device control, data sampling, and user communication (usually a user PC). Device control is achieved via some combination of GPIO bus lines and at least one part needing SPI or I2C control. Data sampling is interrupt driven using a Timer module to maintain sample frequency and more SPI/I2C and GPIO bus lines to control the sampling hardware (ie. ADC). User communication is currently implemented via USB using the Microchip App Framework.

---

So now the question: given what I've described above, at what point would I consider employing an RTOS for my project? Currently I'm thinking of these possible trigger points as reasons to use an RTOS:

• Code complexity? The code base architecture/organization is still small enough that I can keep all the details in my head.
• Multitasking/Threading? Time-slicing the module execution via interrupts suffices for now for multitasking.
• Testing? Currently we don't do much formal testing or verification past the HW smoke test (something I hope to rectify in the near future).
• Communication? We currently use a custom packet format and a protocol that pretty much only does START, STOP, SEND DATA commands with data being a binary blob.
• Project scope? There is a possibility in the near future that we'll be getting a project to integrate our device into a larger system with the goal of taking that system to mass production. Currently all our projects have been experimental prototypes with quick turn-around of about a month, producing one or two units at a time.

What other points do you think I should consider? In your experience what convinced (or forced) you to consider using an RTOS vs just running your code on the base runtime? Pointers to additional resources about designing/programming for an RTOS is also much appreciated.

Apogeotropism

Answer 1

There are many many reasons you might want to use an RTOS. They are varied & the degree to which they apply to your situation is hard to say. (Note: I tend to think this way: RTOS implies hard real time which implies preemptive kernel...)

• Rate Monotonic Analysis (RMA) - if you want to use Rate Monotonic Analysis to ensure your timing deadlines will be met, you must use a pre-emptive scheduler

• Meet real-time deadlines - even without using RMA, with a priority-based pre-emptive RTOS, your scheduler can help ensure deadlines are met. Paradoxically, an RTOS will typically increase interrupt latency due to critical sections in the kernel where interrupts are usually masked

• Manage complexity -- definitely, an RTOS (or most OS flavors) can help with this. By allowing the project to be decomposed into independent threads or processes, and using OS services such as message queues, mutexes, semaphores, event flags, etc. to communicate & synchronize, your project (in my experience & opinion) becomes more manageable. I tend to work on larger projects, where most people understand the concept of protecting shared resources, so a lot of the rookie mistakes don't happen. But beware, once you go to a multi-threaded approach, things can become more complex until you wrap your head around the issues.

• Use of 3rd-party packages - many RTOSs offer other software components, such as protocol stacks, file systems, device drivers, GUI packages, bootloaders, and other middleware that help you build an application faster by becoming almost more of an "integrator" than a DIY shop.

• Testing - yes, definitely, you can think of each thread of control as a testable component with a well-defined interface, especially if a consistent approach is used (such as always blocking in a single place on a message queue). Of course, this is not a substitute for unit, integration, system, etc. testing.

• Robustness / fault tolerance - an RTOS may also provide support for the processor's MMU (in your PIC case, I don't think that applies). This allows each thread (or process) to run in its own protected space; threads / processes cannot "dip into" each others' memory and stomp on it. Even device regions (MMIO) might be off limits to some (or all) threads. Strictly speaking, you don't need an RTOS to exploit a processor's MMU (or MPU), but the 2 work very well hand-in-hand.

Generally, when I can develop with an RTOS (or some type of preemptive multi-tasker), the result tends to be cleaner, more modular, more well-behaved and more maintainable. When I have the option, I use one.

Be aware that multi-threaded development has a bit of a learning curve. If you're new to RTOS/multithreaded development, you might be interested in some articles on Choosing an RTOS, The Perils of Preemption and An Introduction to Preemptive Multitasking.

Lastly, even though you didn't ask for recommendations... In addition to the many numerous commercial RTOSs, there are free offerings (FreeRTOS being one of the most popular), and the Quantum Platform is an event-driven framework based on the concept of active objects which includes a preemptive kernel. There are plenty of choices, but I've found that having the source code (even if the RTOS isn't free) is advantageous, esp. when debugging.

Stouffer

Oh, my mistake really. As well as trying to get an idea of why I would want to turn to an RTOS I'm also looking for pointers to more resources that I can research further. Thanks for the detailed explanation. – Apogeotropism

Definitley the stuff we've been doing thus far for our projects have been pretty much DIY. Having a structure to enforce basic tenets of how it runs and how we can build on top of it would be a plus in my book as right now we build from scratch and I find myself chucking my code every few iterations because its too tightly coupled to the last design's hardware or the method that was chosen to implement the application code. – Apogeotropism

Even the smallest RTOS (uC/OS-II and FreeRTOS leap to mind) will help you avoid reinventing wheels such as semaphores, queues, event flags and more that are tricky to get exactly right and cause very hard to debug problems if not implemented exactly right. – Exorcist

+1 for making the answer I was considering typing unnecessary. I'd just add a pointer to micrium.com which is the home of uC/OS-II. It's commercial open source, and the subject of a textbook on the design of an RTOS which can be found at the same site. I'd recommend the book as a good overview to the what, why, and how of the kernel. – Exorcist

Answer 2

RTOS, first and foremost permits you to organize your parallel flows into the set of tasks with well-defined synchronization between them.

IMO, the non-RTOS design is suitable only for the single-flow architecture where all your program is one big endless loop. If you need the multi-flow - a number of tasks, running in parallel - you're better with RTOS. Without RTOS you'll be forced to implement this functionality in-house, re-inventing the wheel.

Virgule

Answer 3

Code re-use -- if you code drivers/protocol-handlers using an RTOS API they may plug into future projects easier

Debugging -- some IDEs (such as IAR Embedded Workbench) have plugins that show nice live data about your running process such as task CPU utilization and stack utilization

Hubris

Answer 4

Usually you want to use an RTOS if you have any real-time constraints. If you don’t have real-time constraints, a regular OS might suffice. RTOS’s/OS’s provide a run-time infrastructure like message queues and tasking. If you are just looking for code that can reduce complexity, provide low level support and help with testing, some of the following libraries might do:

• The standard C/C++ libraries
• Boost libraries
• Libraries available through the manufacturer of the chip that can provide hardware specific support
• Commercial libraries
• Open source libraries

Agram

It sounds like I should consider an RTOS more like a library with a certain feature set that I want to take advantage of. Up till now I've always saw an RTOS like putting Windows on my microcontroller which always made it seem like overkill considering my requirements. – Apogeotropism

Answer 5

Additional to the points mentioned before, using an RTOS may also be useful if you need support for

• standard storage devices (SD, Compact Flash, disk drives ...)
• standard communication hardware (Ethernet, USB, Firewire, RS232, I2C, SPI, ...)
• standard communication protocols (TCP-IP, ...)

Most RTOSes provide these features or are expandable to support them

Lordinwaiting