tests/periph_timer_short_relative_set: initial commit

[kaspar030]

Contribution description

From the readme:

This test exposes if timer_set() with very low values (down to zero) underflows.
For each value from 100 to 0, it'll try to set a timer with that length.
In human terms, that should trigger instantly.

See this example of a timer_set() implementation:

int timer_set(tim_t dev, int channel, unsigned int timeout)                                                                    
{                                                                                                                              
    return timer_set_absolute(dev, channel, timer_read(dev) + timeout);                                                        
}                                                                                                                              

This will probably underflow if "timeout" is 0, or if an ISR interrupts
somewhere between the read and the timerSet_absolute() call.
Depending on the used frequency of the underlying timer and the time it
requires for the involved function calls, reading the timer register, doing the
addition and writing back to the register, this will also fail for higher
timeouts.

For example, as of this writing (30-Oct-19), samr21-xpro fails for values below
8, nrf52dk for values below 2.

This test will probably fail on most devices. The PR is meant to give developers a tool to improve the situation.

Testing procedure

Issues/PRs references

Found while debugging ztimer (#11874).

[MichelRottleuthner]

Good idea to add this. But with the implementation of the test I see a problem for 16 bit timers and fast 32 bit timers. I don't know of any default configuration that uses very fast 32 bit timers though.
The problem is, that the wraparound will happen so fast that it looks like it is actually working even if it is not. 16 bit at 1MHz will overflow after ~65ms and I don't think pexpect will time out before that ;)
There should be some way of comparing the observed time with the one that was requested.

[kaspar030]

The problem is, that the wraparound will happen so fast that it looks like it is actually working even if it is not. 16 bit at 1MHz will overflow after ~65ms and I don't think pexpect will time out before that ;)
There should be some way of comparing the observed time with the one that was requested.

Yes, good point. I added some logic to read the timer in a loop, counting upwards, comparing to a definable maximum delay.

[kaspar030]

@MichelRottleuthner maybe take another look?

[MichelRottleuthner]

Yep the check should do. I tested on some boards I have lying around:

pba-d-01-kw2x	iotlab-m3	nucleo-l476rg	nucleo-f103rb
success	Error @ 1	Error @ 1	Error @ 0

Some small doc /typo comments below.

[kaspar030]

@MichelRottleuthner I totally overlooked your review, sorry. All comments addressed.

[MichelRottleuthner]

All my comments were addressed you can go ahead and squash

[kaspar030]

All my comments were addressed you can go ahead and squash

• rebased, squashed

[MichelRottleuthner]

ACK

[smlng]

this assumes timer bit width is equal to platform bit width, e.g. 32 bit on 32 bit platform. However this will be wrong when using 16bit timer on a 32 bit platform, for example. See #9283 and #10493.

[MichelRottleuthner]

Thanks for jumping in! Yes, this calculation doesn't give the correct value for diff. The reason it does work in this test is because testing all values can be done in the first period before an overflow happens - but with 8 bit timers even that won't work.
Seeing the need for proper diff operation again ...I think I should have a look at #10493 soonish :)