Embedded Systems Design Europe - February 2008 - (Page 14)

feature Thirty years ago, full-ﬂedged real-time operating systems (RTOSs) existed and professional features like multitasking and multiprocessing were applied and implemented. This brings up an interesting point: where exactly does multitasking ﬁt with this technology? With a little research, I found that products are available to handle multitasking with an RTOS. Developers must then question whether the RTOS is really required for their application, or near-real-time would sufﬁce. Back then, in the absence of multitasking, serial task execution was the only way to run embedded systems. Figure 1 shows two tasks running in a system. Task #1 executes until it concludes its operation, then passes control to Task #2. Task #2 runs and eventually terminates causing system operation to end. By deﬁnition, multitasking allows an embedded system to share its resources between several programs running concurrently. The resources can be those of the processor itself (such as internal registers, memory, and arithmetic logic units) or the peripherals attached to the embedded system (such as display, printer, sensors, and actuators). Figure 2 illustrates a simple form of multitasking. Here, Task #1 is the main task running in the system until some sort of interrupt or an event occurs at time t1. This causes the system to put that task on hold, passing its control to another secondary Task #2, at time t2, to serve the event and willingly return system control to the main task at time t3. This kind of multitasking is based on cooperation between the running tasks, such that tasks are willing to give up system control at some point throughout their execution. Note that there’s no mention of operating-system coordination between tasks; task delegation of system control is built in the task programs themselves. Nested subroutine calls and branching instructions are a means of implementing simple multitasking. Multitasking in an operating-system environment is a different story. System resource sharing is realized under the operating system’s control, rather than task delegation, by allocating those resources to a single task for a speciﬁc period of time before putting them temporarily on hold and switching the resources to another task. The task allocated time and frequency depend on “multitasking policy.” Different policy schemes can be adopted, such as round-robin (equal task rights) and priority-based (higher priority tasks use resources more frequently than lower priority ones). The part of the operating system responsible for task switching is called the task scheduler. The scheduler enforces the multitasking policy whenever it regains system control from the user tasks. User tasks can be designed to either give up system control to the scheduler voluntarily (scenario #1) or forcibly (scenario #2). Scenario #1, called cooperative multitasking, is where a breakpoint is implanted in the task program to transfer system control to the scheduler program. The scheduler can later resume task execution at that breakpoint. Figure 3 illustrates this scenario with three tasks. Task #1 returns control to the scheduler at time t1. The scheduler decides that Task #2 gets the control, which is passed on to it at time t2. At time t3, Task #2 returns control to the scheduler and Task #3 gets control at t4. Task #3returns control to the scheduler at t5; the scheduler then decides that Task #1 resumes its execution. Task #1 regains control at t6. This scenario repeats until all tasks conclude their operation or the system shuts down. Scenario #2, called preemptive multitasking, is where task execution is interrupted at any point in time by an internal or external system event. System control is then handed over to the scheduler to decide which task is to resume execution. Figure 4 illustrates this scenario with two tasks. Here, Task #1 runs until an interrupt 14 JANUARY – FEBRUARY 2008 | embedded systems design europe | www.embedded.com/europe 013-014-016-017_ESDE.indd 14 7/02/08 11:38:36 http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - February 2008

Embedded Systems Design Europe - February 2008 Contents ARTEMIS and ENIAC Get Parlimentary Approval Product Teardown Videos Come On Screen Esterel and Abslnt Integrate Products Microsoft Opens Windows to Networked Embedded Applications Trango Embeds Virtualization Tool in Cavium's Multicore CPUs MindTree - ADI Develop Security DVR Platform NXP Extends Deal with ARM to Cover MCUs Automotive and Embedded to Dominate DATE 08 ZigBee Spec Gets Smart On Energy Updated Card Spec Provides for Power-On Boot The Basics of Embedded Multitasking On a PIC Cover Feature: The Art of FPGA Construction Is Symmetric Multiprocessing For You? Accelerating MATLAB Using MEX-Files ARM Provides the Microcontroller Solution Embedded World Advertising Contracts

Embedded Systems Design Europe - February 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.