Concepts

A good diagram can help us understand and communicate a complex process. In traditional development, process diagrams are only connected to the code that implements them by manual translation; this translaction work must be repeated every time there's a change. In Pictorus, code is automatically generated from a diagram, saving work, reducing translation errors, and reducing the complexity of coding, while retaining the benefits of a language well-suited to safe efficient embedded development.

Additionally, in Pictorus there are no "intermediate representations" common in legacy simulation tools. Meaning, everything in a diagram directly generates embedded code, so even in simulation mode we can observe the exact algorithmic behavior we expect when deploying to hardware.

The essential idea is that blocks represent processing. Lines between blocks represent information flowing between blocks. The behavior of a block can be understood directly from the block by examining it. There is documentation for every kind of block. Each block has settings or variables associated with it. Component blocks are implemented as nested diagrams or Rust code.

Light Controller Example

Here is a simple application to control a light. The light can be bright, dim, or off. Diming is accomplished by rapidly turning the light on and off.

The inputs x0 and x1 enter from the left. These would come from a physical switch and the User Setting (Sum) block combines them to produce a value of zero, one, or two. A signal determining whether the light is off or on exits on the lower left. The signal on the upper left is for inspecting the input and can be ignored for now.

The User Setting is encoded thus,

The User Setting block supplies the Condition input to the Frequency Selector (Switch) block, which selects one of the remaining inputs to pass to its output. The output would control a solid-state relay to set the brightness of the lamp. The completed Light Controller example includes simulated input and output.

For those coming from a traditional programming background, this may seem unfamiliar, however the priciples of good design and good communication are universal, so it's simply a matter of learning how those principles apply in this visual world.

Navigation

Program text has a conventional linear ordering. For small programs, it is possible to print all the source files, and read every page in order. For a collection of hierarchial diagrams, the process of reviewing all the blocks and settings isn't as straightforward, because one must keep track of which blocks have been reviewed and which blocks are yet to be reviewed. Moreover, one must remember to open the settings for each block. This problem is more similar to reviewing a large program. Although one could print a large program, it is impractical. Instead, development tools enable us to quickly find definitions and references to program entities while focusing on the aspect of the program under review.

Organization

A picture is worth ten thousand words, but only sometimes. A cluttered diagram with many blocks and crossing signal lines with high-level and low-level details all jumbled together may be worse than a carefully organized program in a textual programming language. Organization is key, both visually and conceptually.

Related blocks can be grouped into higher-level reusable components. This helps us focus on smaller collections of related things.

Blocks can be arranged so that the most important signals flow in a simple line, and less important signals are below or off to the side.

Block labels can reflect the role of the blocks in the process. Comment blocks allow the author's intentions to be expressed close to the relevant blocks.

Extending Pictorus

When blocks do not yet exist for needed processing tasks and building them up from other blocks would be cumbersome, it is possible to define new blocks using Rust code. This is especially handy for reuse. We'd love to hear your ideas to make the block library more complete or more efficient.