Embedded-hal: Timer countdown start contract for multiple calls

[droogmic]

The countdown trait states:

self.start(count); block!(self.wait()); MUST block for AT LEAST the time specified by count.

The effect of calling start a second time is unclear.

One interpretation is that the countdown restarts; consider a countdown that does not restart (possibly because cancel has not been called):

self.start(5);
nop;
self.start(10);
block!(self.wait());

The contract on self.start(10) would not hold. (This is true even if this were an upcounting timer and the final count were updated by self.start(10) , as the timer count has already increased.)

[hannobraun]

Thank you for opening this issue, @droogmic. I agree with your interpretation, and the timer restarting is certainly the most sensible actions for the uses cases that I've seen so far.

I'd like to leave this open for a while to see if there are any disagreements, but from my perspective, it seems the correct action is to update the documentation of CountDown::start to clearly state that the documented contract implies a restart.