State Machines

Phil_aka_Pip

A Finite State machine is in state s. When event e occurs a state change to state t is triggered.

My colleague who is doing the user interface insists that he has to be capable of displaying the device statii corresponding to event e while state s is on display, whereas I say that is not necessary. The user interface needs to display the state t with the device statii corresponding to event e because the FSM has already changed state by that time

He is effectively insisting on two UI states for each of my FSM states: one showing state s with the conditions of event e, and the other showing state t with the conditions of event e.

The state change is as near as dammit instantaneous: as long as it takes to write a new value to an 8 bit variable, and certainly takes a lot less time to do than transmit the new FSM state and device statii using a SOAP interface.

I say he is mistaken. Anyone else have an opinion?

JayGee

In the general case, and in terms of what an end user sees in a production environment you're right and he's wrong. However.... I've worked as a software engineer on embedded/real-time stuff for going on for 30 years, in that time I have as you might imagine implemented a lot of FSMs and being able to run them in what's effectively a "single step" mode (or at vastly less than normal speed) with a visual representation of current state, incoming events, next state, and any associated actions has sometimes been hugely advantageous for debugging purposes :-)

Phil_aka_Pip

@JayGee Agreed. I debug with ddd (if I have to) ... and won't be debugging through his web server!

JayGee

Hah!

Real Programmers debug with printf() and/or an oscilloscope and a handful of spare (possibly borrowed with the aid of a soldering iron and scalpel) I/O ports. :-)

Phil_aka_Pip

@JayGee Once upon a time we had neons on the front of the cpu cabinet: one for each bit on the data bus, the address bus, the registers incl program counter and processor status. We didn't need ICE because we could stop the clock and single shot with proper switches. Then things went modern and we had LEDs. After that things went into a bit of a decline ...

ROOG

Phil_aka_Pip said:

@JayGee .. Then things went modern and we had LEDs. After that things went into a bit of a decline ...

Now you're sounding like Marvin!

Phil_aka_Pip

I don't feel any happier about modern technology than he did. "Sounds ghastly" said Arthur. "It all is" said Marvin.

PolarityMan

If I'm interpreting it correctly he's saying he wants to show your current state, the event and the state you came from?

Sounds reasonably useful, as to whether it's necessary it depends on the use case. 

Phil_aka_Pip

No, the state we came from is not part of the display. In fact he doesn't need "states" to control his display. He's using a "state number" to index a list of objects to display on the screen (for the statii of individual devices), which is irrelevant, as the status message I give him contains explicitly the status of each device, so he might as well read the message and for each device in the message display its status appropriately instead of assuming that "state=n" implies a list of device statii. The event is no more than a relevant status change in a device.

He says he still reads the message to see if the device statii are what he expects them to be, so he's still got to inspect the device statii anyway. I don't mind if he wants to raise some kind of error if there's a device in the opposite state to what he thinks it should be (they're all OFF or ON).