To the uninitiated the words ‘State machine’ sound like something scarily big and complex. They aren’t (necessarily) and can be quite useful. In fact, state machines are no physical machines but a model of processes. They link the states a system can be in with allowed transitions. For example a media player when stopped can change to play or open another file. While playing, it can go to pause, stop, reverse, fast forward and so on. A state machine creates a map of all states and how they are connected. It is an abstract tool hat offers a graphical approach to organizing your code before actually programming.
In his video [Chris Guichet] uses a state machine to debounce a switch for a beginner friendly introduction of the concept. He then shows how to turn the hand drawn map to actual code, including a section on debugging state machines.
State machines are one of the tools that veterans wield easily but often have a hard time to explain to youngsters. This video solves this. For those that prefer to read, we have a thorough explanation in text form at hand. And of course a physical machine with blinkenlights.
18 thoughts on “State Your Intentions More Clearly With State Machines”
“To the uninitiated the words ‘State machine’ sound like something scarily big and complex. ”
Only if they have a political affiliation.
I love abstract tool hats! (LOL)
…or not. That one there be a typo.
Wish I had an abstract tool hat!
You shouldn’t explain a concept that you don’t understand completely. It confuses people. A state machine changes state when a specific event occurs. Also a state machine has two more things, on entry and on exit actions, on entry, the actions that occur when a state machine enters into another state, on exit, the actions that occur when you leave a state, to enter another. Ex: wait state, on entry, start a timer (or counter) for 5 seconds, enter the state, change state when timer is finished (the event to change state), on exit, stop the timer (or reset counter), move on to the next on entry action for the next state.
Started watching the video, got as far as the first sentence which was completely untrue so stopped at that point.
If you want to understand state machines you should design from the state machine into basic logic gates not some programming language. This guy seems to think you can’t use it for that. Maybe that’s why he seems to think it needs really basic explanations about what it is when in reality is is as simple as logic gets.
Nice video, but switch/case for state machine is plain evil, please dont use it. (because you will never be able to keep up as the SM grows)
Use some abstraction language+code generator for it, like the nice State Machine Compiler: http://smc.sourceforge.net/
It even generate nice diagrams.
Au contraire. For people just learning about state machines, hand coding one, and learning what restrictions that imposes and etc, can be significantly more informative.
‘Spaghetti and Meatballs’ have very limited utility as the number of states and transitions increase. Nowadays, we use transition tables, which pretty much anyone can follow (esp. customers).
We used to use this. Array with structs and typedef with pointer to function. Very elegant solution.
Simple (non centrally connected) traffic light made the concept easy to a driver in the US. Sequencing, prohibited combinations, timing,etc. repeat.
Flowcharts anyone? Then build logic gates or code it…
Flowcharts are for sissies who want clean, logical code that others can follow
Did I hear Christian right? The “bug-fixed” version of the debounced switch doesn’t trigger until you take your finger _OFF_ the button???
Surely that can’t be right. What happens if you just keep the button pressed for a minute — or an hour? Users expect things to happen when the button is PUSHED, not released.
You did hear it right, I suppose it is a safe method for industrial uses. For low latency switches it’s best to trigger immediately on press and then debounce after the wait period.
IMHO, it’s a _TERRIBLE_ method for industrial uses. Look at any industrial machine, like a robot welder or steel mill, and there’s bound to be a big red button on it, labeled STOP. The E-Stop button is there to make the machine stop the INSTANT it’s pushed.
Seems to me, a switch debounce based on software — and especially based on a wait time — is a case of gratuitous complexity. Back in “the day,” we used to do it with a SPDT switch and an S-R flip-flop. The first signal on the S input sets the FF, the first on the R resets it. Period.
What am I missing here? Surely, in the last 50 years, someone’s developed a switch with the FF built in. We should be able to buy a debounced switch at Banggood.
FWIW, I LOVE state machines. I once solved a really tricky design for a medical patient monitor, using nested state machines (and yes, it used switch/cases — very clean and modular). In fact, there was a recent article somewhere, saying that a state machine is a better option than an RTOS.
I just don’t like this particular application. A pushbutton that only responds after a delay, and requires you to take your finger off the button before anything happens, does not satisfy.
Please, please, please use an enum for your case labels if you’re going to use a switch for a state machine.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)