Not too long ago I had to fix a small bug on a Jaguar Land Rover instrument cluster project. The code was so badly written (lots of global state variables. nested if else, control loops - spaghetti logic) that it was impossible to change something without inducing some side effects. So I had to redesign the whole thing using Hierarchical State Machines after watching a presentation based on "Practical UML Statecharts in C/C++" some years ago. I can't stress enough how much better the end result was. It was a clean, robust, easy to follow design. It is like finding a single solution that covers all the possible cases. Flawless! I try to promote this idea as much as I can but too few care about good design as long as "it works", at least in the industry I work. Thank you Miro Samek.
few years ago, i was using ibm rhapsody for the first time , and it appeared straight to me that it was the future and its how i wanted to work. Its wonderful that you achieved to have a lighter and straightforward version of such tool.
IBM Rhapsody is a "high-ceremony" modeling tool, while QM (www.state-machine.com/qm ) is intentionally a "low-ceremony" tool. Rhapsody is in a different class of tools and can do obviously so much more than QM. But, QM can rival Rhapsody's support for *state machine modeling* , and some elements of hierarchical state machines (e.g., internal transitions and choice-segments) are arguably more expressive in QM than in Rhapsody. Also the QM code generation is more flexible, because QM has been specifically designed to capture the physical design (partitioning of the code into directories and files). Anyway, for years I was looking for a truly lightweight, "low ceremony" modeling tool that could do 90% of what I needed for 10% of the complexity and costs. QM is such a tool. BTW, QM is freeware... --MMS
Your presentation was great. Thanks. Personally, I'd like to watch you use the QP frameworks in a more complex project. I think a great complement to this presentation would be a code walkthrough / live coding session: - Helping us to discover the QP frameworks workflow - Helping us see an application of the event-driven mentality to a bigger project. Regards
Yes, I'd love to talk about the modern concepts and QP/QM in particular. But any such discussion would necessarily involve concepts like "state machine", "run-to-completion", "RTOS", "event-driven programming", "sequential programming", etc. Unfortunately, those concepts tend to be completely misunderstood in the embedded community, so I need to very carefully first introduce the concepts and explain them. This takes a lot of time (see my "Modern Embedded Programming" course going on from 2013). To illustrate what I'm up against, just please check out a recent discussion "When a State Machine is not a State Machine?" (www.embeddedrelated.com/thread/11836/when-is-a-state-machine-not-a-state-machine ). All except one participant of that discussion (me) have declared that a piece of sequential "Blinky" code based on blocking is, in their view, a "state machine". Now, what do you do with that level of confusion??? --MMS
@@StateMachineCOM Thanks for your answer. I trust your opinion on pedagogy, and I salute your efforts on this RUclips Video Series. I'm looking forward to your next videos. :) ps Here's the article that inspired my initial comment. It's making the case for the value of live-coding as a knowledge transfer tool. commoncog.com/blog/youtube-learn-tacit-knowledge/ Regards,
Here's my take on a state machine. I have a never ending project to clone Heidenhain TNC155A CNC controller (with something else than a TMS9995 running at 12MHz. My pick was STM32H7 at 480MHz and maybe with some help with Spartan-6 FPGA). I need to read real Heidenhain keyboard matrix which has no debounce capacitors nor diodes preventing key ghosting. Luckily there are no multi key presses on a real Heidenhain TNC controller and so my keyboard scanner halts the scanning at the first valid key press after debounce. All running at systick interrupt (1/1000s). My plan is to use STM32F4 as a keyboard controller and read spindle and feed override potentiometers with it (12-bit adc (no comparators used as with the original TNC controller, ADC's where expensive back in the 80's) ) and also provide a mean to use USB flash drive to read NC-programs... My route on cloning the TNC controller is to use as many microcontrollers as possible (they are cheap for one of project). My keyboard scanner has state machine for key presses and also runs USB host stack for flash drive and provides a mean to read analog potentiometers. I think it's called distributed computing... ? That's part of the user inputs. For outputting the servo drive analog voltages (+-10v) I'm planning on using one STM32 controller per axis and use it's dual 12-bit DAC's and getting 24-bit analog output out with help of an opamp (differential output from the DACs). Makes it a bit easier coding wise and also I get true 12-bit analog voltage (12-bits positive and 12-bit negative) and just by keeping one at zero changes the sign... There is no real reason for the 24-bit analog voltage other than that I could use it. ruclips.net/video/3EpoLow8g6w/видео.html Distributed computing is in my mind the future as silicon gets cheaper. There is no real reason other than prize to share mcu resources for mundane tasks. More cores equals more power. The provided STM HAL USB stack is also a bit of a no go for true realtime embedded programming. While it enumerates a USB device it calls on HAL_Delay() :) I've done another USB stack for Microchip controller that enumerates on MIPS systick timer. State machine incorporates the delays needed and it's quite easy as states only changes at the interrupt.
My experience has been that the fewer CPUs the easier the project. The reason is that multiple CPUs turn your project into a *distributed* application, and *distributed* systems open up completely new can of worms that don't exist in single-address-space systems. These are problems of communication over "networks" (e.g, SPI, I2C, UART, CAN, etc.) So, all of the sudden you need to serialize the data to push them over the wires, you invent "protocols", you deal with bad checksums/CRCs, etc. The bulk of your code deal with this communication and not with your problem at hand. It's just accidental complexity. In contrast, in a single CPU project, you can consider event exchanges *reliable* , as reliable as calling functions. --MMS
![Eminem - Temporary (feat. Skylar Grey) [Official Music Video]](http://i.ytimg.com/vi/ZaK9Wi5ho0o/mqdefault.jpg)
Not too long ago I had to fix a small bug on a Jaguar Land Rover instrument cluster project. The code was so badly written (lots of global state variables. nested if else, control loops - spaghetti logic) that it was impossible to change something without inducing some side effects. So I had to redesign the whole thing using Hierarchical State Machines after watching a presentation based on "Practical UML Statecharts in C/C++" some years ago. I can't stress enough how much better the end result was. It was a clean, robust, easy to follow design. It is like finding a single solution that covers all the possible cases. Flawless! I try to promote this idea as much as I can but too few care about good design as long as "it works", at least in the industry I work.
Thank you Miro Samek.
few years ago, i was using ibm rhapsody for the first time , and it appeared straight to me that it was the future and its how i wanted to work. Its wonderful that you achieved to have a lighter and straightforward version of such tool.
IBM Rhapsody is a "high-ceremony" modeling tool, while QM (www.state-machine.com/qm ) is intentionally a "low-ceremony" tool. Rhapsody is in a different class of tools and can do obviously so much more than QM. But, QM can rival Rhapsody's support for *state machine modeling* , and some elements of hierarchical state machines (e.g., internal transitions and choice-segments) are arguably more expressive in QM than in Rhapsody. Also the QM code generation is more flexible, because QM has been specifically designed to capture the physical design (partitioning of the code into directories and files). Anyway, for years I was looking for a truly lightweight, "low ceremony" modeling tool that could do 90% of what I needed for 10% of the complexity and costs. QM is such a tool. BTW, QM is freeware... --MMS
Thank you very much for your amazing lectures
Hoping for more videos in embedded systems, like design pattern, team development like git,svn etc, and software testing, thanks somuch Miro ❤
Loved the series of videos in this conference!!!
Excellent presentation, thanks for sharing!
Your presentation was great. Thanks.
Personally, I'd like to watch you use the QP frameworks in a more complex project.
I think a great complement to this presentation would be a code walkthrough / live coding session:
- Helping us to discover the QP frameworks workflow
- Helping us see an application of the event-driven mentality to a bigger project.
Regards
Yes, I'd love to talk about the modern concepts and QP/QM in particular. But any such discussion would necessarily involve concepts like "state machine", "run-to-completion", "RTOS", "event-driven programming", "sequential programming", etc. Unfortunately, those concepts tend to be completely misunderstood in the embedded community, so I need to very carefully first introduce the concepts and explain them. This takes a lot of time (see my "Modern Embedded Programming" course going on from 2013). To illustrate what I'm up against, just please check out a recent discussion "When a State Machine is not a State Machine?" (www.embeddedrelated.com/thread/11836/when-is-a-state-machine-not-a-state-machine ). All except one participant of that discussion (me) have declared that a piece of sequential "Blinky" code based on blocking is, in their view, a "state machine". Now, what do you do with that level of confusion??? --MMS
@@StateMachineCOM Thanks for your answer.
I trust your opinion on pedagogy, and I salute your efforts on this RUclips Video Series.
I'm looking forward to your next videos. :)
ps
Here's the article that inspired my initial comment. It's making the case for the value of live-coding as a knowledge transfer tool.
commoncog.com/blog/youtube-learn-tacit-knowledge/
Regards,
Thank you!
Here's my take on a state machine.
I have a never ending project to clone Heidenhain TNC155A CNC controller (with something else than a TMS9995 running at 12MHz. My pick was STM32H7 at 480MHz and maybe with some help with Spartan-6 FPGA).
I need to read real Heidenhain keyboard matrix which has no debounce capacitors nor diodes preventing key ghosting. Luckily there are no multi key presses on a real Heidenhain TNC controller and so my keyboard scanner halts the scanning at the first valid key press after debounce. All running at systick interrupt (1/1000s).
My plan is to use STM32F4 as a keyboard controller and read spindle and feed override potentiometers with it (12-bit adc (no comparators used as with the original TNC controller, ADC's where expensive back in the 80's) ) and also provide a mean to use USB flash drive to read NC-programs...
My route on cloning the TNC controller is to use as many microcontrollers as possible (they are cheap for one of project). My keyboard scanner has state machine for key presses and also runs USB host stack for flash drive and provides a mean to read analog potentiometers. I think it's called distributed computing... ?
That's part of the user inputs. For outputting the servo drive analog voltages (+-10v) I'm planning on using one STM32 controller per axis and use it's dual 12-bit DAC's and getting 24-bit analog output out with help of an opamp (differential output from the DACs). Makes it a bit easier coding wise and also I get true 12-bit analog voltage (12-bits positive and 12-bit negative) and just by keeping one at zero changes the sign... There is no real reason for the 24-bit analog voltage other than that I could use it.
ruclips.net/video/3EpoLow8g6w/видео.html
Distributed computing is in my mind the future as silicon gets cheaper. There is no real reason other than prize to share mcu resources for mundane tasks. More cores equals more power.
The provided STM HAL USB stack is also a bit of a no go for true realtime embedded programming. While it enumerates a USB device it calls on HAL_Delay() :)
I've done another USB stack for Microchip controller that enumerates on MIPS systick timer. State machine incorporates the delays needed and it's quite easy as states only changes at the interrupt.
My experience has been that the fewer CPUs the easier the project. The reason is that multiple CPUs turn your project into a *distributed* application, and *distributed* systems open up completely new can of worms that don't exist in single-address-space systems. These are problems of communication over "networks" (e.g, SPI, I2C, UART, CAN, etc.) So, all of the sudden you need to serialize the data to push them over the wires, you invent "protocols", you deal with bad checksums/CRCs, etc. The bulk of your code deal with this communication and not with your problem at hand. It's just accidental complexity. In contrast, in a single CPU project, you can consider event exchanges *reliable* , as reliable as calling functions. --MMS