Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 51 of 197

Once the user's requirements are fleshed out, I can crank out a state machine of this complexity in a couple of days. They almost always do what I want them to do. source-level debugger, or build an "input poke r" uti li ty that lets you write the values of the inputs in to your application. This requires a fair amount of patience and coffee, because even a mid-size state machine can have 100 different transitions. Howeve r, the number of transitions is an excellent measure of the system's complexity. The complexity is driven by the user's requiremen ts: the state machine makes it blindingly obvious how much you have to test. With a less-organized approach, the amount of testing required might be equally large- you just won't know it. It is very handy to include print statements that output the curre nt tate, the value of the inputs, and the value of the outputs each time through the loop. This lets you easily observe what ought to be the Golden Rule of Software Testing: don't just check that it does what you want- also check that it doesn't do what you don't want. In other words, are you getting only the outputs that you expect? It's easy to ve r- ify that you get the outputs that you expected, but what el'e is happening? Are there "glitch" state transitions, that i , states that are passed through inad- verten tly, fo r on Iy one cycle of the loop? Are any outputs changing when you didn 't expect them to? Ideally, the out- put of your printfs would look a lot like the state transition table. Fi nall y, and th is applies to all embedded software and not just to that based on state machines, be sus- picious when you connect your soft- ware to the actual hardware for the first time. It's very easy to get the polari ty wrong- "Oh, I thought a '1' meant raise the gear and a '0' meant lower the gear." On many occasions, my hardware counte rpart inserted a temporary "chicken switch" to protect his precious components until he wa sure my software wasn 't going to move things the wrong way. Crank it Once the user's requirements are fleshed out, I can crank out a state machine of tllis complexity in a couple of days. They almost always do what 1 want them to do. The hard part, of course, is making sure tllatI understand what the user wants, and enswing that tile user knows what he wants-that takes considerably longer! esp Martin Gomez is a software engineer at the Johns Hopkins University Applied Physics Lab, where he is presently developing flight software Jar a solar research spacecraft . He has been working in the field oj embedded soJtware development Jar 17 years. Martin has a BS in aerospace engineering and an MS in plectrical engineering, both Jrom Cornell University. He may be reached at maTtin. PCM-9550F Features 8" x 5.75" - Inlel low power Pentium' MMX'· processor - Supports Video·in and lV-out (PCM·9550FM) - 8 digrtal inputs and 8 digital outputs - Supports XGA & 36·brt LCD - 3D audio & 100 Mbps Ethernet - One PC/l04+ & one mini PCI socket (Type III) AD\-\NTECH E-mail: EBX Form Factor No Cooling Fan Digifall/O Long-term Supply References: 1. Hurst, S.L. The Logical Processing of Digital Signals. New York: Crane, Russak, 1978. 2. Pressman, Roger A. Software Engineering: A Practitioner's Approach, 3rd Edition. New York: McGraw-Hili, 1992. 3. Shumate, Kenneth C. and Marilyn M. Keller. Software Specification and Design: A Disciplined Approach for Real-Time Systems. New York: John Wiley & Sons, 1992. 50 DECEMBER 2000 Embedded Systems Programming

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13