EETimes

Embedded Systems September 2000 Vol13_10

Issue link: http://dc.ee.ubm-us.com/i/71837

Contents of this Issue

Navigation

Page 159 of 229

The reason for using a variable rather than a constant for reload value is that this helps us to dynamically manipulate the execution speed of the task. we really only need to do it every second? • We don 't wan t to delay the execu- tion of other tasks for too long LlmNG 7 • • void MEMORY_Check(void) { static unsigned int State = 0; static unsigned int Csum; byte *Ptr; II the usual exec counter processing goes here if (State = Q) { II zero the csum Csum = 0; } II derive the memory pointer Ptr = (void *)(RAM_START + State*100); II do CRC 100 bytes at each II iteration AddToCsumC&Csum, Ptr, 100>; if (++State = 100) { if CCsum != GetRAMCsumO) II error PanicO; State = 0; } } csum mismatches do something me ory checking In regards to the first problem, a mechanism is available to help slow down the tasks. This can be done in terms relative to the main control loop, or in absolute terms (we will call it exact timing). In both cases, we need two variables per task. One is called an execution counter and the other reload value. Th e execution counter counts down from reload value. When it reaches zero, the task is called, oth erwise the entry function to the task exits wi thout further process- in g. The reason fo r using a variable rather than a constant for reload value is that this helps us to dynamically manipulate the execution speed of the task. See Listing 6. Some poin ts about the code: • In the exact timing system, the exe- cution counter is decremented in a fixed frequency interrupt routine, while in relative timing system the task itself decrements the counter. In an exact frequency system, we know how frequently our task will execute (minus the la te ncy of other tasks). By setting FIGURE ::2 State-driven LCD update task-the state transition Updat: scr~~-~-- -,~ variable data ::: '- Update screen constant data J ] _______ _..I LCD_TASK_FREQUENCY to 100, and using a lOms interrupt, we know that our task will execute every sec- ond plus the execution time of other tasks that may have been called before ours, but after tl1e LCD tasks execution counte r was decremented to 0 • The vol at iLe keyword wi ll prevent optimizatio n by the compile r. Some optimizing compilers will otherwise (in an exact timing sys- tem) LCD assume th at the _ExecCounter will always be set to a non-zero value, especially if the lOms interrupt handler is coded in a diffe rent fi le • TASK_ DISABLED will be #defined to the largest possible unsigned inte- ger. Setting the execution counter 158 SEPTEMBER 2000 Embedded Systems Programming

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10