+2  A: 

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

Doug Currie
+1  A: 

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
waffleman
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.
spade78
+6  A: 

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.

Dan
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.
spade78
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.
spade78
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.
RBerteig
+1 for making the answer I was considering typing unnecessary. I'd just add a pointer to http://www.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.
RBerteig
A: 

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.

Ilia
A: 

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

chrmue