I really hate to be naive - any chance someone would be able to ELI5 RTOS please? How they may differ from say MS Windows, why use one, their applications. Always struggled to bend my head around them
Unlike a general-purpose operating system, when using a RTOS it is possible to guarantee that a given action will be executed before a certain deadline in time.
The general-purpose operating systems attempt to execute all available tasks as quickly as possible and in a fair manner between users, but they cannot make guarantees about the worst-case execution times, which can be very bad even when the average execution times are very good.
In order to be able to provide time guarantees, a RTOS avoids any algorithms that are not deterministic and it uses different policies for scheduling the execution threads, unlike those used by a general-purpose OS.
Most RTOSes use fixed priorities for the execution threads, where any higher-priority thread always preempts immediately a lower-priority thread, whenever an interrupt signals an event which must be handled by the high-priority thread, while the threads of equal priority are scheduled in a round-robin manner.
Unlike when programming for a general-purpose OS, when programming for a RTOS a very important additional task for the programmer is to assign priorities for all the execution threads. If the priorities are assigned in a wrong way, it can be impossible to guarantee the time deadlines.
For some common cases there are easy rules for priority assignments. E.g. when having a set of threads that are activated periodically, which must always finish their work within a period, then the priorities must be assigned, from the highest to the lowest, to the threads ordered from the smallest period to the greatest period.
The programs which may execute for an indefinite time after they receive control, like many of those written for Windows or Linux, must be put on the lowest priority level available, because any program with a lower priority than them would never be executed by an RTOS. When there are more such programs, they are executed in round-robin manner, being preempted after a configurable time interval.
Basically the same as any other OS, but typically stripped down to the bare essentials. The key differentiator is the kernel scheduler, which is typically set up to provide regular and guaranteed time slices to processes.
Normal operating systems provide time slices in big chunks, and not very predictably.
The RTOS approach is less efficient overall and has lower total throughput, but some applications don’t need a lot of horsepower, just consistency.
Think: robotics, audio, servo motor controllers, etc…
>>In the context of multitasking systems the scheduling policy is normally priority driven (pre-emptive schedulers). In some situations, these can guarantee hard real-time performance (for instance if the set of tasks and their priorities is known in advance). There are other hard real-time schedulers such as rate-monotonic which is not common in general-purpose systems, as it requires additional information in order to schedule a task: namely a bound or worst-case estimate for how long the task must execute. Specific algorithms for scheduling such hard real-time tasks exist, such as earliest deadline first, which, ignoring the overhead of context switching, is sufficient for system loads of less than 100%.[7] New overlay scheduling systems, such as an adaptive partition scheduler assist in managing large systems with a mixture of hard real-time and non real-time applications.
The general-purpose operating systems attempt to execute all available tasks as quickly as possible and in a fair manner between users, but they cannot make guarantees about the worst-case execution times, which can be very bad even when the average execution times are very good.
In order to be able to provide time guarantees, a RTOS avoids any algorithms that are not deterministic and it uses different policies for scheduling the execution threads, unlike those used by a general-purpose OS.
Most RTOSes use fixed priorities for the execution threads, where any higher-priority thread always preempts immediately a lower-priority thread, whenever an interrupt signals an event which must be handled by the high-priority thread, while the threads of equal priority are scheduled in a round-robin manner.
Unlike when programming for a general-purpose OS, when programming for a RTOS a very important additional task for the programmer is to assign priorities for all the execution threads. If the priorities are assigned in a wrong way, it can be impossible to guarantee the time deadlines.
For some common cases there are easy rules for priority assignments. E.g. when having a set of threads that are activated periodically, which must always finish their work within a period, then the priorities must be assigned, from the highest to the lowest, to the threads ordered from the smallest period to the greatest period.
The programs which may execute for an indefinite time after they receive control, like many of those written for Windows or Linux, must be put on the lowest priority level available, because any program with a lower priority than them would never be executed by an RTOS. When there are more such programs, they are executed in round-robin manner, being preempted after a configurable time interval.