Hi Fabio,
Thanks for the feedback and suggestion.
I didn't think to have separate sync and read tasks. It does add a
decent amount of code when this could be solved with one or two lines
and a built in helper class, but it's a workable and reliable solution
today.
I also tested the code below but there are several potential problems
with it:
static void
blinky_task_handler(void *arg)
{
static os_time_t start;
static os_time_t stop;
hal_gpio_init_out(LED_BLINK_PIN, 1);
while (1) {
/* Measure the starting tick */
start = os_time_get();
/* Toggle the LED */
hal_gpio_toggle(LED_BLINK_PIN);
/* Measure the ending tick */
stop = os_time_get();
/* Check for overflow in tick counter */
if (stop >= start) {
os_time_delay(OS_TICKS_PER_SEC/BLINKY_RATE_HZ - (stop -
start));
} else {
/* Overflow occured */
os_time_delay(OS_TICKS_PER_SEC/BLINKY_RATE_HZ - stop +
(UINT_MAX - start) );
}
}
}
This doesn't account for situations where the read event might run
/over/ the desired rate either, which will require a check before the
overflow test if 'stop-start > OS_TICKS_PER_SECOND/BLINKY_RATE_HZ', at
which point you probably want to flag the timing overrun and maybe get a
new sample right away. There are likely other issues I'm not seeing as
well, such as making sure we don't exceed 1/2 the OS time epoch in our
delay.
Having a single helper function would let you encapsulate all these edge
cases in one call might be useful, but perhaps someone has a suggestion
about the naming or some other helpers that are worth considering ... or
disagrees that this should be included in the core at all!?
FreeRTOS, for example, has vTaskDelayUntil():
http://www.freertos.org/vtaskdelayuntil.html
K.
