Switching from a "one-big-loop" style of programming to a multithreaded real-time operating system (RTOS) can make sense in many applications. An RTOS can switch between multiple tasks, or threads of execution, so it appears that the tasks are running concurrently. Although the processor can execute only one task at a time, RTOS task switching gives the illusion of concurrent execution.
Most embedded RTOSs use preemptive priority-based task switching, meaning that the CPU can switch from one task to another at almost any time, usually in response to an external interrupt or RTOS system call. The RTOS executes high-priority tasks in preference to lower-priority tasks. This ability to run multiple tasks brings new complications, however, and RTOS services for intertask communication (e.g., message queues), synchronisation, and mutual exclusion (e.g., semaphores) are needed to address these issues.
Here's a look at the advantages of using an RTOS, along with several key issues to watch out for.
RTOS benefitsReduced interdependencies: An RTOS allows lengthy jobs to run independently in different tasks. Unlike with the one-big-loop method, there's no need to divide software unnaturally into small subjobs to take account of the timing and execution requirements of other parts of the system. Easier collaboration: An RTOS makes it easier to write modular code you can expand without fear of interfering with other parts of the system. This in turn makes it easier for a team of programmers to collaborate on a large project. Better response time: A preemptive RTOS can improve the real-time response to external events by ensuring that an appropriate high-priority task resumes execution as soon as the RTOS receives an event. In contrast to the one-big-loop method, it isn't necessary to wait for other, less important jobs to complete first. Pitfalls
Shared resources: A preemptive task switch may occur while a task is accessing shared hardware or data. This may result in another task also attempting to access the same hardware or data before the first task has completed its operation. You can overcome these problems with strict and careful use of RTOS's mutual exclusion mechanisms. These include using semaphores, locking the RTOS scheduler, or briefly disabling interrupts. Non-reentrant code: Functions should be reentrant, so you need to avoid static/global data and using local (stack-based) storage for function variables. This allows multiple tasks to execute the same function at the same time without interference. Sometimes, tasks must share static data structures. Using the mutual exclusion techniques can protect them. Priority inversion: When a high-priority task can't run because it's waiting for a resource (e.g., semaphore) owned by a lower-priority task, priority inversion occurs. While it's waiting, the high-priority task effectively has the same priority as the lower-priority task. It can't run until the scheduling of the lower-priority task and the release of the resource. A high-priority task that occasionally behaves like a lower-priority task can have a disastrous affect on the real-time performance of your software. Some RTOSs avoid this problem using a priority-inheritance mechanism that temporarily bumps up the priority of the lower-priority task, but not all RTOSs support this feature. Deadlock: When two tasks can't proceed because they're each waiting for a resource owned by the other, you have a deadlock. The tasks effectively hang. Avoiding deadlock conditions requires careful attention to the way in which multiple tasks share semaphores and other RTOS resources. Deadlock conditions don't always show up easily during software testing. Extra CPU overhead: A small overhead is associated with task switching and other RTOS duties, although, in practice, it isn't necessarily a serious problem. The task-switching overheads serve to ensure that software is responsive and always switches to run the most important task. Extra memory requirement: Extra ROM/RAM is required for the RTOS code and associated data structures. Additionally, each task requires extra RAM for its own private stack space. Complex debugging: The dynamics of the code execution are more complex and less predictable in a multitasking RTOS environment. This can make it more difficult to reproduce the exact circumstances in which a bug occurred. Reaping the benefits
Although you need to be careful how you use an RTOS, the payoff may be worth it. RTOS task switching enables you to run lengthy jobs independently, write modular code to facilitate collaboration, and improve response time by prioritising tasks.
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
