Closed Wallacoloo closed 9 years ago
In the spirit of unit testing, it may be best to NOT have something like a Servo verify that the IoPins are actually set. Rather, the servo verifies that it exposes the correct information to the State, and then the State verifies that it processes that information correctly and sends the right bits to the Scheduler, and so on (this isn't to say that IO doesn't need to be tested, just that it should only be tested by the relevant classes).
Currently, when you do something complicated that should eventually lead to an IoPin write, it's very difficult to tell if it actually resulted in one. There are a few possible solutions to this:
lastDigitalWrite()
function. Downsides: not all writes go through IoPin. OutputEvents, for example, only allow access to thePrimitiveIoPin
(it's near impossible to provide access to the IoPin itself, due to its non-copyable nature. Plus, the OutputEvent doesn't need the extra information that the IoPin wraps). Also, a non-generic HardwareScheduler implementation might not directly call PrimitiveIoPin::digitalWrite (e.g. the RPi DMA scheduler).onOutputEventProcessed
handler function into the Scheduler that gets called whenever the Scheduler relays an OutputEvent to HardwareScheduler.queue(). Downsides: This only guarantees that the event reaches the HardwareScheduler; not that it's actually processed or processed at the correct time.PrimitiveIoPin
track its own state when DO_TESTS=1. Downsides: most invasive. Extra work for EVERY platform.Note: in general, there's not always a way to actually verify that a pin IS set, without configuring another input to be directly connected to it. This is because the pin can be set by a peripheral other than the CPU (e.g. DMA). On the Raspberry Pi though, the GPLEV register will read the value of an input OR an output.
Also, although it may only be possible to generically test IO propagation through to the point where the platform-specific HardwareScheduler takes hold of it, platform-specific testing could be employed to test that any OutputEvent reaching the HardwareScheduler is handled correctly. So, option 2 (the
onOutputEventProcessed
callback) is perhaps the best option.