[Feature] pbio/os: Add an API for a fixed *frequency* timers

[ArcaneNibble]

Twice now I've wanted to run some code at a fixed frequency rather than after a fixed delay. I've been achieving this by using timer.start += timer.duration;, but this very much feels like it violates some abstraction boundaries. We should probably have a proper API for this, but I'm not sure how it'd look. PBIO_OS_AWAIT_NEXT_PERIOD?

[dlech]

With the etimer from contiki, there was reset and restart APIs for this. I.e. you would wait for the timer, do some work, then call one of the two. The difference being that one would be timer.start += timer.duration; which was the most commonly used one, but the other was timer.start = now; which was needed on occasion. So I would be happy with just having a timer reset function like we are used to.

[laurensvalk]

With the etimer from contiki, there was reset and restart APIs for this. I.e. you would wait for the timer, do some work, then call one of the two. The difference being that one would be timer.start += timer.duration; which was the most commonly used one, but the other was timer.start = now; which was needed on occasion. So I would be happy with just having a timer reset function like we are used to.

👍

Coming up.

The only thing I would change is the naming. I could never quite remember which was reset and which was restart. Extending the timeout seems easy to remember.

void pbio_os_timer_extend(pbio_os_timer_t *timer) {
    timer->start += timer->duration;
}

but the other was timer.start = now; which was needed on occasion.

Since this is only used occasionally, we could perhaps call the existing pbio_os_timer_set for this, since it sets timer.start = now.

[dlech]

the existing pbio_os_timer_set

To make the naming a bit more consistent with the new pbio_os_timer_extend(), I would be tempted to rename pbio_os_timer_set() to pbio_os_timer_start()

[laurensvalk]

Works for me.