EETimes

Embedded Systems September 2000 Vol13_10

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

Contents of this Issue

Navigation

Page 153 of 229

How do we achieve different execution speeds if the functions are called from the same control loop? loop represents an independent task • Each of these tasks must return in a reasonable time, no matter what thread of code is being executed • We have no idea a t what frequen- cy our main loop runs. In fact, the frequency is not constant and can significantly change with th e changes in sys tem status (as we a re printing a long docume nt or LISnNG 4 Sending ari eitenqq II somewhere in R$232 module OUTPUT_EVENT_TYPE OutputEvent; OutputEvent.NewState = 1; Output Event .Nurber = 1; OUTPUT_PutEventC&outputEvent); d isp laying a la rge bitmap , fo r example) So what happens inside the functions called from our infin ite loop? The majority of tasks in our system are eve nt-driven tasks. They do not execute until a sui table message is received. Each of these tasks has a ded- icated input event queue. For exam- ple, IO_processOutputs is an event-di-i- ven task. It handles the state of outputs and does nothing if there are no state changes to be performed on the out- puts. However, if an output needs to be turned on, an event message is sent to this task. In our system, three tasks will send event messages to the IO_processOutputs: • The input scanner ( IO_Scan) task, when input state change d ictates an output state change • The RS-232 receive task, when an RS-232 message is • The keypad scanner received , requesting an output to be turned on/ off task, (KBD_Scan), when an entry is com- pleted with the request to turn on/ off an output I I new state - on I I turn on output nlJTber one II inject an event The handling of the events inside IO_ProcessOutputs is exactly the same, no matter which of the three tasks has sent the event. (The event- driven task structure is described in the next section.) Other tasks in our system are peri- I I this task is called from main control Loop void IO_frocessOutputsCvoid) { word ret; OUTPUT_EVENT_TYPE OutputEvent; II our normal execution counter processing goes here .. II II end of execution counter processing if ((ret = OUTPUT_GetEventC&outputEvent) != EMPTY) { II buffer not empty II process OutputEvent } } turn on/off the required output IO_OutputStateChange(OutputEvent.Number, OutputEvent.NewState) odic. They run without a trigger event. Some need to run faster, others slower. For example, we may need to scan the inputs at a much faster rate than the LCD update. How do we achieve dif- ferent execution speeds if the func- tions are called from the same control loop? I have also promised to provide some simple means of in ter-task com- munications. For example, we may want to stop scann ing th e inputs afte r a particu la r keypad entry and resta rt the scanning after anothe r entry. This would require a call from a keypad scanner to stop the 1/0 scanner task. We may also want to slow down the execution of some tasks depe nding o n the circum- sta nces. Le t 's say we de tect an avalanche of input sta te changes, and our RS-232 link can no longer cope with sending all th ese messages. As a solution, we would li ke to slow down 152 SEPTEMBER 2ooo Embedded Systems Programming

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10