Embedded Systems September 2000 Vol13_10

Issue link:

Contents of this Issue


Page 149 of 229

On the other hand, if you decide LISTING l Input event structure typedef unsigned int word; typedef struct { word InPtr; word OutPtr; word Count; EVENT_TYPE Store[BUFFER_SIZEJ; } INPUT_EVENT_QUEUE_TYPE; I* Head of buffer *I I* Tail of buffer *I I* Counter *I I* Actual data buffer space *I to take a short cut and not use an RTOS in a system where you really need one, things will be much worse. You will find that your software is get- ting more and more clumsy, the sys- tem keeps falling over and hangs in the most unexpected places, until fin ally you call it a day and start again from the scratch , using a few pieces of code you can salvage from the mess. To find th e right ba lance, it's #define OK lldefine EMPTY #define FULL 0 OxFFFF OxFFFF INPUT_EVENT_QUEUE_TYPE EventBuf; void InitEventBufferCvoid) . { EventBuf.InPtr = 0; EventBuf .OutPtr = 0; EventBuf.Count = 0; } static word GetEventCEVENT_TYPE *event) { if CEventBuf.Count) { EventBuf.Count--; II copy from the buffer memcpy(event,&EventBuf.Store[EventBuf.OutPtrJ,sizeofCEVENT_TYPE)); if CEventBuf.OutPtr >= BUFFER_SIZE- 1) { } EventBuf.OutPtr = 0; else { EventBuf.OutPtr++; } return (OK); } return (EMPTY); } importa nt to realize that a system wi thout a n RTOS can exhibit multi- tas kin g be havio r. It seems to me tha t often th e main reaso n behind a deci- sion to po rt an RTOS whe re it is unnecessary i the lack of unde r- standing that by using some simple means and some no t-so-complex code, an effi cie nt, fas t, and reason- ably ba lanced sys tem can be built. Mo reove r, sho u ld a n RTOS be required some tim e in th e future, thi s is no lo nger a painful exercise, as th e sys tem can be e ngineered as se lf-conta in ed tas ks, eve n in th e absence o f a "true" RTOS. In the fol- lowing sections, I will describe such a system. Main control loop Our system exhibi ts a set of neat fea- tures, which are normally attributed to tl1e existence of an RTOS: • The software is broken into stand- alone, well-defin ed tasks. It is per- fectly valid to say tl1at a particular fun ction belongs to a particular task, and the same can be said about data structures • Event-driven tasks are supported. These tasks have input event queue and execute only when a suitable "trigger" event arrives. Otherwise, these tasks are idle and consume very li ttle processing time • All tasks may send event messages to event-driven tasks Listing 3 continued on p. 150 148 SEPTEMBER 2000 Embedded Systems Programming • Periodic tasks ( tl1at is, tasks tllat do not require a trigger to run ) can be

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10