So, will adl_ctxSleep(1) definitely wait for exactly 18.5ms ?
Or, will it just wait until the next system tick - ie, for up to 18.5ms ?
In other words, if I want a “sleep” of at least 18.5ms, would I actually have to do adl_ctxSleep(2)
anyone?
i’m adding this tho my ‘to try’ list when i get back to work 
I certainly feel so… 
… when the adl_ctxSleep is used for a current context then this context processing is frozen during this time(duration), allowing other
contexts to continue their processing. When the sleep duration expires, the context is resumed and continues its processing… It could be compared to something like a wake up alarm… when the alarm expires , the module wakes up similarly here when the duration is completed the context processing wakes up…
Hope this helps… 
On what do you base that feeling?
But what, exactly, is that duration?
Is it:
- Until the next system tick?
- Exactly one 18.5ms unit?
- Or what?
The term “system tick” suggests to me a constantly-running clock, and that would seem to preclude the first option - leaving only the second.
Not really, I’m afraid - it doesn’t address my specific question of the precise duration of the “sleep”.
I’ve done some measuring,
i wrote a program that toggles an io-port based on a timer subscription on every TICK, and another port on a 2 TICKS timer.
what i’ve seen is that TICKs usually occur between 17.98 an 18.45 ms.
sometimes it takes over 19ms (i’ve even seen 21 ms) for a TICK to happen, but this is compensated for on the next TICK. Whitch brings the total period home in just under 37ms.
[attachment=1]tick timer sample.png[/attachment]
ok, it’s not ctxSleep(1), but it shows TICK’s happening just about on time 
.
Interesting - but, in a repeated nominally “1-tick” delay, I would expect it to get “in-sync” with the System Tick after the first one. Therefore all the subsequent delays would be expected to be exactly 1 tick
So the real question is, how long will an arbitrary, isolated, single adl_ctxSleep(1) actually sleep?
the two waveforms you see in the above screenshots are two individual timers.
they are on a 1 and 2 TICK timer.
and they are not in sync.
so i think we can conclude that there is no ‘system’ tick.
My experience sir. 
… as far as i know after testing this API , it may sleep more than 18.5 ms but not less, hence, it will wait for next system tick + time taken for the reference tick to happen…
so answering your original question…
No … . one is enough since in any case it would not be less than 18.5 ms …
Hmm… there seems to be a certain discrepancy there… 
my observations were made using a Q2686 module running firmware 7.4 (maybe things were done differently in previous versions 
)