#41 State Machines Part-7:Automatic Code Generation
HTML-код
- Опубликовано: 15 окт 2021
- This lesson continues the subject of STATE MACHINES. Today you will see how automatic code generation works in practice. Graphical modeling and automatic code generation do not seem to be mainstream yet, but they are very much parts of the modern approach and I believe they are the future of embedded software development.
1:38 Downloading and installing QP-bundle with the free QM modeling tool
3:30 Launching the QM modeling tool & opening model files
4:00 Viewing state diagrams in QM
4:53 Adding actions in C to the state machine
6:15 Adding attributes to the state machine class
6:38 Adding operations (functions) to the state machine class
7:35 Logical Design vs. Physical Design
9:03 Doing Physical Design in QM
9:18 Adding code directories to the model
9:57 Adding code files to the model
10:30 Editing the file content in QM
11:06 The $declare code generation directive
11:30 The $define code generation directive
11:50 Generating code in QM
14:10 Compiling and running the generated code
15:30 Why should you bother with modeling and code generation?
16:30 Effective and ineffective visual representations
17:39 The UML visual notation
18:00 The intuitive nature of state diagrams (David Harel's story)
19:20 Code generation as critical for the success of modeling
19:48 Concerns about correctness and efficiency of the generated code
20:30 The real challenges of automatic code generation
20:40 The problem of "fighting the tool"
21:10 A quick overview of other modeling tools
21:30 "Fighting the tool" example of the State Machine Compiler (SMC)
22:18 Complete code generation in QM
23:48 Generating code for parts of the model (packages, operations)
24:25 Generating code for individual states
24:41 The non-recursive $define1 directive
24:56 Traceability from the code to model
25:55 Traceability from the model to code (e.g., debugging the model)
26:30 Bi-directional traceability between model and code
27:26 Model differencing and merging
29:30 Scaling models for big teams
29:53 External packages
30:02 Conclusion
-------
Resources:
Companion web page for this video course:
www.state-machine.com/quickstart
GitHub repository for projects for this video course:
github.com/QuantumLeaps/moder...
Transcript of this lesson:
www.state-machine.com/course/...
Recommended Reading:
"The Pragmatics of Model-Driven Development" by Bran Selic,
IEEE Computer Society 2003 (www.computer.org/software-mag...)
PDF (www.state-machine.com/doc/Sel...)
"Statecharts in the Making: A Personal Account" by David Harel,
Communications of the ACM 2010
(www.wisdom.weizmann.ac.il/~ha...)
"Large Scale C++ Software Design" by John Lakos, Addison Wesley Longman, Inc. 1996
ISBN 0-201-63362-0
Music credits:
The background music comes from:
www.bensound.com/royalty-free... 
Наука
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
Great tool Great tutorial Great teacher! Thanks 🙏
I was hesitant with such graphical modelling tool because things that took away complexity oftentimes have unwanted outcome hidden away from me. However, your arguments about the similarity between compiler and modelling tools really convinced me! Thank you Mr. Samek
Excellent Work !!! i think you have to upload this video firstly other than 40 + video you uploaded. because after watching this video i actually realized that how QM works. and its really helpful✌👍
Incredible tool, I'm very impressed. I was wondering if you've considered building QM as a plugin to popular IDE's like eclipse or keil, this would be a very interesting, I can imagine the debugging being simplified by watching the literal transitions and current states in a graphic way, I think it would be game changer to have it all integrated into a tool!
QM is NOT written in Java, and therefore it's *fast* . For example, QM opens up in 1-2 seconds (as opposed to 20-30 seconds if it was Java). But that means that it can't easily integrate with Eclipse. Also, of course graphical, model-level debugging would be nice. Currently it's not supported directly, because it would necessarily tie QM to a specific IDE only. However, the traceability comments in the code allow you to quickly navigate between code and model. Here, the most important feature is the *bi-directional traceability* of the state machine implementation (as demonstrated in the video at 24:55). This is what is really important for effective debugging of the state machine code. --MMS
you are amazing.
thanks a lot for this great video.
the ability to compare the model updates is important and not exist in stateflow
also stateflow generated code is flat and not hierarchal.
if QM tool is reliable and doesn't have a major bugs, then it will be the best choice for many suppliers.
Hello Dr. Samek, Thank you very much for this course. It is excellent and I am amazed at all the hard work you have done with it. Outstanding. I have also become more familiar with the QM program. It is amazing. The more I learn about it, the more powerful and complete it is. I have followed you for many years, reading both your books and using them as a handbook to learn about HSMs, and to find applications for them. I was wondering about one thing, though. Is there a way to change the framework on which a model is based. I was wanting to experiment with different versions of the same model, but did not want to re-enter the model manually if I can avoid it. Thank you for you excellent and generous efforts in our behalf.
I'm glad to hear that you enjoy the video course. Regarding changing the framework underlying code generation in the QM modeling tool, there is some flexibility, but the "optimal" state machine implementation strategy (introduced back in lesson #39) is codified inside QM and cannot be easily changed. This strategy determines the rules for code generation from state machines in QM. (BTW, this is how most of code-generating tools work. They use an underlying framework to provide the well-defined "framework extension points" to generate code.) What you could potentially change is the active object layer. For example, you could try to pass events in a different way. You could schedule active objects in a different way, etc. --MMS
Another comment/question that somehow was suppressed by RUclips: VFXTuts wrires: "Hi am a beginner in your framework, and I have a perhaps silly question: In a system where, for example there is a switch whose status in unknown at startup time, how can I program in QM an AO to choose in which state it would transition into at the beginning depending on the switch position? At the present moment I implement it by starting the AO into a state which arms a timer of 1 tick, the state is subscribed to that timer event, which triggers a transition segment that checks the switch position, followed by a choice segment that, depending on the readout, transitions into the desired state. a screenshot of said implementation snipboard.io/OzenNP.jpg MR "
You're right that sensing the switch position at run-time is not possible to implement in the top-most initial transition, because guard conditions are not allowed on initial transitions. And you're on the right track to think of an event to trigger a regular transition, which *can* have guard conditions (the state of your switch). But this event does not need to be the somewhat expensive time event. So, I would invent an immutable event and post it to *self* in the top-most initial transition. Then in the first state, you can have a regular transition with a guard based on your switch position. The framework will execute the transition only after the initialization phase. I hope this makes sense to you. --MMS
Thank you!
Amazings tutorials, congrats ! Are you using scxml as your modelling data format ?
The SCXML specification has been carefully evaluated as the model format for the QM modeling tool. But unfortunately, SCXML is a bit overengineered and requires such sections as: "Executable Content", "Data Model and Data Manipulation" and "External Communications". All these prescribe a specific "Action Language" as well as some additional restrictions as to how to represent and manipulate the internal data associated with the state machines as well as how the state machines should communicate. All this actively hinders simply using C or C++ as an "Action Language", in effect adding complexity where the tool does not add any value. At 20:36 this video shows an example of "fighting" an overengineered specification (SMC in that case). For these reasons, SCXML has not been used directly. Some elements of the structural state machine description (e.g., , , , etc.) are similar in QM, but the QM model format is much simpler than SCXML. Please check it out by yourself, just by opening the qhsmtst.qm file supplied in the project for this lesson in your favorite text editor. --MMS
The QM model format in XML is not based on SCXML specification, but recently ( in QM 6.1.0 ), the XML Schema has been added to QM (see file qm.xsd on GitHub github.com/QuantumLeaps/qm/blob/main/qm.xsd ). This XML Schema allows the validation of existing QM models with an XML editor. --MMS
Why not using matlab’s simulink code generation?
Moreover to the state machine, you can generate code for filters, dsp stuff, controllers, etc.
And all of them can be generated in c and cpp compatible with arm compiler.
And it is easy to use 💪💪😁
I am not saying what you are doing is bad… you got a good vision of the future of embedded system, especially the need for automatic code generation…
The video actually shows a quick overview of other modeling tools from 21:09 - 21:19, including Stateflow (state machine tool for Matlab/Simulink) at 21:12. But specifically Sateflow is designed for predominantly input-driven state machines (see lesson-37) and definitely not for active objects. Of course, we can also debate the quality of the generated code in terms of traceability and scalability. Finally, StateFlow is expensive and I would still put it in the category of big, "high-ceremony" tools. --MMS
@@StateMachineCOM Thanks. That was a reasonable and a good answer.
It is a great tool to implement state machine flawlessly, but in normal circumstance most people would like to write code in the IDE editor. Then while modelling they would have to use that code inside state machine. This seems a little difficult to convince people at the start as it seems that we are doing rework
Of course, when state machines are first coded by hand in an IDE, re-drawing them in a modeling tool *is* a duplication of effort. But that is backward. To take full advantage of "visual intelligence", you need to start with a diagram. Then manual coding *is* a rework. But you know this already, right? Convincing other people to do things differently has always been the hardest thing in the universe. Yet, this is the only way to make progress. --MMS
@@StateMachineCOM I also feel the same, convincing people to do things differently is a task but nonetheless required for overall improvement
Is it free?
The QM tool is freeware. The generated code requires the QP framework to run (either QP/C or QP/C++), which are both open source (GPL). So, all this is free, as long as *your* code is free as well. If your code is proprietary and cannot comply with GPL, QP can be licensed commercially, which is not free. --MMS
看不懂啊看不懂