Request instructionCounter in GodmodeState

[jgfoster]

Sometimes we need to test not just the value of pins but the order in which they are set. For example, many devices (such as LiquidCrystal) have a "clock" pin that is used to inform the device that the other pins have now been populated with useful values (see LiquidCrystal.cpp:303).

At first it seems that this could be done by incrementing the microsecond clock with each instruction but this is unrealistic (it implies a 1MHz machine) and makes some other tests less practical (it is nice that Blink can test for exactly microseconds for a delay() call).

My suggestion is that each event also have an instruction counter so we could determine what pin values were set before the clock pulse. Or is there something that does this that I'm missing?

[ianfixes]

The closest thing I got to was manually incrementing the clock after calls (in this hokey example where I make the time increments the fibonacci sequence to see what non-incremental jumps in time look like during testing. But this does nothing for things that happen within a library -- in that case all the events will have the same time.

This is related to #136 and #145

My rough idea was to make a nice way to report godmode changes as events that the test code could somehow subscribe to. That would allow you to set your own delays for the various function calls. I'm not sure yet how I'd structure that into what's there already, but that's as far as the idea got.

[jgfoster]

My rough idea was to make a nice way to report godmode changes as events that the test code could somehow subscribe to.

I'm interested in this idea. I see that PinHistory is a subclass of ObservableDataStream and that a test could subscribe to an individual pin (perhaps a clock pin). In what way is this insufficient? I started down a path of adding a general event, but (while I like it) now wonder if it is needed.

[jgfoster]

Now that I'm using ObservableDataStream I'm able to capture the events I want in their proper order so I'm happy to have this closed and since you tagged it as a duplicate I'll assume that keeping it open doesn't add much value (though you are certainly free to reopen it!).

[ianfixes]

I'd like to steer the conversation to those other issues since the folks who raised them have a broader sense of use cases than I do and I'm really interested in their opinions.