There are two basic methods of implementing FSM.
In the the method I posted the only code running is the code in the current state.
All the actions and transition conditions are held in one 'block'.
This is how most commercial FSM packages 'display' a state, but it is unlikely that their implementation actually follows this form.
The other methods use lists of pointers and an index to the current state, or, like the chatGPT code, a state variable and a CASE structure.
The programme in this case is jumping between execution of a state and determining which state to execute.
There are pros and cons to both methods.
In the real world FSM programming is similar to Sequential Flow Chart (SFC), and is one of the five standard languages in IEC 61131-3.
SFC is very good for problems that have a sequential solution, like a recipe for baking a cake.
It is not very good for things that can happen in any order, or interact with each other.
This is why it is important to choose the programming tool most suitable for the task in hand.
In PICAXE we have BASIC, BLOCKLY, and FLOWCHART tools.
The first two are just different representations of normal BASIC, but FLOWCHART is very close to generating 'real' FSM code.
This extract shows some cells from a PICAXE flowchart ...
Code:
Cell_7_4:
if pinC.3=1 then
goto Cell_7_5
end if
goto Cell_7_4
Cell_7_5:
readadc C.1, varA
if varA < 128 then
goto Cell_7_7
end if
play 1, 3
goto Cell_7_4
Cell_7_7:
play 0, 3
goto Cell_7_4
You can see that the cells represent states, with both actions and transitions in the same cell.
As hippy suggested, most commercial implementations of FSM / SFC have entry and exit phases associated with each state. They also have minimum and/or maximum execution times, latching or non-latching actions, override, interlock and reset conditions, and lots of other features to make them more suitable to real world applications.
I don't think the OP actually needed an FSM, but we've had a good time thrashing it about !.
Cheers,
Buzby