Hi everyone,

I'm an engineer working at Raisonance and among other things I work on the 8051/MX RTOS.

Firstly, I quite agree that the name "RTOS" can be confusing. But the same is true of many other things. (my perfered being "AI")
For me a RTOS is just a tool to easily and quickly write complex applications where time is involved.
Meaning that some events have to trigger some other events after a determined time.
NOT meaning that it can do it faster or better than without using a RTOS. It's only easier and faster _to_write_, in some situations.


Use a RTOS if you know how to use it and if your application is suited for it.
You'll learn how to recognize this while you learn how to use the RTOS.
And if working time (your time, not the processor's) is an issue. (when is it not?)



This topic is quite complex and there would be lots of things to say on it (many books have been written), but I'll try to keep it short and for this I'll use a comparison that can be applied to almost any kind of tool.


Like most complex tools, a RTOS is similar to a C compiler, a C++ compiler, or even a snow-plough in these aspects:

1. You can always do without it: you could write anything in assembler, (some people do it) so why use a C compiler? You can clean the road with many people and many shovels, so why use a snow-plough?

2. Using the tool is often _less_ efficient that doing the same job without it: programs written in assembly are most of the time smaller and faster than their C counterpart, programs written in C are most of the time smaller and faster than their C++ counterpart, and I won't speak about ".net"...

3. Using the tool can be quite complex and takes some time to learn. This is why some people still code everything in assembler. And I guess that learning how to drive a snow-plough takes some time too!

4. Using the tool is usually faster to get to the result, provided you know how to use it well: writing a program in assembler is much longer than writing it in C. If you know C, of course.



Like all "complex tools", the RTOS has these characteristics:

1.
You could do everything with interrupts and a big loop like someone suggested in this topic.
Or something more complex and more efficient.
But sometimes after adding things and stuff, you end up rewriting your own personnal RTOS without noticing.
I've seen it several times!
And in this case, you'd better go from the start with a RTOS that already has been validated, optimized, etc.

2.
The RTOS itself needs processor time and code space.
Even though using a RTOS is sometimes better than a badly-written homemade solution.

3.
The first time you use a RTOS, you will probably be lost in the taskns, priorities, semaphores, etc.
Unless you are used to multi-task programming style, maybe.

4.
For _some_ applications, a trained RTOS user can finish a complex design at an impressive speed.
Much faster than without it.
And that's the only reason why so many people use them.


As you see, there are 3 points against the use of a RTOS and one point for it.
But in some situations, the 4th point alone gets more important than the 3 others united!

Now, I'm not saying that a RTOS is a good thing for every application. There are situations where it is really a bad idea.


Finally, I want to remind you that using a RTOS does not prevent you from using interrupts for the "really time-critical" actions.
This is in fact recommended in our RTOS's doc. ;)


Vincent