EETimes

Embedded Systems December 2000 Vol13_13

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

Contents of this Issue

Navigation

Page 42 of 197

One of the advantages of a state machine is that it forces the programmer to think of all the cases and, therefore, to extract all the required information from the user. has several examples of state transition diagrams used to document the design of a software product. 2 A simple example of a state machine is a protocol parser. Suppose you had to parse a stling of text, look- ing for the token " / 1". Figure 1 shows a state machine to do that. In this example, the first occurrence of a slash produces no output, but causes the machine to advance to the second state. If it encounters a non-slash while in the second state, then it will go back to the first state, because the two slash- es must be adjacent. If it finds a sec- ond slash, however, then it produces the "we're done" output. The state machine approach I rec- ommend proceeds as follows: • Learn what the user wants • Sketch the state transition diagram • Code the ske leton of the state machine, without fi ll ing in the details of the transition actions • Make sure the transitions work properly • Flesh out the transition details • Test An example A more illustrative example is a pro- gram that controls the retraction and extension of an airplane's land- ing gear. While in most airplanes this is done with an electrohydraulic co ntrol mechanism (simply because they do n ' t have a compute r o n board), cases exist- su ch as unmanned air vehicles-where one would impleme nt the control mech- anism in software. Let's describe the hardware in our example so that we can later define the software that controls it. The landing gear on thi s airplane consists of a no e gear, a left main gear, and a right main gear. These are hydrauli- input char = 'f' /no output t \ / v--~" --~ ... input char<> '/' /no output ' cally actuated. An electrically driven hydraulic pump supplies pressure to the hydraulic actuators. Our software can turn the pump on and off. A direction valve is set by the computer to eithe r "up" or "down," to allow the hydraulic pressure to either raise or lower the landing gear. Each leg of the gear has two limit switches: one that closes if the gear is up, and another that closes when it's locked in the down position. To determine if the airplane is on the ground, a li mit switch on the n ose gear strut wi ll close if the weight of the airplane is on the nose gear (commonly referred to as a "squat switch") . The pilot's controls consist of a landing gear up/ down lever and three lights (one per leg) that can either be off, glow green (fo r down) , or glow red (for in transit) . Let us now design the state machine. The first step, and the hard- est, is to figure out what the user real- ly wants the software to do. One of the advantages of a state machine is that it forces the programmer to think of all the cases and, therefore, to extract all the required information from the user. Why do I describe th is as the hardest step? How many times have you been given a one-line problem description similar to this one: don't retract the gear if the airplane is on the ground. input char = 'f' output end signal Find 2nd "/" ~ / Donel Clearly, that's important, but the user thinks he's done. What about all the other cases? Is it okay to retract the gear the instant the airplane leaves the ground? What if it simply bounced a bit due to a bump in the runway? What if the pilot moved the gear lever into the "up" position while he was parked, and subequently takes of£? Should the landing gear then come up? One of tlle advantages of thinking in state machine terms is that you can quickly draw a state transition dia- gram on a whiteboard, in front of the user, and walk him through it. A com- mon notation designates state transi- tions as fo llows: / .2 If we simply designed what the user initially asked us for ("don 't retract the gear if the airplane is on the ground"), what he'd get would look a bit like Figure 2. It would exhibit the "bad" behavior mentioned previously. Keep the fo llowing in mind when designing the state transition diagram (or indeed any embedded algoritllm): • Computers are very fast compared to mechanical hardware- you may have to wait • The mechanical engineer who's describing what he wants probably doesn 't know as much about com- puters or algorithms as you do. Embedded Systems Programming DECEMBER 2000 41

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13