timer with separated input settings

[Blokk]

May I have an additional question regarding to the simple state machine template?

I have checked several CLD example solutions, and as I see the simple state machine template is not enough own its own.

I mean, if we need to for example run one particular state for a certain time. In this case we should bounce between that case and the Event loop's timeout case inside the "wait for event" case (as it was already mentioned by one of you in some posts earlier, so the GUI will still reactive via Events).

We can check the elapsed time using FGV timer in the actual case (state), and decide to move to the next state for instance.

However, if we use only a single enum in a shift register, after going to the "wait for event" case, the state machine will have already lost the info about which case it was before, so it cannot "go back" to continue the waiting and jumping between the recent case and the "wait for events" case.

As I see (in the CLD prep materials and solutions) this problem with the Simple State Machine template was solved by using Queues (so the actual case (or state) inserts the "wait for event" enum constant first and the actual case enum constant second into the queue), or simply a typdef enum array, using it as a kind of "home made" Queue...

My question: if I see that the given CLD exam can be solved with a simple state machine template, shell I use Queues (so far it looks the most compact way to do for me)?

Or is there another way to be able to jump between the actual case and the "wait for event" case?

[crossrulz]

---

Blokk wrote:

My question: if I see that the given CLD exam can be solved with a simple state machine template, shell I use Queues (so far it looks the most compact way to do for me)?

Or is there another way to be able to jump between the actual case and the "wait for event" case?

---

You can do some really fun logic in each state to say where it should go next.  Personally, I find using the queue to be much easier to manage since you can enqueue multiple states in at once.  This is really helpful for when you have to do custom sequences.  But you do need to make sure you have an error state for when your queue runs out of states (very common during debug sessions).  Make sure the timeout on the queue is set to 0.

But for the CLD, do whatever you can do quickly.  If you are really fast at using the Queued State Machine (a state machine that uses a queue to hold the states to call), then do that.

[Blokk]

But for the CLD, do whatever you can do quickly.  If you are really fast at using the Queued State Machine (a state machine that uses a queue to hold the states to call), then do that.

Yes, but the point is that, if I have a scenario when a state needs to wait, the only nice way to bounce between the actual state and the GUI listener "wait for events" is the usage of Queues, yes? Otherwise the state machine "does not know" which case was just before the "wait for event" case...

Other possibilities to use two enum shift registers (like "actual state" and "command transient") or the awkward enum array.

Am I correct?

Sorry if I seem to be a bit "lost in details", I think I am recently in a state (haha) when I try to clear things up in my mind... 🙂

[crossrulz · Accepted solution]

---

@Blokk wrote:

Other possibilities to use two enum shift registers (like "actual state" and "command transient") or the awkward enum array.

Am I correct?

---

Yep, that is correct.  Like I said, there are many ways to do this.  I personally think using a queue is the best way to handle your states (or at least I haven't seen any better ways).

[Blokk]

I think I just got all the info what I needed at this point, so I marked the prev post as a solution. But also thanks to all who gave good ideas and advices!

I just proceed and practice, 2 weeks from tomorrow is the judgment day 😄