Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 119 of 197

.. #include typedef struct { II InternaL state for the moduLe goes here. } tbaLLLocaL_t; PBO_MODULE(tbaLL) int tbaLLInit(tbaLLLocaL_t *Local) { I I ModuLe-specific initiaLization goes here return (int ) LocaL; } int tbaLLCycLe(tbaLLLocaL_t *LocaL) { SVAILOUT(xd) ; I I ModuLe-specific 'cycLe' code goes here return PBO_OK; } . Most im ortant to form of the PBO_MODULE macro, and how substitution of xyz for car results in the desired declarations (## is the C preprocessor token pasting operator; it is part of ANSI C) . The macro also defin es the fun ction prototypes for each method, so that when the code is compiled, if the user 's code does not match what is expected by the frame- work, compiler warnings or errors will be generated . A software component then only needs to #i ncLude , and call the macro before defining the func- tions. An example is given in Listing 2. It is an excerpt of the module t ba LL, that shows the header information, and the ini t and cycLe fun ctions (the two most complex functions of most modules). A li st of the xyzFunc structure for input and output ports, and calling the use r-defined init me thod . The process then waits in the OFF state, and can be viewed as being in a standby mode for a dynamic reconfiguration. When an ON signal is received, the local table is updated to reflect the current state of the system, and execu- tion begins. Implementation of the framework The fram ework is defin ed in two parts: heade r informatio n including data structures and function proto types that enforce the interface between the PBOs and the framework, and the code that executes the FSM that was shown in Figure 6. We provide a sample of the frame- work header file in Listing 1; this code would go in th e fil e pbo. h, to be #i ncLuded by every sofnvare compo· nent. Note that th is fram ework code only needs to be written once, and can be used from o ne application to another. The heade r fil e defin es th e pboFunc_t structure that will contain a pointer to each of the functions of the PBO. PBO_MODULE (xyz ) is a macro that expands into all of the declarations needed by the software component, and allows the compiler to enforce the API of the component. The expansion of this macro is one of the keys to cre- ating componen t-based software, and is illustrated in more de tail in Figure 7. On the left side of this diagram, the framework process only knows about components based o n their functions. In this example, the o bject "car" is plugged into the framework. To do so, the structure carFunc needs to be defin ed. This structure is defin ed by placing PBO_MODULE(car) in the decla- rations part of the file car . c. The right side of the diagram shows the generic 118 DECEMBER 2000 Embedded Systems Programming each PBO can then be maintained, either statically (that is, an array) or dynamically (that is, a linked list). The list can also include additional info r- mation about the object needed for real-time scheduling, such as period and priori ty. In the non-preemptive case, the framework itself does sched- uling and selects one of the objects from the list. In the preemptive case, a new thread is created for each object in the list, and the underlying RTOS takes care of all the scheduling. Due to space limitations, it is not possible to show the entire code for the framework process shown in Figure 6. Instead, we show the frame· work code that surrounds calling the LJcle routine, which is the main body of any object. In Figure 8, tIl e code fo r a preemp- system is shown. The tive svarCopyXxShm fun ctions are the inter- process communication mechanism (more on this later). The code is a loop that blocks at the beginning. If the task is periodic, it calls pauseO, which is an RTOS fun ction to wait for tIle next sta rt time. ! 16! If the task is aperiodic, it calls tIle sync 0 me thod, where user·defin ed blocking (such as waiting for a message) can be defi ned . When the signal is received, data is

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13