Embedded Systems September 2000 Vol13_10

Issue link:

Contents of this Issue


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