EETimes

Embedded Systems December 2000 Vol13_13

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

Contents of this Issue

Navigation

Page 131 of 197

lated within a software component of an I/ O element. Draw the I/O elements (on paper, blackboard, or using a compute r draw- ing tool-whichever is preferred) such that all the input elements are on the left, and all the output elements are o n the right. Each module should be drawn as a box with rounded corners and the I/O item entering or exiting from the bottom for an input or out- put module respectively, as shown in Figure 12. Give each module a name that reflects the I/O element. For example, in a cruise control sys- tem, the outputs are the forces to be applied to the engine (how much gas to give), the forces applied to the wheels (how much to press the brake), and output to the dashboard (the speedometer and odometer). These are shown in Figure 13. The remain- der of this example builds upon this diagram. If an I/O element has both input and output, then split the element into two pieces, with input on the left, output on the right. Later in the design, the modules can be merged so that both input and output are imple- mented as a single component. Many times, a decision has to be fde --OC~(====e== ne=~~J Force to engine ng=i== fdw --(C wheels Force to wheels ') Speedometer Odometer wo alternatives for comRonents that generate fde ( control )~ l control • • . • (t fdw .( split-pm (_whee~) Force to wheels t 130 DECEMBER 2000 Embedded Systems Programming . . engine Force to engine wheels Force to wheels • • J J made as to what level of granularity should be made at th is step. Suppose there are eight input switches; should th is be eight separate I/O modules? Or a single module th at has an 8-bit parallel input? As a general rule, if each switch has similar functionality (for example, each switch controls a light) then keep them together. If the switches are used for different func- tionality (one is for a light, a second turns on a motol~ and so on) then split them up. Either way, refin ements of the design can be made throughout; it is not important to get the perfect design first try. These guidelines sim- ply provide a starting point. Communication with another sub- system should also be viewed as an I/O element. For example, the dashboard that contains the speedometer might be a separate subsys tem. The speedometer and odometer compo- nents of the dashboard, howevel~ are sti ll modeled the same way, because at this point, each component is sti ll independent of the target hardware platform. Determine inp uts to output components Once all of the I/ O components are defined, the diagram is to be filled in from right to left, that is, start with the output modules, and work back towards the input modul es. To begin, define the input ports of each output module. For the cruise-control exam- pl e, this means the engine, wheels, and dashboard modules, as shown in Figure 14. The inputs are variables with stan- dard uni ts that are to be sent o r applied to the output I/ O element.

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13