Loop (no OS)
Description
The application is one control task which is typically implemented as a delayed loop or as an event-driven loop.
Locking (e.g. by disabling interrupts) is usually required to protect the data that is shared between the task and the Interrupt Service Routines (ISR’s). Except e.g. when events are sent with the single reader / single writer queues, but that is another topic.
A stack is allocated for each cpu mode (i.e. privileged mode and irq mode). The task uses the privileged mode (e.g. system mode) stack while the ISR’s use the irq mode stack.
The task has its own stack and also the ISR’s have their own stack (in fact the stack is assigned to the cpu irq mode) or share a single ISR stack.
There is no memory protection.
Benefits
- Simplicity
- Can run on very cheap processors
Drawbacks
- Requires full view on the system (everything impact anything)
- No memory protection
- The functions of the loop are not
supposed toallowed to “block” (e.g. busy wait for results)
Applications
- Very low-end controllers
- Sensors
- High volume applications which require a very low cost processor
Examples
- Only dedicated implementations?
Scheduler
Description
The application is composed of several tasks. The scheduler (the OS) decides which task runs. A task can always be interrupted by IRQ’s and, in the case of a real-time (pre-emptive) scheduler, a task can be pre-empted in favor of higher priority tasks. The OS typically includes basic IPC (Interprocess Communication, i.e. one task sharing information with another task in a safe manner) as well.
Locking (e.g. by disabling interrupts) is required to protect the data that is shared between the tasks and between the tasks and the Interrupt Service Routines (ISR’s).
Each task has its own stack. And there is usually one stack for all ISR’s (the irq mode stack) or the stack of the interrupted task is used (which makes it a bit difficult to estimate the worst case stack usage of each task; this scheme does waste some valuable resources).
There is no memory protection. This means that (buggy) tasks can corrupt other tasks’ memory such as stack, data etc.
Benefits
- Can run on cheap processors
- Several scheduling policies possible
- Apart from the scheduler, the OS typically also provides: synchronization mechanisms, basic IPC, basic heap etc.
Drawbacks
- No memory protection
Applications
- Low-end controller
- High-volume applications
- sSnsors
Examples
- FreeRTOS
- eCos
Scheduler + memory protection
Description
Very similar to the previous architecture (the scheduler) except that an MPU (Memory Protection Unit) enables the protection of certain memory regions. Typically, one would like to protect the scheduler (and its memory), mapped memory of hardware peripherals, some/each task stack region, etc. Note that there is also the possibility to run certain tasks in privileged mode while other tasks run in non-privileged mode.
Benefits
- Cfr. ‘the scheduler’
- Protected memory region improve the reliability of the system (protection against buggy tasks).
Drawbacks
- Cfr. ‘the scheduler’
Applications
- Functional safety applications
Examples
Microkernel (scheduler + memory management)
Description
The goal of a microkernel is to only provide the essential functionality: scheduling, memory management (MMU) and basic IPC. As such, the kernel stays lean and clean. Other non-essential functionality such as networking, file systems, device drivers etc. are regarded as user space services.
User space tasks live in their own protected virtual address space. This feature is realized by the memory management (MM) of the OS which makes use of the hardware Memory Management Unit (MMU).
Several tasks can share the same virtual address space (see Figure). In conventional terminology this set of tasks is called a ‘process’ while the tasks themselves are called the ‘threads’.
Benefits
- Because of the clean design the microkernel might be the best option for security and reliability (e.g. safety-critical applications)
Drawbacks
- Performance (overhead of communication and context switches)
Applications
- Safety-critical applications
- Security applications
Examples
- Minix
- Green Hills Integrity
- QNX
See also
Monolithic kernel (scheduler + memory mgmt + …)
Description
A kernel that integrates most import functionality (networking, file systems, storage etc.) in one monolithic block.
Benefits
- More performant than microkernel architecture
- Easy, unified API (e.g. POSIX) from application(s) to the kernel
Drawbacks
- Kernel can crash because of one buggy kernel module
Applications
- Displays
- High-end controllers
- Applications that require a file system, graphics, networking etc.
- Desktop OS
Examples
- Linux
- RTEMS (monolithic kernel but no support for paged memory for applications)
- …
About rtos.be
Nice introduction to the RTOS topic. It will be great if you explain in details of how to choose which functions run in the same task. At least for me, an RTOS-based design may perform worse than a bare-metal one if it has a wrong task partitioning.
Best regards,
Fernando
Hi Fernando,
We have prepared several other articles about this particular subject:
1.Real-time scheduling
2.Real-time scheduling: no locks, please.
3.Real-time scheduling: assigning priorities
4.Designing task algorithms
(and more on request)
These articles will be published in due course. Until now, our decision to publish one article a week still stands. Thus, it might take some time before the content you are looking for is available on our website. Thank you for your interest and stay tuned 😉
Best regards,
Gert and Pieter.
It seems that you’re working really hard on this blog. I’ll stay tuned for the content.
Regarding to task partitioning, here are some references I’ve found useful:
Using design patterns to identify and partition RTOS tasks (embedded.com)
Embedded Systems World class designs, Ch. 3 “System-level design”.
Fernando