> If you stop the timer, then wouldn't we gradually accumulate error? Like a > gradual clock drift... Not sure yet what to suggest. I need to think about > it some more...
I would like to think of it a bit more, too. But I believe that the error is always there. If you keep the timer running, you need to check the current counter value, add your wait period, and set the match register. Till you do all of these, the counter may have advanced. Its phase will surely change. You will always end up waiting less than requested, about the overhead time of this function. If you stop the timer, then there is no "time keeping" during the setup of the timer. You will always end up waiting more than requested, about the overhead time of the function. Thus, the "inaccuracies" are always there. It is just about choosing between errors towards "more" or "less. But I am not sure about the accumulation of these errors yet. It depends on the implementation of the scheduler. On Wed, Jun 7, 2023 at 10:45 PM Nathan Hartman <hartman.nat...@gmail.com> wrote: > On Wed, Jun 7, 2023 at 3:39 PM Fotis Panagiotopoulos <f.j.pa...@gmail.com> > wrote: > > > Ah! Yes this is exactly the cause. > > > > Within nxsched_resume_timer(), nxsched_timer_process() sometimes returns > > only 1 tick! > > > > Later on, up_timer_start() will try to schedule the timer expiration 1 > tick > > in the future. > > > > Since we don't know the phase of timer, the scheduled tick may be up to 1 > > tick less. > > And since we try to schedule only 1 tick, then in reality the time may be > > even close to 0! > > > > And since all the above need at least some time for the CPU to execute > > these functions, > > we can easily end up scheduling something in the past! > > > > At least in STM32 there is no protection about scheduling things to the > > past. > > As far as I can tell, it would be impossible with the current > > implementation. > > > > --- > > > > What I don't really understand is "why" it is implemented like this? > > > > During all these calculations, and setting of the match register, the > timer > > is left running. > > Thus it can run beyond our intended target while we set it. > > > > Sanity checks are impossible due to TOCTOU errors. > > > > Should the timer be stopped? > > Then possibly reset to a known value (0?), with a known phase. > > Then the match register be loaded (that now will be more accurate, since > > the phase of the clock is known), > > And then restart the timer. > > > > If you stop the timer, then wouldn't we gradually accumulate error? Like a > gradual clock drift... Not sure yet what to suggest. I need to think about > it some more... > > Nathan >
