EETimes

Embedded Systems December 2000 Vol13_13

Issue link: http://dc.ee.ubm-us.com/i/71850

Contents of this Issue

Navigation

Page 102 of 197

Reconfigurable components are modular components with the highest degree of modularity. Most important, they are modules designed to have replacement independence. o bject (PBO) abstraction or a compo- ne nt. The techniques do not require a ny pecia l commercial CASE (com- pute r-aid ed softwa re e ngineerin g) tools, and a re compatible with most integra ted d evelopme nt e nviro n- ments and RTOSes. Fo r low-end pro- cessors with out an RTOS, the me th- ods can also be implemented using th e dynamic sch eduling real-tim e executive that is described in this a rticle. Some people believe that software reuse in embedded systems is near impossibl e; nothing can be furth e r from th e truth. It does no t ta ke tremendo us expe ri e nce o r kn owl- edge. Ra th er, the most impo rta nt qua lity needed by the softwa re designe r and programmer to create reusable component-based software is discipline. Th is article provides the details on how to create such a soft- ware system; the discipline is required to follow some of the rul es. The rules do not limit what can be done-they do limit how it is done-to e nsure that the software can be re used . To enfo rce the discipline, formal design and code inspections hould be pe r- formed a t each ste p durin g th e design and impleme ntation phases. I I I Time spe nt on tJlese reviews can easi- ly save five to 10 times as much time debuggin g, both before and after deployme nt. Background Modular vs. reconfigurable software Modular software is characterized by many guidelines, which include a sim- ple structure, da ta e ncapsula tion , functional and informational cohe- sion, separa tio n of th e inter face specificatio n, and the internal be hav- io r implementatio n.I IO, I I,14] The degree ojmodula' surement that describes the extent to which a software module follows these guidelines. For example, a sys tem decomposed into modules may be classified as "somewhat modular" or "highly modular," depending on a software engineer 's assessmen t of how well the module meets the defin ed crite ri a.131 Reconfigumble components are modu- lar components with th e highest degree of modulari ty. Most important, they are modules designed to have replacement independence. In a mod- ular system, there is often on Iy one way to piece all the compone nts togeth er, because the inte rfaces of modules that need to be integrated are designed according to the other modules they interact with . For exam- pl e, if a C or C++ module is written and a . h file of anothe r module is #i ncLuded, then the module becomes dependent on tile interfaces of that other module. In contrast, interface specifications fo r reconfigurable com- ponents are designed according to a pre-defined standard, not according to the interfaces of other modules with which it will be integrated . Inte raction between components occur through these standard inter- faces only. By the above definitions, software components designed according to the PBO model are reconfigurable, because they are modular and have replacement independence. rity refers to a subjective mea- Generic vs. reconfigurable software Reconfigurable software does not nec- essarily imply generic software, for which it is sometimes mistaken. It is possible to have both hardware- and application-dependen t com pone n ts that are not generic, but are reconfig- urable . Class ifi cations of reconfi g- urable softwa re componen ts are defin ed in this section. A generic component is a module that is neither hardware dependelll nor application dependent. The compo- nent can be configured for di.ffe ren t types of hardware, and can be used in di.fferent applications. Ha-rdwaTe-dependent (I-JD) components are software modules th at can only be executed when specific hardware is part of the system. HD components can be of two types: interface compo- nents and computation components. J-JD inte1ace components are used to convert hardware-dependen t signals into hardware-independent data, such that other components can in terface with these modules. The HD interface compone nts re place standard I/O device d rivers, and provide an inter- face to applicatio n hardware such as robotic actuato rs, switches, sensors, and display. They di ffe r from RTOS I/O device drivers because as process- es wi th their own thread of control, they have the same tandard illlerface as other software components, ratJler than being defin ed as system calls that are called through tJle operating sys- tem. The differe nce between o ur device driver model and the tradi- tional module is illustrated in Figure 1. An extensive study of this dl-i- ver model is given in an article by M. Moy and myself, as found in the Real- Time Symposium Proceedings.19] liD comt}utation components provide similar functionali ty as generic com- ponents, bUl with beller performance or added fun ctiona. lity, due to hard- ware-specific optimizatio ns or mod- ifications of tJle generic component. Unlike the inte rface components , they do nOl communicate directly to hard- ware; they are simply dependent on having specific hardware as part of the system. Rather, they in tel-face to the HD in ter face components thro ugh their input and output ports. Embedded Systems Programming DECEMBER 2000 101

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13