Why does .init() create a SIG_ENTER event? about arduino-trimwright HOT 5 CLOSED

That's a good question. It's been a while since I looked at this, but I think it's a result of a few concepts:

• The state machine is always in one particular state at a time, it's never "sort of" or "kind of" in a state.
• When a state is entered the ENTER event is always the first event it's given, and LEAVE is always the last event it's given.

So to answer your question, no the state machine can't be initialized without going through the full "init" flow. In other HSM work I've done (in javascript) I had a use case where I wanted to serialize an HSM, and later unserialize it to handle a new event. That might be a case for initializing an HSM directly to a deeper state w/out the usual "init" flow. However in c++ there are all kinds of things which might also go along with being in a particular state (e.g. open file handles, remote data cached locally, etc), so unserializing an HSM (or FSM) might be quite a bit more than just restoring the m_stateCurrent pointer.

Anyways that's my current thinking. Do you have a particular use case where the current behavior is tripping things up? I'm definitely open to making the library more sophisticated (but not in a way that makes it easy to misuse).

from arduino-trimwright.

Thx for getting back to me.
My use case follows a global design in our code where every object has these functions:

1. initialize() -> I've decided to create an "idle" state here to solve my issue.
2. start()
3. process() -> states change depending on events
4. stop()
5. start()
6. process
7. stop
   ... and many more start/process/stop cycles, and then eventually
   XX. shutdown

So in initialize(), I'd like to set the initial state of the State Machine (SM) without it execution of any "processing" tasks on entry.

I think my solution is to create an "startup" state that has no process functions. I think I'll do that as it makes more sense since the first state I was initializing my SM to wasn't correct - now that I think of it.

I'd like to mention that I reviewed a lot of SMs on GitHub and I found yours to be the easiest to understand and easiest to add break points and log traces for debug. Thx.

from arduino-trimwright.

What you're doing seems very reasonable. That "idle" state makes sense conceptually so is perhaps a reasonably clean workaround. In your start() you could dispatch a "START" event to transition to your initial running state. In your stop() you could dispatch a "STOP" event to transition back to "idle". If you're using hierarchical states you could do something similar with top-level "idle" and "running" states, with most of your states being children (directly or indirectly) of "running".

If it's helpful I could add pre-processing macros to change the interface of TrimWright. I was a little worried that "init()" is too generic a name, and could add an option to use "initStateMachine()" instead (or something like that). It doesn't sound like that's what's tripping you up though.

from arduino-trimwright.

I accidentally hit the close on this. But I'd like to say I like the initStateMachine() idea.

from arduino-trimwright.

PR #4 adds the ability to redefine the init() method. Your feedback there would be most appreciated.

from arduino-trimwright.