zdebanos opened a new pull request, #15781: URL: https://github.com/apache/nuttx/pull/15781
The CPCSTOP has a negative effect on the periodic timer operation. This causes the timer of stop when and overrun occurs. Timer must be then restarted in the interrupt. However, as interrupts are not infinitely fast, this prolongs the next timeout. ## Summary I've been doing several experiments with control applications. The sampling was achieved by configuring a timer driver using the `TCIOC_NOTIFICATION` ioctl call. However, I spotted the achieved sampling frequency (using a simple SW counter in a high prio task) was smaller than the configured one. This was caused by a badly configured timer. In `sam_tc_lowerhalf.c`, it was assumed the timer stops and resets itself when an overrun occurs. The timer needed to be restarted in the overrun interrupt handler. This introduced a small but nonnegligible delay so the period was actually `set period + irq delay`. If CPCSTOP is not used, the timer just keeps running when it overruns. A potential problem is when `periodic = false` and the period is so small it overruns more than once before the callback has been processed. But that is unlikely. ## Impact I'd like to encourage all arch developers who understand timers to have a look if all architectures don't suffer from this problem, as this approach should make fast sampling possible. ## Testing Tested on a local SAMV7 hardware in a control loop (8 kHz). Firstly, `bool periodic = true` in the `timer_notify_s` struct. The measured frequency now matches the set one. Secondly, `bool periodic = false`. The task wakes up only once. -- 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: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
