EETimes

Embedded Systems September 2000 Vol13_10

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

Contents of this Issue

Navigation

Page 151 of 229

LISTING 3, cont'd. word PutEvent { if >; if = BUFFE~SIZE- 1> { } else { EventBuf.lnPtr++; } return (010; } return ; } EventBuf.InPtr = 0; executed at a pre-defined speed. Depending on the requirement, this speed can be either exactly defined or relative to the speed of execution of the main control loop • Some basic means of inter-task communications are provided. These include stopping and restart- ing tasks, slowing them down, and speeding them up • Software timers provide a conve- nient method of performing a vari- ety of duties that require exact tim- ing (for example, flash a cursor at a fixed rate). The software timers can be one-shot or run foreve1· In addition, as our system is not pre-emptive (tasks cannot be inter- rupted by another task ) we have the luxury of not worrying about protect- ing our data with semaphores/ mutex- es. All of our tasks relinquish control only when the entry function of the task returns. As an example, let's consider an Optimizing C Compiler Integrated Development Environment Built-in Macro Assembler BCiink Linker Runs under: Windows 95/98/NT. Also available for DOS, HP-UX ) Byte Craft Limited 421 King,>treet North Waterloo, Ontario Canada N2J 4E4 embedded system with a keypad, an LCD, and an R.S-232 port that runs some comms. The system also has some l/0 and a parallel printer. Each change of state of an input or output results in an RS-232 message sent out, a printout, and an LCD update. Received RS-232 messages can result in printouts, LCD updates, and output status updates. We may have to start a flash pattern on a particular lamp as a result of: • An input or output becoming active (fridge door open) • Keypad entry (defrost schedule entered), • Comms message received (the owner is e-mailing us to cool the beer down just before he arrives) Let's have a quick look at our main UMITEC control loop in Listing l. Nothing new or original here. Three things are immediately obvious: • Each function called in our infinite 150 SEPTEMBER 2000 Embedded Systems Programming

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10