Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 121 of 197

i s a o /D = ~ Integrating software components such that all communication is performed in a predictable and timely manner is perhaps the most difficult aspect of creating component-based real-time systems. different screens o r menus to quickly create and modify code for an embed- ded display device. The display man- ager itself is a PBO, which enables it to interface to the rest of the system. The cycle mutine of the display manager can itself be a framework for a differ- ent class of objects, in this case menu obj ects. The framework is speci ficall ), pboFrame(*pbo) ( pbo pboFrame(pbo) { :-----:--.----.--------------------------- ~.-~- start = clock(); while (pbo->state ==PBO_ON){ if (tasktype == PBO_PERIODIC){ start += pbo->preiod; pause(start,pbo->period); } else { pbo->func->sync(pbo->Iocal); svarCopyFromShm(pbo->vartable); pbo->func->cycle(pbo->Iocal); svarCopyToShm(pbo->vartable); ~, .. ------------------.----.-.. ON , , (, out-vars> ./ , -~, I cycle :J wakeup , d esigned usin g C, because man)' embedded sys tem programmers are not expe rts in object-or iented design or C++. Rather, they are experts in th e application area, and are more familiar with C than C++. The frame- work likely uses less overhead than C++ o bjects, but we have not yet do ne actual performance comparisons. We have do ne performance benchmark- ing of th e non-preemptive frame- work on an 8MHz Motorola 68HC12, and found that the overhead of swi tching between objects is less than lOOps. external signal Inter-object communication Integrating software components such that all communication is performed in a predictable and timely manner is perhaps the most difficult aspect of creating com po nen t-based real-time systems. In order to support the PBO model, a communication mechanism was designed that meets the following requirements for embedded control systems: copied from shared memory, processed by calling the object's eycLeO routine, and the output data copied back in to shared memory. Figure 9 shows the fram ework for a non-preemptive sys tem. While this code is a bit more complicated than for the preemptive case, keep in mind the code does th e scheduling and eliminates the need for an underlying RTOS. The do-loop at the beginning of the main loop performs an earliest- deadline-first (EDF) scheduling to obtain the next task to execute. Other scheduling algorithms [or non-pre- emptive systems can also be imple- me nted at th is point instead of EDF. Once the object to execute is selected, the eye LeO routine is called. Since there is no preemption, there is no need for a complex IPC mechanism that maintains integl-ity of global data; instead, each o bject d irectly uses pointe rs to the shared data. Summary of framework process While the fram ework shown is designed for conu-ol system compo- nents. A similar approach can be used to integrate other types of compo- nents too. For example, a display sub- system would al low the user to plug in 120 DECEMBER 2000 Embedded Syst ems Programming • Support the po rt-automaton model of independent processes. That is, read the input ports at the begin- ning of each cycle to obtain the most recent data available, and write to the output ports at the end of each cycle • Target data u-ansfers with low vol- ume (less than 100 bytes per trans- fer) but at ( l ,OOOHz) high frequency • Have a simple and su-aightforward binding scheme for input and out- put ports, to enable dynamic recon- fi guration in bounded time • Fan an output into multiple inpu ts

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13