xiaoxiang781216 commented on code in PR #17308:
URL: https://github.com/apache/nuttx/pull/17308#discussion_r2516652328
##########
sched/wdog/wd_start.c:
##########
@@ -313,6 +313,32 @@ int wd_start_abstick(FAR struct wdog_s *wdog, clock_t
ticks,
reassess |= wd_insert(wdog, ticks, wdentry, arg);
+ /* If the new watchdog expiration time is earlier than the current system
+ * time, trigger a timer interrupt manually. This ensures that the system
+ * processes the watchdog immediately instead of waiting for the next tick.
+ */
+
+ if (clock_compare(wdog->expired, clock_systime_ticks()))
+ {
+# ifdef CONFIG_ARCH_HAVE_IRQTRIGGER
+ if (up_timer_trigger() != OK)
Review Comment:
> OKļ¼but do you think `up_alarm_start `or `up_alarm_tick_start `is too
heavy? it involves too many tick/time conversion, and then conversion to
hardware timer count, and then set alarm count in hardware.
>
> If we use `up_timer_trigger` no these things will be needed, just set irq
request by using ` up_trigger_irq()`.
>
The new api just handle a special case, I don't think it could improve the
peformance in general. If you are interesting in the performance of timer
performance, it's better to:
1. watch https://www.youtube.com/watch?v=tqWwKLCD0dU?t=5h28m30s
2. review https://github.com/apache/nuttx/pull/17276
> By the way, I checked armv8-r generic timer implementation for nuttx alarm
arch, it looks like if `count value >> match value`, the timeout will be set to
zero, I think this may be a problem:
zero delay will trigger the interrupt immediately, why is it a problem?
--
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]
