ST 11 Hierarchical Refinement of Statechart (GpioIn)

In the previous post, we showed how we modeled a GPIO interrupt pin with a hierarchical state machine (HSM) named GpioIn. Its simple design enforces the following properties:

1.  It works with any input signals, even noisy ones. It avoids event queue overflow by disabling interrupts before a TRIGGER event is handled.
2. It always tracks the physical pin state, never settling at the wrong state. By enabling interrupts before checking the pin state, it always generates a TRIGGER event even when the pin state changes right after the check.

With infinite number of waveforms on the input pin, it’d be impossible to test all of them. It is therefore crucial for us to ensure its correctness right from the construction of the model. The scope capture illustrates a deliberately noisy input on Ch. 1 and how the GpioIn states tracked it on Ch. 2. (Ch. 3 shows the internal activities of the ISR and GpioIn for profiling).

Thanks to the hierarchical nature of statecharts, it adapts very well to design updates or refinements, which is particularly important with our modern agile processes. One day, the project manager would say, “I like how it works today, but it’d be great if it can detect pulses longer than a certain duration and button holds.” Sounds familiar?

Let’s compare the refined statechart (first) with the original one (second). It is striking to see the high-level states and transitions look almost the same between the two designs. Most of the behaviors for pulse and hold detection are contained within the Active state. This kind of hierarchical refinement enables developers and product owners to visualize system behaviors at different level of details or abstraction, which is hard to achieve with just code or verbal descriptions.