As a computer science engineering student, one of the early things I learned was the use of state machine diagrams. Following the state machine methodology when doing design work – whether for hardware, a communications protocol, or the software implementation of a communications protocol – has proven invaluable throughout my career. Because I’m a big fan of this approach, I was very interested in last week’s article by Dan Harres over on EDN, “State Machines Ease Programming Microcontrollers.”
For those who aren’t familiar with the state machine process, it’s actually the creation of a diagram (with a math overlay) that sets out all the states and transitions that need to be included in your design.
The example that Dan uses is a simple one – but complex enough to be interesting and to be able to demonstrate the merits of using the state machine methodology.
For his article, Dan’s designing a robot that doesn’t have to do all that much except turn to avoid obstacles. Its electronics are sensors and amplifiers, a microcontroller, and steering and propulsion motor drivers. With these elements in place (at least on paper), it’s time to list out all the possible states the robot might find itself in: moving straight ahead, turning left, or turning right. (No stopping, no slowing down, no turning around. As I said, this is a simple example.)
Anyway, without attempting to give away – or rewrite – Dan’s article, he walks through the process of diagraming the possibilities, which involves coming up with an initial state machine diagram, then thinking it through and realizing that, on the first round, he hadn’t thought through all the possibilities.
When thinking through my state machines, I’ve often found that they get revised in many ways before they’re complete. A good, careful analysis of all the states that are needed in your design is very important. Through the analysis process, you sometimes find that you need additional states, sometimes intermediate states to handle certain situations.
What Dan’s article shows – and what has always been my experience – is that the state machine methodology provides an excellent visual depiction of the how the system you’re designing will operate, allowing you to thoroughly analyze your problem. It’s a true aide for making sure that you have a system reaction to each input, from every state. With your state machine diagram in hand, you’ve covered a lot of ground towards creating a robust design and a roadmap for implementing it.
Dan’s article goes into a lot of detail, and is as good as any I’ve seen for describing how this methodology works. I note, however, that even though the article is targeted towards microcontroller programming, the methodology is applied regularly in more complex microprocessor based embedded system designs. In fact, I’ve only used in on more complex systems, since that’s where the bulk of my work has been.