pkarashchenko commented on a change in pull request #5432:
URL: https://github.com/apache/incubator-nuttx/pull/5432#discussion_r800701698
##########
File path: sched/wdog/wd_start.c
##########
@@ -204,15 +214,31 @@ int wd_start(FAR struct wdog_s *wdog, sclock_t delay,
up_getpicbase(&wdog->picbase);
wdog->arg = arg;
- /* Calculate delay+1, forcing the delay into a range that we can handle */
+ /* Delay for at least one tick should be performed */
- if (delay <= 0)
+ if (delay == 0)
{
delay = 1;
}
- else if (++delay <= 0)
+ else
{
- delay--;
+ /* Calculate delay+1, forcing the delay into a range that we can
+ * handle. In general wd_start() can be called at any time and we do
+ * not know is it at the beginning in the middle or at the end of a
+ * system clock phase, so we need to add 1 tick to ensure that the
+ * operation will be delayed for at least delay number of ticks. But
+ * in a special case when wd_start() is called from a wd expiration
+ * callback that is called from a system tick interrupt handler we know
+ * that we are exactly at the beginning of a new phase so we do not
+ * need to add an extra tick in this case.
+ */
+
+ delay += g_wdexpiration_context ? 0 : 1;
Review comment:
> >
> > I can agree with 1, not with 2. Even if separate HW timer is used the
other interrupt can happen near the timer interrupt. 2 is usually mitigated by
assigning of a proper interrupt priority and enabling nested interrupts, so
can't be a valid argument in this discussion.
>
> Why do you assume other interrupt happen near the timer interrupt? Many
interrupts are trigger by the external activity, nobody can forecast when the
activity will happen.
I'm assuming that it may happen, but external interrupts may happen near
other MCU timer interrupt. The usage if a dedicated HW timer was suggested as a
solution to have more accurate timers. What I'm trying to say that in terms of
2 there is no difference between sys tick interrupt and dedicated HW timer
interrupt
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
