Very relevant. What about UML? Diagrams are excellent, but even better if semantics are standardized. The Entity Relationship Diagram (ERD) is a lovely basis for a semantic model for implementation and analysis. Visual Paradigm may be an interesting tool as they support ERD and state models (including composite state models) across multiple platforms: https://www.visual-paradigm.com.

Thank you!

Thank you for the talk. I also use schematics a lot, especially finite state machines and UML's sequence diagrams, to explain complex interactions between modules.
A tool that I find interesting, as it is free and web-based (there is also a computer application): https://app.diagrams.net.
Hope this will be useful!

Thank you for the talk. It was nice to see that you use/d some of the tools I also use/d. I am involved in both embedded systems and digital design (FPGA). If in the embedded world the graphic is used to complement the code design and for a better documentation, in digital design graphics are used more in the design process. I saw designing tools going from graphics (logic gate diagrams) to code (hardware description languages) but never dropping completely graphics. Even the newest tools make use of graphics to create high-level block diagrams that allow to have that 50000 feet view of the design, so for better understanding all the relationships between components and signals going in and out of them.
In old versions of Xilinx ISE tools there was a graphic tool named StateCAD used to draw FSMs from which your could automatically generate Verilog or VHDL code. I don't know why they dropped it.
I also use graphviz to draw FSMs or other diagrams that can be built with this tool. The reason is because I can generate the diagram from a text file that can be quickly written with any text editor and can also be easily modified or reused (which means an increased productivity) - drawing with the mouse is also possible, but it is much slower. As you said, a picture worth a thousand words but if you can draw it base on a few lines of code, it is even better.

A good talk! Thanks!!

Hi Jean Labrosse,

Thank as lot for your presentation. It was very insightful specially because you gave us a very broad overview of current tools that can help us in "visualize the software".

My "addendum" here is regarding the possibility of interacting visual descriptions of the source code using Doxygen as was discussed by you and some of other peers.
There is an interesting (but still very simple) extension to Doxygen called Moritz that generates Nassi-Shneiderman diagramms of functions and methods in a C/C++ source as html files, which could be included in a software documentation or just watched by using a browser:

https://sourceforge.net/projects/moritz/

In addition, something extremely useful would be a tool that could visualize not only classes, functions, objects, variables, etc but also the flow of data inside a large software application.. ;-)

Best Regards from sunny Japan,

Wilson

Good talk. I've used Vizio for memory maps and similar diagrams, but for documenting state machines, flow control, and communications links, I usually used graphviz. It's not hard to process a state machine implemented as a table to produce the necessary graphviz statements. Depending on the language, call dependency graphs are also not that hard to produce automatically.

Thanks for all your advises. I liked the ISR and Task diagrams. I like document all, however sometimes there isn't time to make that. Additionally, I use doxygen (https://www.doxygen.nl/index.html) for obtain the documentation from the code.

Jean,
Thank you for your talk. I make extensive use of diagrams in my design work, and also when deciphering legacy code. It was helpful to see how you do it, and I learned of some new types of diagrams and tools which I was not previously aware of.
Most of the diagram tools that you presented about have graphical point and click interfaces. Do you prefer this kind of interface over text based tools like plantuml?
Thanks,
Sean

Thank you very much it's always a pleasure to listen to your informative talks. I also think that it's the best approach for starting a development by drawing some "big picture" diagrams. Especially if you as as en embedded engineer are new to technical domain. These graphical approach is really helpful to close the gap between the domain experts (who know what to do) and the embedded developer (who knows how to implement it). At the very end you mentioned the problem of keeping source and documentation up to date. To me some "best practices" for this would be another interresting topic to hear about. As long as a project is in time this is nothing care about but when deadlines arrive i heard so many times "features are more important than documentation". And in the end if your product moves from development stage to life cycle mainainance you pay the price for this.

I really enjoyed your talk as it was also very practical. In respect to the tools you used there is also need to update those regularly or convert the visual to a different format. Over the years lots of tools vanished or run only under old OSs. This adds additional amount of work for documentation. Thank you also for sharing the slides (which I wasn't aware of so I took handwritten notes). This was a great presentation which I liked very much. Thank you!