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

feature occurs at time t1, suspending the task. Control is passed on to the scheduler program at t2, at which time the program decides to pass the control to Task #2 based on some policy and activates that task at t3. Task #2 runs until t4, when another interrupt occurs causing it to suspend and the control is passed on the scheduler again at t5. The scheduler decides to resume Task #1 execution at t6, which takes back control until another interrupt occurs. Frequent interrupts to running tasks enable the scheduler to manage system control switching between tasks. MULTITASKING REENTRANT PROGRAMS The tasks employed for a multitasking embedded system can be replicate control applications or a combination of control, data crunching, and user interfacing. But we know that not all embedded systems have an abundance of memory that ﬁts multiple task programs. In addition, many PICs have limited interrupts, work registers, and stack capabilities that keep them form competing against full-ﬂedged processors. This may explain why it’s hard to ﬁnd operating systems that support multitasking. One way around the PIC’s limitations allows better manipulation of its resources. In computer jargon, it’s called reentrant programming. Reentrant programs realize a simple form of multitasking while minimizing memory overhead. When you consider running a number [x] of tasks of similar functionality, each of which requiring [y] memory bytes to run, you may think at ﬁrst glance that you would need [x * y] bytes of memory. However, with reentrancy, you would actually require only a fraction [?] of memory over and above that of a single task, giving a total of [(1 + ?) * y] bytes for the [x] tasks. Figure 5 illustrates the reentrant program concept as a special case of multitasking, which was demonstrated in Figure 4. Here, all tasks are similar in functionality and are represented 16 by a single reentrant program. The scheduler switches the execution of this program among the distinct tasks upon interrupt events. A reentrant program is a generic data-driven task. If you manage to separate the task data from the code and make the code register-dependent, you can end-up with a generic task. Having done this, another question arises: how can user tasks invoke their reentrant program simultaneously? The answer is twofold: • • First, you must initialize the registers of the generic task with each task’s data. Second, you need some mechanism, such as interrupts, to switch the generic task between user tasks. A user task gaining control of the generic task loads its processor state (its registers’ settings) and resumes its previously interrupted operation. But that only happens after it the user task saves its predecessor state. The task in control of the processor may set a pointer to its descendant task to take over control when the interrupt occurs. SYSTEM LIMITATIONS My ﬁrst encounter with microcontrollers was the Microchip’s PIC18F452 MCU. It was a challenge to implement my version of multitasking on such a device. I was faced with limitations that required a workaround that costs memory and execution time. I didn’t encounter such limitations while working with those ancient microprocessor devices. On one hand, most of the PIC data transfer and arithmetic instructions involve the W register. To facilitate indirect addressing on a PIC, the address must ﬁrst be loaded into the FSR register. This makes a stack implementation inefﬁcient, comprising many instructions for one indirect memory access. The programmer has to work around this by passing parameters in ﬁxed memory locations. The PIC’s small hardware return stack allows only minor nesting of calls, so the program structure is almost ﬂat, relying on macros. Also, the PIC lacks support for automatically saving and restoring its state on interrupts. This makes interrupt processing extremely delicate. It’s up to the programmer to save the processor state JANUARY – FEBRUARY 2008 | embedded systems design europe | www.embedded.com/europe 013-014-016-017_ESDE.indd 16 7/02/08 11:38:52 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.