Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 43 of 197

How will your program behave if a mechanical or electrical part breaks? Provide for timeouts, sanity checks, and so on. FIGURE 2 'A state machine fragment that does gear lever = up && not on ground I pump on. dir ----------~.~, Gear Down Start / I gear lever = down I pump on, dir Good thing, too-otherwise you would be unnecessary! • How will your program behave if a mechan ical or electrical part breaks? Provide for timeouts, sanity checks, and so on We can now suggest the fo llowing state machine to the user, building upon his ) -equirements by adding a few states and transitions at a time. The result is shown in Figure 3. Here, we want to preclude gear retraction until the airplane is definitely air- borne, by waiting a couple of seconds after the squat switch opens. We also want to respond to a rising edge of the pilot's lever, rather than a level, so that FIGURE J pilot's lever rising edge && squaCswitch = AIRI start timer, lights = RED /-- ----------~.~I Gear Down Start / squat switch = GND or pilot's lever down I restart timer All 3 down switches madel pump off, lights = GREEN ./ Gear Up . All 3 up switches are / made Ipump off, ./ extinguish lights pilot's lever down !lights = RED, pump on, dir = DOWN / / ( RaisingGear ~---- timer = 2 sec./pump on, dir = UP = up ( RaiSingGear I \ , = down we rule out the "someone moved the lever while the airplane was parked" problem. Also, we take into account that the pi lot might change his mind. Remember, the landing gear takes a few seconds to retract or extend, and we have to handle the case where the pilot reversed the lever during the process. Note, too, that if the airplane touches down again while we' re in the "Waiting for takeoff' state, the timer restarts-the airplane has to be air- borne fOl- two seconds before we'll retract the gear. Implementation This is a good point to inu-oduce a clean way to code a finite state .... .. .... machine. Listing 1 is my implementa- tion of the state machine in Figure 3. Let's discuss a few features of the example code. First, you 'll notice that the functionality of each individual state i implemented by its own C func- tion. You could just as easily imple- ment it as a switch statement, with a separate case for each state. However, this can lead to a very long function (imagine 10 or 20 lines of code per state for each of 20 or 30 states.) It can also lead you astray when you change the code late in the testing phase- pe rhaps you 've never forgotten a break statement at the end of a case, but I sure have. Having one state's code "fall into" the next state's code is usually a no-no. To avoid the sw; tch statement, you can use an array of pointers to the individual state functions. The index in to the array is the curr _st a t e, which is declared as an enumerated type to help our tools enforce correcmess. For simplicity, all the hardware I/O (reading switches, turning pumps on and off, and so on) is represented as a sim pie variable access. It's assumed that these variables are "magic addresses" that are associated with the hardware through invisible means. The next obvious thing is that the 42 DECEMBER 2000 Embedded Systems Programming

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13