> Well, I agree that substituting a delay of one tick instead of using > zero is not a useful solution. Calling the expiration logic with no > delay would be better. The error handling is not good. > > However, I still say that the root cause of the problem is the logic > running on the LP work thread that is actually requesting a delay of > zero. That is a hard error and should never happen.
If this is surely an error, we can add an ASSERT(), so such errors are caught. However, I am also sure that this will break all applications that are actually using tickless. This may be a good thing (tickless is not working correctly, so the user is notified), or a bad thing (applications that were "ok" are now broken). --- There is an alternative approach that will perfectly allow single tick delays. I just tried a proof-of-concept with success. Assume a "software prescaller". According to this prescaller, the actual value of the hardware timer will be scaled-down when fed to the OS. And when values are set to the timer, they are scaled-up again. Let's say that the software prescaler is set to 10. This means that the actual hardware timer runs 10 times faster than what the OS thinks. A single OS tick will have a duration of 10 hardware timer ticks. With this trick, we can now have control over the phase of the timer. Because, even if 1 tick "slips-away", there are still 9 left. The max. inaccuracy will be 10%, instead of 100%. The phase is the key here. When you read the timer, you don't know if you are right at the start of the current tick, or if it's just about to end. That means that you have an uncertainty of 1 tick. By breaking it down to smaller bits, your uncertainty is only the fraction of the assumed tick. It's like having a fractional timer. (I am sorry, I am not sure if I explained this in an understandable way). The only problem I see with this approach, is that the maximum wait period will also be reduced, according to this prescaller. What do you think? On Thu, Jun 8, 2023 at 1:18 AM Gregory Nutt <spudan...@gmail.com> wrote: > > On 6/7/2023 2:38 PM, Fotis Panagiotopoulos wrote: > >> This is, ultimately, the problem. You can't wait for one tick. There is > >> something wrong with the delay that is asking for the single tick delay. > > The watchdogs, by design, ask for a single tick delay. > > > > Here it is: > > https://github.com/apache/nuttx/blob/master/sched/wdog/wd_start.c#L406 > > > > When the wdog->lag is 0, then the delay is set to 1 tick. > > Well, I agree that substituting a delay of one tick instead of using > zero is not a useful solution. Calling the expiration logic with no > delay would be better. The error handling is not good. > > However, I still say that the root cause of the problem is the logic > running on the LP work thread that is actually requesting a delay of > zero. That is a hard error and should never happen. > >
