Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 45 of 197

LISTING 1 typedef enun {GEAR_DOWN = 0, WTG_FOR_TKOFF, RAISING_GEAR, GEAR_UP, LOWERING_GEAR} State_Type; 1* This table contains a pointer to the function to call in each state.*1 void (*state_table[])() = {GearDown, WtgForTakeoff, RaisingGear, GearUp, LoweringGear}; State_Type curr_state; mainO { InitializeLdgGearSM(); 1* The heart of the state machine is this one loop. The function corresponding to the current state is called once per iteration. *1 whi le (1) { state_table[curr_state](); DecrementTimer(); 1* Do other functions, not related to this state machine.*1 } } , . void InitializeLdgGearSM() { curr_state = GEA~DOWN; timer = 0.0; 1* Stop all the hardware, turn off the lights, etc.*1 } void GearDownO { 1* Raise the gear ~ coomand, but not if the airplane is on the ground.*1 if «gear_lever == UP) && (prev...9E!ar_lever == DOo'N) && (squat_switch == UP» { } , . } void RaisingGear() { 1* Once all 3 legs are up, go to the GEAR_UP state.*1 if «nosegear _i S_LIp MADE» == MADE) && (leftgear _i S_LIp { Listing 1 continued on p. 46 44 DECEMBER 2000 Embedded Systems Programming == MADE) && (rtgear _i S_LIp timer = 2.0; curr _state = WTG_FO~TKOFF; prev-gear_lever = gear_lever; 1* Store for edge detection.*1 code doesn 't do much at this point. It just t1-ansitions from state to state. Thi is an important intermediate step, and you shouldn 't skip it lightly. IL would be a good idea to add some #i fdef DEBUG'd print statements tllat cause each fun ction to prin t "I'm in tate xxx" as well as tlle value of me inputs. Half the battle is in the code that induces the state transitions, tllat is, detecting that me input events have occurred. Once the code is cycling mrough states cOiTectly, tlle next step is to fill in the "meat" of tlle code, namely mat which produces the out- put. Remember that each t1-ansitio n has an input (me event that caused it) , and an output (me hardware I/O, in o ur example) . It is. often helpful to write this down as a state t1-ansition table. Keller and Shumate use a for- mat similar to the one in Table 1, to which I've added an explicit listing of all tlle inputs and outputs.3 Here, we ' ll fill out the state transitions. There is one line per state transi- tion in me state t1-ansition table. In our re la tive ly simple example, th e "action" code is a very direct mapping from the state transitio n tabl e. This, as you can imagine, is not always the case. In coding a state machin e, try to preserve its greate ·t trength, name- ly, th e e loque ntly vi sibl e ma tch between th e use r 's requireme nts and th e code. It may be necessary to hide hardware de tails in another layer of fun cti ons, fo r in lance, to keep the sta te machin e 's cod e looking as much as possible like the sta te tran- sition table and the sta te transition diagram. That symmetry helps pre- ve nt mista kes, and is the reason why sta te machines are such an impo r- tant pa rt of the embedded software e ngineer 's a rse nal. Sure, you could do the same thing by se tting fl ags and having countless nested if state- ments, but it wo uld be much ha rde r to look at th e code and compare it to wha t the lIser wants . The code frag- me n t in Listing 2 fl eshes out the Ra; s; ngGearO fun ctio n.

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13