Hands on with the construction

- Intro

A combination of some theoretical ranting and an actual project.

In this project I wanted to test a form of debugging which merely records the system state and then enables one to replay it in an offline environment.

(Dusty academic mode on)
In this lab I wanted to test an idea I've had for some time, given a system with an initial state and then also given its input in a time series the end state of the system should be known. By storing the inputs in a sufficiently high resolution and asserting that the input values recorded are identical to the input values actually presented to the system, it should be possible to replay the scenario step by step, making observations along the way.
(Dusty academic mode off)

When doing some programming it is often not a good idea to use a debugger even if one is present. In real-time systems, timing often gets skewed and the only thing one can do is watch the state of the system at the break point, assuming that when hitting "continue" or similar we are almost certain to get bitten by "heisenbugs", i.e. bugs that either never manifests themselves in the debugger or only does manifest themselves in the debugger. So the procedure is usually:
1) Make an inspired guess of where the bug is
2) set a break point
3) Spend a lot of manual time trying to get the system to produce the bug and hit the break point
4) Look at the code, review your inspired guess.
5) go to 2)

- Designing a simple system, an electronic dice

We've all been there, lets design something simply like out of basic engineering with some digital logic, an electronic dice and - oh - a push button would be nice to have as well!

Just some resistors+leds down to ground on mpu pins and then give them +5v feed for some extra juice.
Put an arduino in and a few lines of code later you have at least one bug.

Picture of a dice with "seven" is on page

Of course you dove into the code and found the bug faster than I could write this sentence, but for the exercise we shall go about the troubleshooting in a much more complicated way. Just pretend this bug is truly obscure.

- A simple "stub" for simulating the dice on a x86 platform

Since not all you guys have an ardu just lying around, after all they are like 5 euros and take some time to get from the web shop. So here is a simulator together with the original code. It's a rather simple thing defining a main and some stubs for the I/O including the dice.ino file.
The "in.txt" file contains the I part of the I/O operations and as since it feeds the inputs to the simulator when it does a 'digitalRead' the leds will flicker when we read a 0. In the simulator the flicker is replaced with patterns on stdout:

---------
|      X |
|        |
| X     |
---------

---------
|       X |
|    X   |
| X      |
---------

---------
| X   X |
|          |
| X   X |
---------

</pre>

...

The patterns present themselves at about 1000 Hz so each time we read the button we spend 100 cycles counting.

in.txt looks something like this:
1
1
1
0
0
1
...
(much boring)

In our case the resolution is 1/10 of a second and each line corresponds to a read, so here after 0.3s the button was pressed for 0.2s etc.

- The need for debugging arises

Following this scroll for a long time will make the "seven" pattern show up

---------
| X X X |
|     X    |
| X X X |
---------

What we saw above when the dice was rolling we did not get this pattern, so this is most likely the bug we saw with the real dice.

One way to now get to chase this bug will be a conditional break

(gdb) b dice.ino:88 if store[1]==0 && store[3]==0
r
...
...

(gdb)

The leds correspond to this pattern of numbers in the store[] array in
dicesim.c:

---------...