NOTE: The source code, as presented in the video, might cause compilation errors with the newer MDK-ARM / uVision toolsets. This is because the underlying compiler in MDK-ARM has been changed to "Compiler-6", while the older "Compiler-5" is considered now obsolete. The updated code that compiles cleanly with "Compiler-6" is available from the companion website at: www.state-machine.com/video-course and from GitHub: github.com/QuantumLeaps/modern-embedded-programming-course
This video series should be a required watch for all embed programmers, computer science students, and computer systems engineering students. I've been following this playlist for a couple of years and the knowledge I've gained has been invaluable to my career - not only for its upfront content but for its ability to enable to ask follow up questions and guide my own learning. The whole playlist is an example of a well designed, coherent course!
I'd like to add one comment about the "nested-switch statement" state machine implementation that was presented in lessons 35-36. Just in case my in-video remarks were not prominent enough, the "nested-switch statement" is NOT the best implementation technique. This is simply a stepping stone and teaching aid, like the training wheels on a bicycle. In the upcoming lessons I will present an overview of state machine implementation techniques and show you what's the best. Stay tuned... --MMS
This video brings up a question that's always on my mind (which I think you address somewhat in your Meany vs. Moore state machines video). When your guard detects the 'else' case, it turns all LEDs on. This could as easily happen in the initial transition to the 'boom' state. Is there a mental model to use to decide which actions should be done as part of the input to the state vs. in the state transition itself? Another question that comes up when watching: In my current project I often find myself posting somewhat arbitrary events rather than generating guard conditions. For instance, if I receive an event containing information that directs me to one state or another state, I tend to create and post an event for each of the two transitions, rather than using the guard to transition directly. This is partly because so much of my work is done in orthogonal objects, but also to minimize guard transitions. Can you comment on some considerations when designing these types of transitions?
Please remember that we are in the early stages of learning about state machines, and entry/exit actions to states ("Moore-type" state machine elements) have not been introduced yet. That's why at this stage all state machines presented are "Mealy-type", meaning that actions are only associated with state transitions. But you are right, that it will be more elegant to turn the LED on upon the entry to the "on" state and turn the LED off upon the entry to "off" state. This is all still coming when I show how to implement entry and exit actions. Regarding the guard conditions, they should be used very judiciously, because they are not necessarily a good thing! Specifically, every time you can replace a guard condition with an extra state or two, you should probably do it. Designs settled before compile-time that don't defer to IF-s and ELSE-s evaluated at run-time are clearer and generally superior. Finally, too many orthogonal components are not necessarily a good thing, because you have to keep track of many "current-states" in parallel. If some of this can be folded into a single state machine, you can cut down on the number of parallel states and the need to coordinate among them. --MMS
That's right. This channel is not about bomb-making. But these inexpensive embedded boards, like the TivaC LaunchPad, have only a few LEDs and a push-button. It's not that easy to come up with exciting examples... --MMS
NOTE: The source code, as presented in the video, might cause compilation errors with the newer MDK-ARM / uVision toolsets. This is because the underlying compiler in MDK-ARM has been changed to "Compiler-6", while the older "Compiler-5" is considered now obsolete. The updated code that compiles cleanly with "Compiler-6" is available from the companion website at:
www.state-machine.com/video-course
and from GitHub:
github.com/QuantumLeaps/modern-embedded-programming-course
This video series should be a required watch for all embed programmers, computer science students, and computer systems engineering students.
I've been following this playlist for a couple of years and the knowledge I've gained has been invaluable to my career - not only for its upfront content but for its ability to enable to ask follow up questions and guide my own learning.
The whole playlist is an example of a well designed, coherent course!
I'd like to add one comment about the "nested-switch statement" state machine implementation that was presented in lessons 35-36. Just in case my in-video remarks were not prominent enough, the "nested-switch statement" is NOT the best implementation technique. This is simply a stepping stone and teaching aid, like the training wheels on a bicycle. In the upcoming lessons I will present an overview of state machine implementation techniques and show you what's the best. Stay tuned... --MMS
watching mr samek's videos makes me feel good :)
I've been looking for a tutorial on how to build a timebomb with good design practices!
😂🤣
Thank you! Diamond material presentation!
This video brings up a question that's always on my mind (which I think you address somewhat in your Meany vs. Moore state machines video). When your guard detects the 'else' case, it turns all LEDs on. This could as easily happen in the initial transition to the 'boom' state. Is there a mental model to use to decide which actions should be done as part of the input to the state vs. in the state transition itself?
Another question that comes up when watching: In my current project I often find myself posting somewhat arbitrary events rather than generating guard conditions. For instance, if I receive an event containing information that directs me to one state or another state, I tend to create and post an event for each of the two transitions, rather than using the guard to transition directly. This is partly because so much of my work is done in orthogonal objects, but also to minimize guard transitions. Can you comment on some considerations when designing these types of transitions?
Please remember that we are in the early stages of learning about state machines, and entry/exit actions to states ("Moore-type" state machine elements) have not been introduced yet. That's why at this stage all state machines presented are "Mealy-type", meaning that actions are only associated with state transitions. But you are right, that it will be more elegant to turn the LED on upon the entry to the "on" state and turn the LED off upon the entry to "off" state. This is all still coming when I show how to implement entry and exit actions. Regarding the guard conditions, they should be used very judiciously, because they are not necessarily a good thing! Specifically, every time you can replace a guard condition with an extra state or two, you should probably do it. Designs settled before compile-time that don't defer to IF-s and ELSE-s evaluated at run-time are clearer and generally superior. Finally, too many orthogonal components are not necessarily a good thing, because you have to keep track of many "current-states" in parallel. If some of this can be folded into a single state machine, you can cut down on the number of parallel states and the need to coordinate among them. --MMS
The sadness that you experience after finishing the video when you realise that you might need to wait another 5 months to know what happens next😢😿
Actually, the next lesson is so interesting that it will be released much sooner. Promise! --MMS
@@StateMachineCOM I'm really hoping so... These lessons are invaluable. I humbly thank you for them, Mr. Miro.
@@StateMachineCOM Thank you for your contribution. I really love your course ;)
The next video in the State Machine segment is available. Please watch ruclips.net/video/E2Im7jLDDG4/видео.html . --MMS
We got more videos! Yes!!!
Miro samek, new video !!
Lool with bombs
That thumbnail picture is what I send to Customs when I import MCUs and they want to know what I am going to use it for
lol, I thought it was edgy too.
Boom🤣🤣
the-turn-all-leds-on state should be renamed to president-state!!
you should not teach your students how to create a time bomb!!
Don't give examples like making bomb 🤣
That's right. This channel is not about bomb-making. But these inexpensive embedded boards, like the TivaC LaunchPad, have only a few LEDs and a push-button. It's not that easy to come up with exciting examples... --MMS