A State Machine is a core concept of programming, and one that opens up a lot of creative possibilities beyond the basic single input/output Arduino/electronics/game projects.
The concept seems quite simple, but implementing it has been confusing – until I had a realisation late last night. I purposely haven’t defined the term (Finite) State Machine, because that is the issue. Let’s start with an example instead…
Imagine we have an elevator.
At any particular time, t, the elevator ‘system’ has a set of specific characteristics and is doing a certain behaviour:
- Set of Characteristics: e.g. it’s on level 3, has 2 passengers, buttons for level 4 and 7 are pressed, and the elevator music is playing.
- A Behaviour: it’s going up (it’s not going down, stopped or getting serviced).
The set of characteristics describes the STATE of the elevator. (if you’re familiar with the typical definition of a finite state machine you might be starting to question me now, but please keep reading)
“State: (noun) The particular condition that someone or something is in at a specific time.”
Another word for behaviour is the MODE the elevator is in.
“Mode: (noun) A way or manner in which something occurs or is experienced, expressed, or done.”
“Mode: (noun) <computing> A way of operating or using a system.”
Finite Modes, Infinite States
In the elevator example, we’ve listed four key MODES. We could probably list a few more, but it’s unlikely we’d need many more to successfully describe the system behaviour we’re interested in.
On the other hand there may be many many, potentially infinite, combinations of characteristics. Considering just the possible combinations of buttons people may have pushed – for 20 buttons (floors) there are 190 possible combinations of just two buttons-pressed.
So, when modelling a system we typically have a finite number of MODES (behaviours) we’re interested in. And at any particular time the system may be in one of potentially infinite STATES.
This is contradictory to most definitions of Finite State Machine I’ve read. So, referring to this kind of system model as Finite State Machine would seem inaccurate, or at least misleading (and a source of confusion for budding programmers/makers). If anything shouldn’t it be called a Finite Mode or Finite Behaviour Machine? Or I guess it could be written as Finite State-Machine, to make it clear that Finite does not relate to State.
I hope this will help anyone who’s trying to learn how to create state machines in their programs/Arduino sketches. For a chosen system:
- State: set of characteristics at a particular time
- Mode: the type of behaviour the system is performing at a particular time
- Machine: the program/code that manages the behaviour and updates the state (likely this will involve various control structures like if and switch statements).
To add a twist to all this: the current Mode is one of the characteristics of the current State (i.e. right now we’re behaving this way, not that way (e.g. we’re going up, not down or sideways)). The current State, at any particular time, emerges from the behaviour described by the current Mode, but the State itself is not a behaviour. This has implications for how we organised our code and variables.
Some good resources to check out next
- Adafruit have written a fantastic introductory tutorial to creating a state machine. It’s very clearly broken down and is also an excellent intro to classes.
- A very helpful example of implementing a state machine by Clinton Freeman, though it’s a little more complex with the use of structs and function pointers.
- I also recently completed the C++ Tutorial on Solo Learn, which I thought was really well organised and helpful for familiarising with key concepts. Nice bite-sized lessons to blitz through. C++ is the programming language the Arudino IDE (software) is based on.
One last thing, a question
If a horse walks into an elevator, will it turn around to face the door?
Header image credit: Roth 2016
Mr Ed: here