State machines: planning ahead to save time later

Until you have sat down and written a long, involved firmware solution, you probably haven't come to the point of exclaiming: "There has to be a better way!" Using state machines in your code may result in a surprisingly simple solution for code writers. This scenario sounds trivial as a suggestion for the programmer who is proud of that long program that took hours to create and debug. However, you can enjoy numerous advantages with this type of approach. With this method, it is easy to debug the program by using breakpoints with your emulator. You may also use a modular approach in your programming so you can return to any culprit code that is not performing correctly. This approach presents a well-organized code listing that is easy to scan and review on the computer screen or on paper. And finally, this method significantly shortens your code length.

To create a state machine in firmware or software, it is best to draw a diagram (or table) of what your customer (internal or external) wants implemented. This diagram should identify inputs and outputs, states, conditions, and the relationships between these items. The diagram is fairly easy to create. Further, it's easy to troubleshoot because it's right there in front of you. A great place to generate this type of diagram is on a white board, on which you and your customer can quickly see the states, inputs, and outputs of your application (Figure 1).

Take a look, for example, at a real problem in which firmware monitors, records, and communicates the status of a mouse with a host. When you first embark on generating a state-machine diagram, learn and carefully define the end user's objective. In this example, the major task firmware performs is determining whether a user has pushed a mouse button and whether the mouse has moved left, right, up, or down. Additionally, a time restraint exists in this application. One bit of information from the mouse occurs every 1/1200 of a second. If the application exceeds or shortens this timing, the firmware will probably perform a wrong reading. Once the firmware makes that determination, it stores the mouse-position change in five position bytes (for standard mouse-system devices). Firmware then transmits those five bytes through the RS-232 UART port to the host computer at 1200 baud. Figure 1 shows the state-machine diagram for this problem.

Finally, the most important state to include is the return to the main program or the top of the routine. You implement items such as updating the watchdog timer at this stage. The additional code at this juncture could save your program from going to Neverland.

Once you and the customer agree that the state diagram is correct and complete, the next step is to generate the flow diagram for the application. In areas in which the state diagram is more customer-oriented, the flow diagram starts to address the overall structure of your code. At this level, you identify most of the major variables and routines. Following this step, you can easily write and debug the code. However, the key to this approach is that you now have code that you created in a modular fashion. If you include proper comments, you can easily scan this code on paper or on a computer screen when you are debugging your final solution, enhancing future programming projects, or porting to other platforms.

Author Information

Bonnie Baker is the analog/mixed-signal-applications engineering manager for Microchip Technology's microperipherals division. You can reach her at Bonnie.Baker@microchip.com.