EETimes

Embedded Systems September 2000 Vol13_10

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

Contents of this Issue

Navigation

Page 157 of 229

LISTING 6 volatile unsigned int LCD __ ReloadValue volatile unsigned int LCD __ ExecCounter void LCD_frocess(void) { #ifdef EXACT __ TIMING disable<>; #endif if (LCD __ ExecCounter == TASK_p!SABLED) { #ifdef EXACT __ TIMING enableO; #endif return; } #ifdef EXACT __ TIMING II note contention possible with interrupt routine if (LCD __ ExecCounter) #else if (--LCD __ ExecCounter) #endif { #ifdef EXACT __ TIMING enable(); #endif return; } II if we reach this point, we are about to run our task II reload the execution counter LCD __ ExecCounter = LCD __ ReloadValue; #ifdef EXACT __ TIMING enableO; #endif II application task code follows II II end of function } II and this is our fixed time interrupt routine ... interrupt void TIME~IRQ __ 10ms(void) { I I other stuff #ifdef EXACT __ TIMING if ((LCD __ ExecCounter != TASI\._DISABLED) && (LCD __ ExecCounter)) --LCD __ ExecCounter; #endif II other stuff } • We don 't want to call our tasks too often. Why would we call a watch- dog refresh function every 20ms if 156 SEPTEMBER 2ooo Embedded Systems Programming II disable interrupts for a short instance LCD __ TASK __ DEFAULT __ SPEED; LCD __ TASK __ DEFAULT __ SPEED; store up to BUFFER __ SI ZE entries. Any other task, or the task itself , can inject events of EVENT __ TYPE into the input ring buffer. The events will be inse rted at the position of OutPtr, which will grow until the "owner" task executes and reads events from the buffe r. When the task extracts events, the position of InPtr is adjusted . When OutPt r and InPt r are equal, the buffer contains no unprocessed events. The "Count" member contains the num- be r of u nprocessed events in the buffe r. Listing 3 shows the implementa- tion of Ini tEventBuffer, Get Event, and PutEvent. It's quite simple to imagine how othe r tasks would acti- vate the outputs. All they need to do is to construct OUTPUT __ EVENT __ TYPE an eve nt and of call OUTPUT__Put Event, as shown in Listing 4. With all other tasks happily using the OUTPUT __ PutEvent function, the only thing we need to do is implement our output controller task. This is straightforward, as shown in Li ring 5. Note that by simply changing "if' to "while" in th e functi on above we can signifi cantly change the behav- ior of the tas k. Instead of processing one event pe r ite ration of the task, it wi ll process all th e events in th e buffe r. Anoth e r va lid idea would be to implement a mixture of two me th ods, whe re a task extracts a maximum of X events a t a time. Even bette r if X can be changed by o the r tasks. Changes to Listing 5 to implemen t these ideas are straight- forward , and I leave th em to the reade r. Periodic tasks Nothing is stopping us from call ing any function from the main control loop. However, we have to consider two things first:

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10