Q5Microcontroller and Embedded Systems

A multi-tasking system is an operating system or embedded software architecture capable of managing the apparently simultaneous execution of multiple independent tasks (also called threads or processes) on a single CPU, by rapidly switching the CPU's attention back and forth between the different tasks according to a scheduling policy, so that from the perspective of an outside observer (or of the tasks themselves, at the timescale each individual task cares about), all the tasks appear to be progressing concurrently, even though at any single instant in time the CPU is, in fact, actually executing only one task's instructions at a time on a conventional single-core processor. Multi-tasking is achieved through a combination of a scheduler (the software component responsible for deciding which task runs next, discussed further below) and a context-switching mechanism (the low-level routine that saves the complete register state, including the program counter, of the currently running task, and restores the previously saved register state of the next task to be run, so that each task, when it resumes, continues exactly from where it had previously been suspended). A representative example of multi-tasking in an embedded system is a data-logging instrument that must simultaneously sample a sensor at a fixed periodic rate, update a numeric display showing the most recent reading, and monitor a keypad for user button presses to change the display mode; rather than writing a single, large, tightly interleaved program that manually manages all three activities together, a multi-tasking architecture allows each of these three activities to be written as an independent, logically self-contained task (the sensor-sampling task, the display-update task, and the keypad-scanning task), with the underlying multi-tasking scheduler responsible for ensuring each task receives adequate CPU time to meet its own individual timing requirements, considerably simplifying the application software's structure and making each task's logic easier to write, test, and maintain independently of the others.

Scheduling

Scheduling is the specific policy and associated algorithm used by a multi-tasking operating system's scheduler to decide, at any given moment when the CPU becomes available for reassignment (such as when the currently running task voluntarily yields the CPU, blocks waiting for an event, or is forcibly preempted after its allotted time slice expires), which of the currently ready-to-run tasks should be granted the CPU next. Different scheduling algorithms make this next-task selection decision according to different criteria and priorities, such as strict priority (always running the highest-priority ready task, as used in many real-time operating systems for embedded control applications where certain tasks have hard deadlines that must never be missed), first-come-first-served (running tasks in the order they became ready, without regard to priority), or round robin (discussed in detail below), with the choice of scheduling algorithm directly determining the resulting system's real-time responsiveness, fairness among competing tasks, and overall predictability of task completion timing.

Round Robin Scheduling

Round robin scheduling is a scheduling algorithm in which every ready-to-run task is granted the CPU in a fixed, cyclically repeating order, with each task allowed to run for at most a fixed, predetermined time interval called a time slice or quantum before being preempted (forcibly suspended, regardless of whether it has completed its work) and moved to the back of the ready queue, allowing the next task in the cyclic order to then receive its own turn at the CPU for one time slice, and so on, cycling back around to the first task once every task in the ready queue has had its turn. Round robin scheduling is specifically designed to ensure fairness among tasks of otherwise equal priority, since every ready task is guaranteed to receive a turn at the CPU within a bounded time (specifically, within at most N time slices, where N is the number of currently ready tasks sharing the CPU), preventing any single task from monopolizing the CPU indefinitely and starving the other tasks of processing time, a property particularly valuable in general-purpose time-sharing systems where multiple independent, equally important tasks must all make steady forward progress. The choice of time slice duration in a round robin scheduler represents an important design tradeoff: a very short time slice gives excellent apparent responsiveness (since every task is revisited very frequently) but incurs a correspondingly larger proportion of total CPU time lost to the overhead of the context-switching operation itself (which must be performed at every time slice boundary), while an excessively long time slice reduces context-switching overhead but degrades the system's apparent responsiveness, since a task waiting for its turn may need to wait for as long as nearly the full duration of every other ready task's time slice before finally being serviced, making the selection of an appropriate time slice duration a key practical tuning parameter in any round robin scheduling implementation.

It is further worth noting that the effectiveness of round robin scheduling in ensuring fairness relies on all tasks being treated as having genuinely equal priority; in practice, many real embedded and general-purpose operating systems combine round robin scheduling with an overlaid priority scheme, applying round robin fairness only among tasks that share the same priority level while still allowing a strict priority-based preemption rule to apply across different priority levels, giving a hybrid scheduling scheme that achieves both the fairness benefits of round robin scheduling within a priority tier and the responsiveness guarantees of strict priority scheduling across tiers, illustrating that round robin scheduling in practical systems is often one building block within a larger, more sophisticated overall scheduling policy rather than the sole scheduling mechanism used throughout an entire system.

It is further worth noting that the specific data-logging instrument example discussed above for illustrating multi-tasking would, if implemented using round robin scheduling among its three tasks (sensor sampling, display update, and keypad scanning), need careful selection of an appropriately short time slice to ensure the sensor-sampling task, which likely has the most demanding real-time periodicity requirement of the three, is revisited frequently enough to maintain its required sampling rate, illustrating in concrete terms how the general time-slice-duration tradeoff discussed above translates into a specific, practical design decision for a real embedded multi-tasking application.