Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 115 of 197

~ n o a Component-based software support is realized by creating a single, standard process that we call the framework process (pboframe). Only when necessary, th e RTOS invokes a method of one of the soft- ware components to execute applica- tion code. In th is section, we provide more details on the framework. In particu- lar, we show how to create a frame- work for both periodic and aperiodic tasks, in both non-preemptive and pre- emptive environme nts. Typically a non-preemptive approach is used for low-end processor environments that cannot afford the overhead of a full RTOS. The framework for the preemptive approach can be imple- me nted as middleware, to ope rate with your favorite RTOS. The differ- ence in the approaches is ill ustrated in Figure 5. The non-preemptive case has only a single context, and each object is plugged in as it is needed. For the preemptive case, the context of the framewo rk is replicated for each task, and a PBO is bound to that framework for the lifetime of the task. The details of the framework follow in the remain- der of this section. The framework process Component-based software support is realized by creating a single, standard process that we call the jmrner.lIo-rk process (pboframe). Both periodic and aperiodic processes in the system use this same framework. The process l)boframe takes a PBO as an argument. The PBO defin es the module-specific code, including the input and output ports, configuratio n constan ts, the lype of process (for example, periodic tJTOCeSS or aperiodic server), and the tim- ing parameters such as frequency, deadline, and priori ty. The framework process imple- ments a finite state machine with three stales, as shown in Figure 6. The tates FIGURE 7 EXRansion of the PBO_MODULE macro used to enforce tlie int xyz##Cycle(xyz##_t * loc) PBO _MODU lE(car) E.G.: . . -. --- --. '-. '- -.......... -.. --- I----... '~ carCycle ~---...., : :'t' .. -- ' I .. '. ' typedef int ( *pboFunc_t)(void * ); - typedef struct { pboFunc_t pboFunc_t pboFunc_t pboFunc_t pboFunc_t pboFunc_t } pboFunc_t ; init ; on; cycle; sync; off; term; }; -- - 114 DECEMBER 2000 Embedded Systems Programming \ ,~==-----=====~~ pboFunc_t carFunc = { , , , , , , IcarTerm, f',. ". .. carinit, carOn, carCycle, carSync, carOff, ..... }; ~:~~ carOff carTerm carFunc pbo xyz##Func_t xyz##Func = { xyz##lnit, xyz##On, xyz##Cycle, xyz##Sync, xyz##Off, xyz##Term, . , , ~ ~ mt carCycle(cac t * loc) "- --. , , -" -" .......... I----~, ~ ca~nc .~-----4 I------i:'"'.~' . . . , I are shown as bold ell ipses, and are NOT_CREATED, ON, and OFF. Extensions to include an error state can be found in [19]. State transitions are shown in the diagram as process flow diagrams. A state transition is triggered by a sig- nal (drawn as solid bars). Signals may originate from interrupts, a planning module, an external subsystem, or from the user through a graphical user interface. In response to a signal, a data trans- fer is made to receive data from other obj ects. One of the use r-defi ned func- tions is then called, followed byanoth- e r transfer to send data to oth e r obj ects. The PBO method that is called depends on the state of the process and the signal that is received. For example, if a PBO is in the ON state, and it receives a wakeup signal, then it will execute the cycle method and remain in the ON state. On the other hand, if the PBO i in the ON state, and receives the kill signal, then it will exe- cute the oJ! method, followed by the typedef int ( *xyz##Func_t)(xyz##_t * ); xyz##Func_f xyz##lnit J

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13