[test] Better hardware unit tests using simple on-device logic analyzer

[salkinium]

This adds the generic modm::GpioSampler driver which uses the hardware edge detection features of the Input to generate a EXTI interrupt, which writes the DWT->CYCCNT value into the sample array. The CYCCNT value is truncated to 31-bits and cast into a signed integer, with the sign bit encoding the Gpio::read() value of the edge event (ie. positive is modm::Gpio::High, negative is Low).

This should make it easier to write hwut style tests with the current unittest framework, and most importantly without any external instrumentation.

Note, this approach will not work well on AVRs, since the exti interrupts need to be nested and high-priority to be able to interrupt the HAL interrupt handlers.
This may also not work if the input buffer is disconnected by the Alternate Function (only for Analog mode I believe).

cc @strongly-typed @rleh @chris-durand

[salkinium]

Related: https://blog.janestreet.com/using-ascii-waveforms-to-test-hardware-designs/

[salkinium]

I'm merging this as is, since the GpioSampler won't get any better than this performance and API wise, and while the LogicAnalyzer isn't super useful, it is functional and can already be used to write tests.

[salkinium]

cc @henrikssn this is somewhat related to your SAMD EXTI work, but with a focus on on-device unit testing, ie. having the logic analyzer on the same device as the test.
In my tests the entire interrupt was between 100-150 cycles with two pins, so at 100MHz, you could sample a ~1MHz SPI signal. That's pretty good for no extra hardware (not even external wires).

[salkinium]

The CYCCNT value is truncated to 31-bits and cast into a signed integer, with the sign bit encoding the Gpio::read() value of the edge event (ie. positive is modm::Gpio::High, negative is Low).

I should've probably used the lowest bit for encoding the edge event, since the interrupt latency already masks the lowest 5-7 bits or anyways. A well…

[henrikssn]

Very cool! The only suggestion I have here for API is to support tuple-style getters in the Handler to make it more clear in the unit tests which pin you are asserting on.

TEST_ASSERT_EQUALS(get<Sck>(r).size(), 1u);