"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 sched

"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.