Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 123 of 197

n o 51 Every I/O port and configuration constant is defined as a state variable (SVAR) in the global table, which is stored in shared memory_ Framework code surrounding tlie Duplicating messages based on the number of recipients also violates the port-automaton theol)', which states that a process is unaware of the destination of the data on its outpu t ports • The overhead with sending mes- sages- especially in a multiproces- or environment-is much higher EngueueNode and tJlan that achievable using shared memory. This factor is especially important consider ing some data must be transferred 1,000 times per second while (1) { do { etimeClock{&now}; I I Move newly awoken tasks from PauseQ to ReadyQ while (!Empty(pause!) && etimeCompare(SchedTIme(pauseQ}.now) <= 0) { DequeueNode{&pauseQ. &pbo}; etimeAdd(&pbo->schedtime.pbo->period); EnqueueNode(&readyQ. pbo}; } } while ( == NULL); IIHead of readyQ has earliest-deadline tas DequeueNode(&readyQ. &pbo}; pbo->func->cycle(pbo}; if (pbo->tasktype == PBO_PERIODIC) EnqueueNode(&pauseQ.pbo); else pbo->func->sync(pbo); wakeup Periodic etime Aperiodic • These drawback of message pass ing systems led to tJle design of a mecha- nism based on shared memOl)" using the state variable table communica- tion that is now described. -Y'J .. external signal • Support transparent multiprocess- ing, so that objects can be either on the same or different processors, without any difference in the com- munication interface. Any differ- ences must be encapsulated within the IUOS • Al low communication between proces es that may be executing at diffe ren t frequencies Communication between compo- nents may seem like a nanlral candi- date for message passing. However, message passing was not used for sev- eral reasons: • The port-automaton theOl), cannot be supported with messages because the most recent data is not always readi ly availabl e. FOI- exam- ple, if the process producing the data is faster, then the messages may be queued, and the message received by the consumer might not contain the most recent data • Fanning an output to multiple inputs is diffi cult because it requires a message to be duplicated for each input or requires a more complex mechanism to ensure that no message is deleted until all processes need ing it have used it. 122 DECEMBER 2000 Embedded Syst ems Programming State variable communication The communication between PBOs is performed via state variables stored in global and local tables, as shown in Figure 10. Evel), 1/0 port and config- uration constant is defined as a state val-iable (SVAR) in the global table, which is stored in shared memory. Figure 10 shows the contents of the global and local tables fOl- the sample configuration that was illusu-ated in Figure 3a. A PBO can only access the local table, where only the subset of data from the global table that is needed by that PBO is ke pt. ince every PBO has its own local table, no synchronization is needed to read from or write to it. A PBO process can thus execute inde- pendently of other processes by using the data in its local table. Consistency between the global and local tables is maintained by the SVAR mechanism. When a non-p reem ptive real-time executive is used instead of an RTOS, tllere is no need [or tile local table, as shown in Figure 11. Each PBO points directly to tile global ta ble, and prop- er mutual excl usion is achieved through not allowing preemption in the middle of a process's cycle routine. This significantJy recluces overhead, allowing for the PBO model to be used

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13