9

This question is related to diagraming a software process. As an electrical engineer, much of the software I do is for embedded micro-controllers. In school, we learned to illustrate our algorithm using a flowchart. However, nowadays, many of my embedded projects are heavily interrupt-driven where the main process runs some basic algorithm a variety of interrupt sources provide its stimulus. So, my question is, what are some diagramming techniques that I can use to illustrate my process such that future developers can understand what I am doing easily and get involved in development?

Here are some key features that I am looking for:

  • Shows data structures and how data is passed between processes & interrupts
  • Shows conditions that cause each interrupt
  • Shows how data is gathered and passed through a downlink
  • Shows how command messages are received, parsed, and executed
  • Ideally is well suited for hierarchical breakdown into smaller processes with greater levels of detail
kjgregory
  • 656
  • 2
  • 12
  • 23

3 Answers3

12

I've always seen interrupt timing drawn as follows:

interrupt timing diagram

Or inline line so:

inline timing

But I prefer the former as it gives more room for annotation.

In response to your comment, perhaps a UML state machine diagram (with some adaptation) may be closer suited to your purpose:

UML state machine

embedded.kyle
  • 10,976
  • 5
  • 37
  • 56
  • While usfeul, I was more looking for a way to illustrate the overall top-level concept of what the microcontroller is doing. This type of diagram more focused on illustrating the execution timing of individual interrupts, where I have several different interrupt routines in my system. – kjgregory Jul 03 '14 at 15:14
  • @user2635036 Could you possibly explain a bit more what you are looking for? The top diagram shows multiple processes which you may or may not have in a microcontroller. But if you forget Process B and C, then Process A is your `main` loop which is interrupted by IRQx which is interrupted by a higher priority interrupt, IRQy, before returning to the main loop. Which, to me, sounds like a top-level concept of a microcontroller program being interrupted by multiple prioritized interrupt levels. – embedded.kyle Jul 03 '14 at 15:22
  • Well that diagram does a good job of explaining priority levels and timing relationship between interrupts and other processes. What it does not explain is what is the purpose of the interrupt, what is the purpose of the main function, what circumstances will cause an interrupt, what types of inputs and outputs are expected from the uC as a whole, and what interfaces exist between the uC and other systems. This diagram also doesn't show data structures and how data is passed between processes. – kjgregory Jul 03 '14 at 15:27
  • @user2635036 I understand now. You should probably edit your question to include that information as it was unclear to me and will help you get better answers. I've also added another possible diagram type to my answer that may be useful. – embedded.kyle Jul 03 '14 at 15:50
  • That's more like it. Do you know any good (preferably free) programs for drawing these types of diagrams? – kjgregory Jul 03 '14 at 17:00
  • @user2635036 The ones on Wikipedia's site look like they were just done in Visio. [LucidChart](https://www.lucidchart.com/pages/examples/uml_diagram_tool) is an online Visio competitor. Free to use. If you signup they give you a little storage space and if you pay they give you a bunch of other features. They even have UML specific shapes so it should suit your needs. – embedded.kyle Jul 03 '14 at 18:27
  • For drawing UML state machine diagrams, try the [QM graphical modeling tool](http://www.state-machine.com/qm/index.php). QM is not just a drawing tool -- it's part of a larger system. But I think you could use QM stand alone just for drawing UML state machine diagrams. – kkrambo Jul 03 '14 at 19:23
4

Use UML class diagrams for showing data structures. Use sequence diagrams to show interactions between classes and interrupt service routines (showing function calls only). Use activity diagrams to show how interrupts interact with processes (signals are good for this). An activity diagram can also be used to show the process of receiving data, parsing it, and dispatching it. This can also be represented in a static view by a package diagram where the command handler is in one package and the command parser is in another, connected by a dependency line. Use cases are good for a high level view of functionality.

The main point is that UML supports many different views (static, dynamic, logical, deployment) into your system. Don't try to express everything at once.

The diagram below shows an example of an interrupt to a process.

Example interrupt (UML Signal)

Bruce
  • 2,230
  • 18
  • 34
4

There are many of interesting approaches you can find in diagram drawing. I will post a few here. You will find a lot of Operation System and Architecture scpecific names in there such as register , event, function names and etc. It is more for representation so far, right? So he we are.

Let's begin with simple one

Just a little bit complicated than the previous one

The big one

Ruslan Gerasimov
  • 1,752
  • 1
  • 13
  • 20