4 ms·

What's the advantage of a RTOS?

by Hasz 9y ago

dmoy 9y ago
Been awhile since I dealt with microcontrollers, but my recollection is that some non-trivial amount of things have to be done by a RTOS. For example if your thing is attached to a sensor that spits out 47 bytes of sensor data every N clock cycles, and has a buffer that is 94 bytes, then you damn well better be reading that thing every N*2 clock cycles with a hard guarantee that your routine is finished copying all 94 bytes of data by the time it finishes (including time for interrupts). This gets complicated when you have specific requirements about when data is available or other things too (e.g. if reading data requires pulling pin X low, waiting at least Y clock cycles, and then reading all data in no more than Z clock cycles before returning pin X back to high, then good luck doing that in a normal OS where you have no hard time guarantees).
- HankB99 9y ago
  Two models are common in embedded systems: "main loop" or RTOS. In the main loop model, once initialization is complete, the program loops indefinitely, servicing various functions. Since the developer is responsible for a larger portion of the code, it is easier to meet timing deadlines. An RTOS provides a convenience to allow various threads to block and thus simplify programming. I would choose an RTOS where there are a greater number of independent tasks which need to be performed. Both are alternatives to a conventional OS which makes hitting deadlines difficult or impossible.
  - nitrogen 9y ago
    An additional advantage of some kind of RTOS, or at least using interrupts: infinite looping uses more power than sleeping and waiting for interrupts.
- ianhowson 9y ago
  It's worth noting that very few devices using an RTOS actually have real-time constraints. In practice, "RTOS" just means "operating system for an embedded device".
- amelius 9y ago
  Does an RTOS have a built-in theorem prover to accomplish that?
IncRnd 9y ago
The advantage is that you can make claims about the maximum time it take to process something. Contrast that to Windows, macos, or Ubuntu that generally are zippy on new hardware, but sometimes the circle spins or the hourglass shows up and makes you wait, possibly for an outsized period of time for what is being processed.
- archi42 9y ago
  To make any worthwhile claims you need the worst case execution time of your code. Even in the absence of multi-threading, technologies like caches or out-of-order execution can make this quite painful. The common solution seems to be: Don't care for some missed values (e.g. non-safety critical systems) or over provisioning (absence of budget pressure). -> A RTOS alone doesn't give you any reliable claims (but does make a lot of embedded stuff much easier).
  - anmorgan 9y ago
    What I assume IncRnd is referring to is the deterministic behavior of an RTOS. Here is a good white paper from National Instruments: http://www.ni.com/white-paper/3938/en/ http://www.ni.com/white-paper/3938/en/
    - IncRnd 9y ago
      Thank you. That is a good explanation and is indeed what I meant.
  - deleted 9y ago
    [deleted]
zik 9y ago
The usual reason for using an RTOS on small embedded controllers is that a full OS is way too big to fit on such small CPUs (eg. 64K of RAM and 256K of FLASH is common). FreeRTOS is tiny - it only uses a few KB of FLASH. Non real time OSes also don't provide the timing guarantees that are often required in those kinds of applications.
- ramzyo 9y ago
  Valid point, but I’d have to disagree with you here. My experience as to why RTOS are chosen for small embedded micros is either a) some hard real time requirement is a must, eg motor control. You’re right that a non real time OS won’t provide that, but a blocking super loop baremetal application with round-robin task queueing may not either, depending on what’s in the queue b) the source of baremetal super-loop applications gets too jumbled as requirements grow and/or they require some multi-tasking mechanism for performance reasons. RTOS provide a multi-tasking mechanism.
patja 9y ago
Not having to worry about a more complex OS burping, leaking, or otherwise failing on you. As one poster on the Arduino forums explained it to me once, "you never know when Linux is going to nip off for a cup of tea and interrupt your program with some system overhead tasks." You are going to get your n cycles per second, every second.
- ramzyo 9y ago
  This is a common misconception about RTOSes, or at least needs to be further qualified with soft real time vs hard real time OSes. RTOSes provide schedulers and multitasking mechanisms for context switching between tasks. Tasks can be assigned priorities. A higher priority task can pre-empt a lower priority task (depending on the RTOS’ scheduler implementation). In that case, you may never get your cycles, or at least not deterministically. tl;dr, depends on the scheduler implementation.
bschwindHN 9y ago
People have listed other benefits such as timing guarantees, lack of general OS overhead, etc. One of the things I like about an RTOS is the organization it gives to your code. It gives you primitives like tasks, queues, and semaphores and allows you to easily organize and synchronize independently running tasks. On something like Arduino where you just have a setup() and a loop() function, it can become a mess if you're trying to do many different things with different timing requirements.
rkangel 9y ago
"RTOS" is the term used to describe the core component of most embedded systems. Technically it should mean a scheduler that provides 'bounded latency' in scheduling operations. That means that if a certain (internal or external) event happens, the code to run it should happen with no more than a certain delay. Embedded systems tend to be doing things that look more like real-time control applications. Let's say the processor is running a radio. It is important that certain requests form the radio hardware are processed quickly enough otherwise the data isn't ready to transmit in the time slot that it is meant to be in, and you don't meet the standard for that protocol. In practice though, what people are actually wanting is an abstraction around the concepts of scheduling, and facilities like multi-tasking (with pre-emption), and facilities to communicate between tasks in a thread safe way. Mostly they don't need the 'hard' RTOS aspects (and so this is often referred to as 'soft RTOS'). To explain this a little - your traditional simplistic embedded app while look like 'while(1) {}' at the bottom of main. It will sit in a loop servicing the things that need to be serviced - pulling characters off a UART, waggling the line for the LED to make it flash on the right interval etc.. This is fine for a small app on an 8 bit processor but as embedded applications grow, you have a lot of functionality that is all tied up with each other. What an embedded scheduler does is put the main loop at the bottom of the dependency tree rather than the top - modules of code can be separated out and request themselves to be scheduled when necessary allowing for much cleaner separation, and more robust code.

What's the advantage of a RTOS?

by Hasz 9y ago

What's the advantage of a RTOS?

dmoy 9y ago

Been awhile since I dealt with microcontrollers, but my recollection is that some non-trivial amount of things have to be done by a RTOS. For example if your thing is attached to a sensor that spits out 47 bytes of sensor data every N clock cycles, and has a buffer that is 94 bytes, then you damn well better be reading that thing every N*2 clock cycles with a hard guarantee that your routine is finished copying all 94 bytes of data by the time it finishes (including time for interrupts). This gets complicated when you have specific requirements about when data is available or other things too (e.g. if reading data requires pulling pin X low, waiting at least Y clock cycles, and then reading all data in no more than Z clock cycles before returning pin X back to high, then good luck doing that in a normal OS where you have no hard time guarantees).

HankB99 9y ago
Two models are common in embedded systems: "main loop" or RTOS. In the main loop model, once initialization is complete, the program loops indefinitely, servicing various functions. Since the developer is responsible for a larger portion of the code, it is easier to meet timing deadlines. An RTOS provides a convenience to allow various threads to block and thus simplify programming. I would choose an RTOS where there are a greater number of independent tasks which need to be performed. Both are alternatives to a conventional OS which makes hitting deadlines difficult or impossible.
- nitrogen 9y ago
  An additional advantage of some kind of RTOS, or at least using interrupts: infinite looping uses more power than sleeping and waiting for interrupts.
ianhowson 9y ago
It's worth noting that very few devices using an RTOS actually have real-time constraints. In practice, "RTOS" just means "operating system for an embedded device".
amelius 9y ago
Does an RTOS have a built-in theorem prover to accomplish that?

IncRnd 9y ago

The advantage is that you can make claims about the maximum time it take to process something. Contrast that to Windows, macos, or Ubuntu that generally are zippy on new hardware, but sometimes the circle spins or the hourglass shows up and makes you wait, possibly for an outsized period of time for what is being processed.

archi42 9y ago
To make any worthwhile claims you need the worst case execution time of your code. Even in the absence of multi-threading, technologies like caches or out-of-order execution can make this quite painful. The common solution seems to be: Don't care for some missed values (e.g. non-safety critical systems) or over provisioning (absence of budget pressure). -> A RTOS alone doesn't give you any reliable claims (but does make a lot of embedded stuff much easier).
- anmorgan 9y ago
  What I assume IncRnd is referring to is the deterministic behavior of an RTOS. Here is a good white paper from National Instruments: http://www.ni.com/white-paper/3938/en/ http://www.ni.com/white-paper/3938/en/
  - IncRnd 9y ago
    Thank you. That is a good explanation and is indeed what I meant.
- deleted 9y ago
  [deleted]

zik 9y ago

The usual reason for using an RTOS on small embedded controllers is that a full OS is way too big to fit on such small CPUs (eg. 64K of RAM and 256K of FLASH is common). FreeRTOS is tiny - it only uses a few KB of FLASH. Non real time OSes also don't provide the timing guarantees that are often required in those kinds of applications.

ramzyo 9y ago
Valid point, but I’d have to disagree with you here. My experience as to why RTOS are chosen for small embedded micros is either a) some hard real time requirement is a must, eg motor control. You’re right that a non real time OS won’t provide that, but a blocking super loop baremetal application with round-robin task queueing may not either, depending on what’s in the queue b) the source of baremetal super-loop applications gets too jumbled as requirements grow and/or they require some multi-tasking mechanism for performance reasons. RTOS provide a multi-tasking mechanism.

patja 9y ago

Not having to worry about a more complex OS burping, leaking, or otherwise failing on you. As one poster on the Arduino forums explained it to me once, "you never know when Linux is going to nip off for a cup of tea and interrupt your program with some system overhead tasks." You are going to get your n cycles per second, every second.

ramzyo 9y ago
This is a common misconception about RTOSes, or at least needs to be further qualified with soft real time vs hard real time OSes. RTOSes provide schedulers and multitasking mechanisms for context switching between tasks. Tasks can be assigned priorities. A higher priority task can pre-empt a lower priority task (depending on the RTOS’ scheduler implementation). In that case, you may never get your cycles, or at least not deterministically. tl;dr, depends on the scheduler implementation.

bschwindHN 9y ago

People have listed other benefits such as timing guarantees, lack of general OS overhead, etc. One of the things I like about an RTOS is the organization it gives to your code. It gives you primitives like tasks, queues, and semaphores and allows you to easily organize and synchronize independently running tasks. On something like Arduino where you just have a setup() and a loop() function, it can become a mess if you're trying to do many different things with different timing requirements.

rkangel 9y ago

"RTOS" is the term used to describe the core component of most embedded systems. Technically it should mean a scheduler that provides 'bounded latency' in scheduling operations. That means that if a certain (internal or external) event happens, the code to run it should happen with no more than a certain delay. Embedded systems tend to be doing things that look more like real-time control applications. Let's say the processor is running a radio. It is important that certain requests form the radio hardware are processed quickly enough otherwise the data isn't ready to transmit in the time slot that it is meant to be in, and you don't meet the standard for that protocol. In practice though, what people are actually wanting is an abstraction around the concepts of scheduling, and facilities like multi-tasking (with pre-emption), and facilities to communicate between tasks in a thread safe way. Mostly they don't need the 'hard' RTOS aspects (and so this is often referred to as 'soft RTOS'). To explain this a little - your traditional simplistic embedded app while look like 'while(1) {}' at the bottom of main. It will sit in a loop servicing the things that need to be serviced - pulling characters off a UART, waggling the line for the LED to make it flash on the right interval etc.. This is fine for a small app on an 8 bit processor but as embedded applications grow, you have a lot of functionality that is all tied up with each other. What an embedded scheduler does is put the main loop at the bottom of the dependency tree rather than the top - modules of code can be separated out and request themselves to be scheduled when necessary allowing for much cleaner separation, and more robust code.