pkarashchenko commented on pull request #5424: URL: https://github.com/apache/incubator-nuttx/pull/5424#issuecomment-1030863068
@xiaoxiang781216 I'm familiar with FreeRTOS delay interface and delays are not a part of this PR. I think that periodic POSIX timer use case that I'm trying to fix is more similar to https://freertos.org/RTOS-software-timer.html than to https://www.freertos.org/vtaskdelayuntil.html But in a proposed example ``` clock_t last_time = current_time; for (; ; ) { clock_t next_time = last_time + x; clock_t current_time = clock_systime_ticks(); int error= next_time - current_time; last_time = next_time; delay(x + error); } ``` if the task is preempted (for example for 1-2 system ticks) right before a `delay` call, then app periodic logic and compensation calculation will be screwed-up. I've been working for a years with mission critical systems and learned that lesson well. The only reliable way is to have a timer that posts a periodic event and task that is waiting for that event. Now the question is should it be a MCU HW timer or OS SW timer based on internal OS clock. @xiaoxiang781216 @patacongo please undesrtand me write, the question is not about can I or can not I code a periodic processing in a write way, but about how timers are operating. I could easily implement `board_timerhook()` and post an event to my task each third system tick and get the reliable operation. What I'm trying to say is that if there is not blockers for periodic POSIX timer to expire in time then it should expire in time (for example if I have 10ms system tick and configure POSIX timer to have periodic expiration with 30ms period then timer should expire each 30ms and not each 40ms. I'm not configuring 35ms or 37ms, but 3 multiples of system tick). If you trying to convince me that we should have crappy timers, then I'm very disappointed. How the POSIX timers are implemented, that is another question. Currently they are relying on `wdog` that has it's implemented is a way as it is designed, but if we need to change that to get reliable and well expected operation then I'm fine with that. I feel that we mixed in a discussion timers and `wdog`, so there are multiple threads in this discussion that I want to separate. I'm porting an application that is running reliably with RT Linux that have same configuration for a system clock and talking honestly I do not see any reason (strong argument) why it should not run the same with NuttX. Let's focus discussion on POSIX timers only and leave the `wdog` alone. We can have a separate discussion why we need to add one extra tick if `wd_start` is called from `wdog` expiration handler that is actually called from the timer ISR (exactly at the beginning of a phase). I agree with @patacongo that in general `wd_start` can be called at any time and we do not know are we at the beginning or in the middle or an the end of the phase, so `+1` 100% needed in general case, but if we are building a reoccurring event with `wdog` and `wd_start` is called from `wd_timer` (eventually from the system tick ISR) then adding one tick is a bit strange and IMO we just introduce the extra delay in the place where it is really not needed. -- 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]
