Timer Accuracy and Tasks

[Don_Kirby]

I'm experiencing a problem with timing while running multiple tasks on a ZX-40. In total, there are 7 tasks, most of which are running as fast as the processor will allow. One task in particular, the trusty ol' hour meter is losing about 1/4 second per minute, and I can't seem to figure out why. The code is a simple Call Sleep command. When not 'sleeping', a persistent variable is incremented by 1 every minute. Perhaps I'm seeing the EEPROM write cycle time, but it seems way too long. I'm currently isolating the hour meter code in order to run it by itself to see if the other tasks are causing the problem.

Any ideas/suggestions?

-Don

[stevech]

the ZBasic system (VM) has an interrupt driven real time clock and calendar. Do you use that to follow elapsed time? It's correct no matter task latency, etc.

[Don_Kirby]

Well, I wasn't, and that was the problem. I failed to take into account the execution time of the code. I've since modified it to look at the minute value of the RTC and run the code once per minute rather than just sleeping the task for 60 seconds.

[dkinzer]

[Don_Kirby]

I'm revisiting this issue due to an upcoming release deadline...

The code works fine using WaitForInterval(0). The interval is set at 1 second, at which time a few lines of code are executed, a counter is incremented and the task again waits for another interval. Every minute (60 iterations according to the counter) a few more lines of code are executed along with the other code.

However, I'm loosing about 1 second every 4 hours. The loss builds gradually, so the problem is not related to the code running inside the task, or at least I don't think it is. It's not 'missing' an interval at any point.

The accuracy is acceptable for the application, but I'm curious what is causing the loss. I imagine that the prime culprit would be the oscillator, although the resolution of WaitForInterval would be my next guess.

I've set up the logic analyzer with the hope that I can get some definitive timing information, but it seems that the floppy drive has seen better days and it refuses to boot. If anyone knows where I can get a floppy drive for an HP 1652B, please let me know.


-Don

[GTBecker]

> ... a floppy drive for an HP 1652B...

FWIW, most older floppy drives die of a dry belt; you might resurrect it
with an appropriate o-ring. More recent floppies use direct-drive.


Tom

[Don_Kirby]

I haven't opened it up yet to see, but from the sounds coming from it, I suspect you're right.


-Don

[dkinzer]

[Don_Kirby]

The application sends a string of data via the serial port once per second. Something akin to an NMEA sentence. I'm watching that via HyperTerminal.

I timing it using XP synced to an atomic clock server. I expect to see +/- 1 second accuracy due to system latencies on both the PC and the ZX serial port transmission. The most recent test (still running) has lost 6 seconds over the last 30 hours. A bit less than I first suspected, but still about 1 second every 5 hours.

I've attached a test app. The module you see is 1 task of the several in the application. The only changes made were to define some variables to emulate the variables present in the rest of the application. It compiles fine, but I haven't tested on hardware yet.


-Don

[dkinzer]

[Don_Kirby]

Just so I am sure I am understanding the WaitForInterval sub correctly, perhaps you can verify..

If the interval expires, but the task is not ready (in this case, it's outputting via com1 or writing the persitent to EEPROM or both), the fact that the interval expired is recorded and the task is scheduled to run as soon as possible. The interval counter is restarted regardless of whether or not the task has actually run yet.

If the code execution time is very slightly longer than one second, the task will eventually drop a second as WaitForInterval may have set the flag twice (the task is busy from the very end of second 00:01 to right after second 00:02) but there is only an indication that the flag has been set, not how many times.

This would cause a sudden 1 second skip near the 5 hour mark, rather than the gradual lag I am seeing here.

If my understanding is correct, then the only possibility is that the RTC is either running slow, or it's missing ticks, the latter of which I didn't think would be a problem as other functions or subs that use the RTC keep track of the missed ticks.

In either case, I'm running the reporting code alone, with nothing else. The clocks are synchronized as of now. Only time will tell...(bad pun intended)



-Don

[dkinzer]

[Don_Kirby]

After testing for a little over 19 hours, I have a lag of about 5 seconds.

Better than before, but still not what I would call stellar accuracy.

I'll change the interval to 5 seconds and run the test again.

Don, what is the stated accuracy of the crystal supplied with the ZX-40 Interface Board?

[Don_Kirby]

The scope is up and running again, and it tells me that my crystal is not quite as accurate as I'd like. I'm seeing frequency variations +/- about .05 Mhz, with the trend being towards the slow side.

Does anyone have any benchmark figures for frequency accuracy using a ZX-24? When my boards get here, I'll be using the same crystal (almost) as it uses.

-Don

[Don_Kirby]