Thank for another very informative presentation Markus, state machines are a powerful way of defining a task and it was useful to see how they can be implemented in Zephyr. Would be interesting to see an example of a message passing interface between several state machines, perhaps a link manage that is aware of a Thread connection passing messages to a sensor (start, stop measurements depending on link state). Another area of interest would be a low (minimum) power Thread sleepy end device that wakes to take a measurement then returns to a sleep state. I have such a build running with Nordic nRF5 SDK but not sure how to do this with Zephyr. Looking forward to your next presentation.
@AbidurRahman425 Жыл бұрын
Thanks a lot for taking the time and effort to make such an explanatory video. I highly recommend this to anyone trying to get into the Zephyr world! I have a question or might be an idea for your next video: how to handle multiple hardware interrupts(timers & Switches) as events and use the events to switch the states of state machine? maybe some state switch depends on multiple events, what would be the scenario then? It would give us a better understanding of events in Zephyr.
@gittesilberglarsen1262 Жыл бұрын
Thanks. But it is not clear why one should implement using zephyr instead of the classical way which you presented first. The zephyr way looks more complicated.
@wsniot Жыл бұрын
For a simple state machine, the SMF framework is perhaps a bit overdone and the classical way is better. It is simply a framework. With several sensors, for example, you can simply separate the state machines, and there are also other functions such as initialisation before a state is entered and cleaning up when a state is exited. But it's always a toss-up whether it makes sense to use a library that has more complex functions or to implement something yourself.
@dmascore5493 Жыл бұрын
thanks a lot for this material .do you have github with an examples?
@svendepoorter620 Жыл бұрын
Thanks for the example! Question: would `sleep_msec` better fit inside `s_obj`?
@wsniot Жыл бұрын
I think you are right. Looks like a good use case.