Discussion about state machines:
Constructive comments welcome.
It needs some additional info on how things might have state, but are not state machines.
For example, the BLINK sketch obviously behaves differently to turn the LED on and then off, but it not a state machine at all.
(Perhaps it would be interesting to see BLINK converted into a true SM version?)
Can you expand on this? The blink sketch has no variables, and therefore no state.
i had a quick glance. Some constructive (i hope) criticism:
- I wish people would focus more on describing state machines by state diagrams than on actually coding. The diagram is sually very clear, the code can be quite obscure (unless you use my library of course.. :P)
- Under general technique you write this:
When an event happens (eg. serial input, switch press) then
Check what the current state is.If the current state is A, then do X, and maybe change to state B.
If the current state is B, then do Y, and maybe change to state C.
And so on ..
I do not agree fully. One great benefit of state machines is that they act as filter on input signals. That is in a given state the machine should only check the signals of interest. This gives more efficient code and more stable behavior.
Of course, if you are using buffered input like serial, this must be dealt with.
enum {LEDON, LEDOFF} ledstate = LEDOFF;
void loop() {
delay(1000);
switch (ledstate) {
case LEDON:
digitalWrite(led, LOW); // if the LED was on, turn it off.
ledstate = LEDOFF; // new state
break;
case LEDOFF:
digitalWrite(led, HIGH); //if it was off, turn it on.
ledstate = LEDON;
break;
}
}
That is in a given state the machine should only check the signals of interest
Well, could I amend that to read:
If an unexpected event occurs, either ignore it, or report an error.
?
@westfw: Yes, that's not a bad example. When the event happens (time elapses) do something depending on the current state.
With a slight modification you could turn that into "blink without delay".
Example:
If you press the "volume up" button on your remote, and the TV is off, ignore it.
Thats what i meant. There should be NO unexpected events in a state machine. Either you make a transition (which can be to an error state) or you don't. And thats another reason why state diagrams (or other description methods) are so utterly important.
One of the advantages of the State Machine concept (mine are never as nicely organized as yours) that you haven't mentioned is the ability to work with parts of an application that have different timings.
For example there could be a need for regular reading of a keyboard in case someone decided to press a button (and change a State) whereas the code that operates on the State might only need to operate once every few seconds or minutes. Or the other way round where you need to read a sensor at long intervals but keep the rest of the code running without waiting for the next sensor value.
I hope this makes sense. I see a lot of questions from newbies who don't appear to be aware of this simple approach.
And a minor point, I think it would be useful to have a link to an explanation of "enum"
...R
@Robin2. This is partly the same as this.
nilton61:
I do not agree fully. One great benefit of state machines is that they act as filter on input signals. That is in a given state the machine should only check the signals of interest. This gives more efficient code and more stable behavior.
Of course, if you are using buffered input like serial, this must be dealt with.
But that implies that u have a complete description of th SM. And the description incluse the set of states, the set of input signals, the set of output signals and the set of transitions.
And the definitive best way of organizing state machines is a state diagram
With a slight modification you could turn that into "blink without delay".
Yep. With perhaps less "disconnect" than the current implementation.
It is supposed to be an advantage of an actual state-machine based implementation that the behavior is CLEARER than it would be otherwise...
I think I second the suggestion for including a paper state-diagram, but I'm not sure it would be so readily understandable for people who haven't been exposed to flow charts. A state-diagram is an alternative to a flow chart for situations where there are obvious 'states.'
@niltont61, my point is not about the value of a State Machine as a good way to ensure a correct program (which of course it does) but rather about the facility it also provides for easily managing overlapping activities with different time requirements - something newbies seem to have difficulty grasping.
...R
@westfw:
That would be another misconception i quite frequently encounter. Flowcharts are NOT state diagrams even if they resemble another at a first glance.
- A state diagram is a graphical description of a state machine obeying to the same rules and the same underlying mathematical theory.
- A flow chart is just a hotchpotch way of putting instructions together without any validation of correct code, realtime behavior etc.
Robin2:
@niltont61, my point is not about the value of a State Machine as a good way to ensure a correct program (which of course it does) but rather about the facility it also provides for easily managing overlapping activities with different time requirements - something newbies seem to have difficulty grasping....R
I totally agree on that. A correct state machine does both these things. The question is how formal one should be. Oversimplification is a short term solution at best, a recipe for constant pitfalls otherwise (especially when learning).
Flowcharts are NOT state diagrams
I thought that's what I said. Even without delving into mathematical theory (which I'm not sure programs conform to, once you include "actions" as part of state transitions instead of giving them their own states), a state-diagram describes a useful type of program flow that is particularly NOT well suited to flowcharting.
Ok, i misunderstood. Sorry bout that.
nilton61:
@westfw:
That would be another misconception i quite frequently encounter. Flowcharts are NOT state diagrams even if they resemble another at a first glance.
- A state diagram (used correctly) is a graphical description of a state machine obeying to the same rules and the same underlying mathematical theory.
- A flow chart (used incorrectly) is just a hotchpotch way of putting instructions together without any validation of correct code, realtime behavior etc.
To a man with a hammer everything looks like a nail .................
If a state diagram diagram is not correct its not a state diagram
There are no rules on how to construct flowcharts, so every flowchart is correct per se