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
Timer Accuracy and Tasks
You could also employ WaitForInterval() to provide the timing:Don_Kirby wrote: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.
Code: Select all
...
Call SetInterval(60.0)
Do
Call WaitForInterval(0)
' this code will be executed once per minute
...
Loop- Don Kinzer
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
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
Timer Accuracy and Tasks
> ... 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
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
Tom
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
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
- Attachments
-
- TimingTest.zip
- (3.34 KiB) Downloaded 3349 times
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
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
Your conjecture regarding the operation is essentially correct. If a task awaiting the expiration of the interval cannot run before the interval expires a second time, it will effectively miss the first one.Don_Kirby wrote:Just so I am sure I am understanding the WaitForInterval sub correctly, perhaps you can verify..
It would seem that changing the interval to a larger value (say, 5 seconds) might confirm that the potential problem you mentioned is not an issue.
- Don Kinzer
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
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
- Attachments
-
- IMG00135.jpg
- Scope screenshot
- (224.77 KiB) Downloaded 3077 times
Re: Timer Accuracy and Tasks
You hit the nail on the head Tom. Thanks.GTBecker wrote: most older floppy drives die of a dry belt; you might resurrect it with an appropriate o-ring.
-Don