I have been implementing a finite state machine which basically ensures configuration of the external chip which communicates with my MCU via I2C. The skeleton of the configuration state machine looks like this:
Whereas the Configure Register N states are state machines in their own. It is pretty simple state diagram but there is one complication. The chip can asynchronously generate a "fault" event which is signalized via assertion of the "fault" pin. State of the fault pin is read with the same period with which the state machine is executed. Service of the fault pin activation is based on another state machine. So the basic state diagram incorporating the fault pin activation service looks like this:
At first glance there are several repeating patterns in the state diagram. At first the state diagram for the register configuration and secondly the state diagram for fault pin activation handling. I would like to exploit these patterns and avoid of repeating the same code at several places. Can anybody suggest me any solution?
-
1Don't try to fit everything into one big FSM. Use FSMs for the parts where using FSMs make things simpler. You can have more than one.Stack Exchange Broke The Law– Stack Exchange Broke The Law2021年02月17日 12:12:29 +00:00Commented Feb 17, 2021 at 12:12
1 Answer 1
If repeating configuring a register after a fault was asserted is not a problem for the remote device, then you can use a nested state-machine with a History pseudo-state, like this
The arrow from the history state indicates which state will become active if there is no history, otherwise the last active sub-state gets re-activated.
If all the "Configure register N" state machines are actually identical and the only difference is in which data gets transferred, then you could also use a single state machine for all registers and invoke that repeatedly with different data, like this: