Here is the code that I tried, and it seems to be working nicely: https://github.com/apache/nuttx/pull/9546
On Thu, Jun 15, 2023 at 9:59 PM Fotis Panagiotopoulos <f.j.pa...@gmail.com> wrote: > > 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. >> >>
