patacongo edited a comment on pull request #1726:
URL: https://github.com/apache/incubator-nuttx/pull/1726#issuecomment-687904015
> Let me look at STM32.
It appears that STM32 sets a zero interval timeout. So the interrupt and
call to nxsched_alarm_expiration() will occurr immediately.
553 /* Set up to receive the callback when the counter overflow occurs
*/
554
555 STM32_TIM_SETISR(g_tickless.tch, stm32_tickless_handler, NULL, 0);
556
558 /* Initialize interval to zero */
559
560 STM32_TIM_SETCOMPARE(g_tickless.tch, g_tickless.channel, 0);
561
562 /* Setup compare channel for the interval timing */
563
564 stm32_tickless_setchannel(g_tickless.channel);
565
566 /* Set timer period */
567
569 STM32_TIM_SETPERIOD(g_tickless.tch, UINT32_MAX);
579
580 /* Initialize the counter */
581
582 STM32_TIM_SETMODE(g_tickless.tch, STM32_TIM_MODE_UP);
583
584 /* Start the timer */
585
586 STM32_TIM_ACKINT(g_tickless.tch, GTIM_SR_UIF);
587 STM32_TIM_ENABLEINT(g_tickless.tch, GTIM_DIER_UIE);
Am I interpreting that correctly? The match value is set to zero, the timer
is started, then interrupts are enabled.
Calling nxsched_timer_expiration() has the effect of calling
nxched_timer_start() to start the interval timer. So I think that these have
the same: Setting up an initial 0-length interval or calling
nxsched_tiner_expiration() directly.
NOTICE that tickless mode does not have the drift that you were concerned
about when using the oneshot timer for a periodic event: The tickless mode
uses both a free-running and a one-shot timer (which might be one or two
times). So it gets the time that the interval timer is processed directly from
the free-running timer.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
