Mail Archives: djgpp-workers/2003/05/30/00:57:22
Andrew Cottrell wrote:
>>uclock() assumes 0x1800B0 tics in a day.
>>
>>There are 1193180*86400/65536 = 1573040.04 (0x1800B0) tics in an day.
>>
>>With a timer period of 65535, it would have 1573064.04 (0x1800C8) tics
>>in a day.
>>It would gain one full tic per hour, and would be out by 1.5 seconds at
>>the end of the day.
>>
>>
>Ben,
>
>Some questions:-
>Are you using the 2.04 alpha 1 or the 2.03 release? If you are using the
>2.04 alpha 1 then different code gets executed on NT/2K/XP than on
>MS-DOS/W9x/ME, so now for the next questions :-
>What OS are you using?
>
I am using 2.03 on MS-DOS. I also had a look at the code mirrored at
<http://www.ludd.luth.se/~ams/djgpp/cvs/>, and it also showed that it's
programming the clock to 65535 cycles per tic instead of 65536 cycles
per tic. Can't seem to find the code you're talking about there.
>
>If you are using 2.03 have you checked to see if the 2.04 alpha 1 changes
>fix it? I can't remember seeing a fix for this sort of problem.
>
>BTW Over last weekend at work I performed some RTC checking on a PC and on
>an embedded systems product and found that they both drifted by approx 2
>seconds a day. Then on Tuesday again at work we found a server that must
>have drifted approx 7 minutes over a long period of time. And now
>this....... Amazing number of time isses in the last week that I have seen
>in the last week.
>
>Thanks,
>Andrew
>
>
>
>
>
I'll have to try to investigate that. I'll see just what frequency the
RTC 1024Hz interrupt actually is.
I know that the RTC is supposed to use a common 32768Hz crystal, and the
PIT is supposed to use 14318180Hz / 12 (=1193181.66Hz).
Thankyou.
Ben
- Raw text -