Pause()

GTBecker · Joined: 18 Jan 2006 Location: Cape Coral

Don, of the parameter, the Pause() documentation description says "The amount of time to pause, in seconds (Single) or Timer 0 ticks (int16)" but the example and routine description, I believe incorrectly, suggest that its resolution is 1/230400Hz. Testing suggests that it is, indeed, running at the 512Hz tick rate.

Is the documentation incorrect, or is this a bug?

mikep · Joined: 24 Sep 2005 Location: Austin, TX

The documentation is correct but I had to read it twice to fully understand it.

Timer0 ticks are indeed every 4.34 us. 450 of these Timer0 ticks makes one RTC tick which is 1/512 of a second. Sleep and Delay use RTC ticks whereas Pause uses Timer0 ticks. Task scheduling happens every RTC tick.

The maximum pause length is 65535 * 4.34us = 284,422us (or roughly 284ms as documented).

GTBecker · Joined: 18 Jan 2006 Location: Cape Coral

Why does Pause(1) take 1.953mS?

GTBecker · Joined: 18 Jan 2006 Location: Cape Coral

Try this, with both Pause() and Sleep(), with identical results:

mikep · Joined: 24 Sep 2005 Location: Austin, TX

GTBecker · Joined: 18 Jan 2006 Location: Cape Coral

Unless Heisenberg is at work (quite possible in a multitasking environment), my ElapsedTime tool shows that Pause(int16) is indeed more accurate and consistent than is Sleep(int16), but it is not more resolute, as the documentation suggests. The long-term mean of both is identical, in ~1.953mS increments according to the int16 value. The example of Pause(2304), which the comment says it equivalent to Pause(0.01), appears to not be correct.

Pause(single), though, does resolve better than Sleep(single). Pause(0.010) shows a spread of ~4.34uS, while Sleep(0.010) shows a spread of about four times that. Pause(single) does it better, but both still round (low) to the nearest tick, ~9.77mS. Pause(0.010) does not produce a 10mS delay despite its faster timebase.

Pause(0.010):
Max= 9.767794E-03S, Min= 9.763454E-03S, Spread= 4.339962E-06S, Mean(5000)= 9.765765E-03S (102.3985Hz)

Sleep(0.010):
Max= 9.771591E-03S, Min= 9.7564E-03S, Spread= 1.51908E-05S, Mean(5000)= 9.765449E-03S (102.4018Hz)

Overall, both forms of Pause() look faulty to me.

dkinzer · Site Admin Joined: 03 Sep 2005 Location: Portland, OR

Mike is correct in that the units of Pause() are low level ticks of the RTC timer which runs at 1/64th of the CPU frequency or 230.4KHz. The RTC timer is set up to generate an interrupt every 225 of these ticks (yielding an interrupt rate of 1024Hz). The RTC tick value is updated every other interrupt yielding an RTC tick rate of 512Hz.

I'll have to check the performance again using a logic analyzer but the last time I did so the timing was spot on.

One difference between Sleep() and Pause() is that another task may run if you call Sleep() but not so with Pause().

GTBecker · Joined: 18 Jan 2006 Location: Cape Coral

dkinzer · Site Admin Joined: 03 Sep 2005 Location: Portland, OR

GTBecker · Joined: 18 Jan 2006 Location: Cape Coral

dkinzer · Site Admin Joined: 03 Sep 2005 Location: Portland, OR

GTBecker · Joined: 18 Jan 2006 Location: Cape Coral

Pause is better, but the spread (jitter) is much greater. The previous compiler and library yielded 4.4uS spread (around an RTCTick); the new is ~9 times greater, but around the correct period.

dkinzer · Site Admin Joined: 03 Sep 2005 Location: Portland, OR

GTBecker · Joined: 18 Jan 2006 Location: Cape Coral

It is interesting that the timing spread of Pause() now is almost always ~43.4uS (4.34uS*10, of course), sometimes one tick less, 39.06uS. I guess I was spoiled by the perhaps artificially-low one-tick 4.34uS spread when the function was misbehaving, implicitly synchronized to the RTCTick, as you suggest. Still, it produces very good timed delays now.

I tried several values I thought might be practical, like a half-cycle of 60Hz:

That's about 9.1% long.

One-quarter second:

+0.03%

A quarter-second using Sleep():

Max= 0.2500044S, Min= 0.2499957S, Spread= 8.687374E-06S, Mean(50)= 0.25S (4.0Hz)

The apparent error here is essentially zero since the timing mechanism and the timed object are based on the same timebase. [Strictly, everything in the machine is based on the same timebase, but the ~asynchronous nature of Pause() makes it less precise than exact multiples of the RTCTick, as 0.25S is, I think.

It should be very handy for odd, short periods.

GTBecker · Joined: 18 Jan 2006 Location: Cape Coral

I'm having some difficulty with Pause, again, and I'm having trouble building a simple demonstrable case.

In some code, a ZX-24n behaves as if it interprets the Single-type parameter as Timer0 clocks in the following, instead of real time: