When do turn to a RTOS

nobody wrote on Tuesday, February 21, 2006:

Does anyone have any good primers on when to turn to a RTOS?  Thanks.

jra01 wrote on Wednesday, February 22, 2006:

Just trying to figure out when NOT using an RTOS:
-Extreme time constraints: All OS:s slow down task switching. Normally, on the other hand, you can bypass the OS for the very quick interrupts (> 1kHz I guess is very quick for most systems). The OS also uses rather much of the processor time (no exact figures, depends on a lot of things, e g tick rate, but tens of % I think is normal).
-Extremely small and energy constrained devices, where you can defend such greediness in hardware that you cannot afford the extra space to OS will need (5k is not much!), and where you will not have a very complicated application.
-Small projects with special processor. In some cases there is more work to port an existing OS, than to write a small timer-interrupt-based scheduler by yourself.

I have been working for about 15 years without OS, and 1 year with freeRTOS. I will stay with the OS if I can! It simplifies work, facilitates porting of third party software, and inproves software structure.

I am sure I have missed a lot :-). Let’s see what other people say.


henkvisser wrote on Wednesday, February 22, 2006:

My goal is to be sampling about 3 a/d channels as fast as possible. And while doing this I need to be able to read other devices and write to a screen.  The faster sampling the better. >= 1 kHz.  There have been so many timing issues that we have been trying to work out and most of the time we have been dropping in delays manually to balanace the timings!

If I am trying to sample a high speeds from what you are saying the OS might get in the way!  I guess I can just try it out and see how fast I can do everything.

Thanks for your thoughts.


nobody wrote on Wednesday, February 22, 2006:

You might like to try having your a2d sampling completely interrupt driven, with a fast data transfer to wherever the data is used.  Then have cooperative tasks and a slow tick rate as possible to limit the overhead of the os.