EETimes

Embedded Systems September 2000 Vol13_10

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

Contents of this Issue

Navigation

Page 161 of 229

The periodic tasks must be written in a manner that will guarantee that they return in a reasonable time. This is not always easy. LISnNG 8 word WinTaskState = WIN_TASK_IDLE; void Window_Update(void) { II .. reload counters go here switch (WinTaskState) { case WIN_TASK_IDLE: return; case WIN_TASK_CONST: UpdateWinConst<>; WinTaskState++; break; case WIN_TASK_VARS: UpdateWinVars(); WinTaskState++; break; case WIN_TASK_GRAPH: UpdateWinGraph(); WinTaskState++; break; case WIN_TASK_ANIMATIONS: if (UpdateWinAnim()) { II all work done, back to idle state .. WinTaskState = WIN_TASK_IDLE; } II if not all animations updated, stay in this state for II a Little while .. break; default: II panic } } a sa mil number of tasks, it's hard to believe that the processor will be struggling to do the comparisons and pre-decrements. It will be a good idea to set this interrupt to a lower priority th an more critical interrupts in your system (or allow it to be pre-empted by other inter- rupts). It is deba ta ble if some neater mechani m sho uld be intro- duced (such as delta queue) to prevent too many counters decre- mented from an interrupt murine. As the number of tasks for the sys- tem of our size rarely exceeds 20 to 30, the delta queue mechanism may be unnecessary (see Software Timers for d iscuss io n of delta queues) • In exact tim ing sys tems, care should be taken to avoid preemp- tion of the task by a fixed-time interrupt routine. The exact mech- anism is CPU- and compiler-specif- ic. In some cases, it may not be a problem, as 16- o r 32-bit reads and writes may be atomic operatio ns. The easie t solutio n is to disable al l interrupts for a short period in the ection of code dealing with the execution counter (as shown in Listing 6, by using "disable" and "enable" function calls). This is acceptable in the vast majority of cases The pe riodic tas ks must be writ- ten in a manner that will guarantee that they re turn in a reasonable tim e . This is not always easy. For example, consider a background memory checkin g task. If the to TASK_DISABLED disables the task until further intervention. This can be done from any other task. For example, an important event can disable o ur printing process until furth er notice (a simple form of inter-task communication ) • Our lOms interrupt is undoubted ly doing a fa ir bit of processing in the exact timing system. Howeve r, with 160 SEPTEMBER 2000 Embedded Systems Programming amo unt of memory to check is large, we wi ll not want to do th e whole chec k in o ne iteratio n, as it may ta ke too lo ng. A useful approach to such tasks is to build them as finite sta te machin es, with each ite ration taking it to the next state . The processin g in each state is limited to the lo ngest permissible time-sli ce. Sample code for memory chec kin g function is shown in Listing 7.

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10