After 333600 seconds (~3.9 days), the PT_GET_TIME() millisecond count lagged by 10 seconds, or about 30 ppm. The seconds count matches for at least 10000 seconds when using the two external oscillators. #pragma config FNOSC = PRIPLL, POSCMOD = EC, OSCIOFNC = OFFĪnd connecting a 8MHz oscillator to OSC1 (bottom of timers page) makes the ISR-driven PT_GET_TIME() millisecond count almost as accurate as the RTC. Switching SYSCLK to use the primary external oscillator input in the config_1_3_2.h file If it reads something like 1.004 Hz, then the oscillator setup is not correct! The oscilloscope measure function should give exactly 1.000 Hz. I used the one second output time pulse from the RTC to make sure the oscillator was set up correctly. Even if the oscillator is accurate and stable, there are small systematic errors which can creep in. BUT you must test the elapsed time on the RTC. The RTCC is the only way to get a reliable, long term clock. So the thread time is completely useless for a realtime clock. The ISR-driven timer would be about a day off after a year of real-time (and in fact overflows after about 2 months). This number is within the published error range of the internal RC oscillator. The actual time/date maintained by the RTCC is also displayed.Īs you can see in the screen dump below, the ISR-driven timer (SYSCLK is derived from the internal RC oscillator) was about 0.26% slow compared to the RTC oscillator.This time should be as accurate as the external RTC oscillator, which for testing was runningĪt 32768 Hz within error of the scope (±50 ppm). The number of seconds as measured by the RTCC.This time should be as accurate as the internal RC oscillator, which may run up to The number of seconds as measured by reading the ISR-driven mSec timer for the threader. ![]() This time typically runs slow because of thread overhead, which for this code is dozens of mSec.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |