|
Thanks Don & Tom
I have pulseouts of 0.001 which is within the 1.95 ms range. I have changed them to 0.0001 to see if this made a differance. It did. For the last hour it seems pretty much right on. This is a copy of relevant code the 0.00001 were 0.001. I have two tasks running also - one looking for buttons pushed and another that toggles a global variable ever 0.5 sec. Following code in a subroutine that is called every 0.5 sec 'starting 1 bit putpin 11,1 pulseout 12,0.0001,1 '32 bits of info for n=1 to 4 shiftout 11,12,8,osn(n) next 'finishing 3 bits 'future single leds can be used for n=1 to 3 '33,34,35 putpin 11,0 pulseout 12,0.0001,1 next Art -----Original Message----- From: Don Kinzer [mailto:] Sent: Sat 3/12/2005 11:27 AM To: Cc: Subject: [BasicX] Re: RTC --- In , "Art Church" <achurch@m...> wrote: > What is the expected accuarcy of the BasicX Real Time Clock ? - There are only two sources of error that I can think of: the accuracy of the crystal (may vary with time and temperature) and your code if it interferes with the handling of RTC interrupts (every 1.95ms). There are several system library routines (e.g. PulseOut(), PlaySound (), etc.) which may cause the RTC to miss ticks depending on their parameters. You could also cause the RTC to be inaccurate or miss ticks if you fuss with the Timer0 settings (using Register.TCCR0, Register.TCNT0, Register.TIMSK, etc.). The accuracy of a crystal is typically on the order of 30ppm or so. Yahoo! Groups Links |
Re: RTC
Started by ●March 12, 2005
Posted by ●March 12, 2005
|
--- In , "Art Church" <achurch@m...> wrote: > I have pulseouts of 0.001 which is within the 1.95 ms range. I > have changed them to 0.0001 to see if this made a difference. > It did. For the last hour it seems pretty much right on. That's interesting. I would have thought that a 1 millisecond pulse would have been OK. I assume that the code that implements PulseOut () in the BX-24 disables interrupts while performing the function. If interrupts are disabled for only 1ms, at most one RTC interrupt could possibly occur and it should be serviced as soon as interrupts are re-enabled (assuming that other higher priority interrupts have not occured also). As a side note, you might as well reduce the pulse width to something near the minimum required by the device that you're strobing, plus a safety margin. If it is 74xxx series logic, for example, even the minimum 1.085uS pulse that can be generated by PulseOut() is over 20 times as long as the minimum required pulse width. Anything longer than the minimum just wastes time - you're program can do nothing else during the pulse generation. Also note that the code generated by a call to PulseOut() converts the Single value to an integral number of timer units. If you use a constant Single value like 'Call PulseOut(12, 0.000001, 0)' the generated code ends up identical to that generated by 'Call PulseOut (12, 1, 0). On the other hand, if you use the invocation, 'Call PulseOut(12, pulseTime, 0)', where pulseTime is a Single variable, there is another 18 bytes generated to convert the value of the Single to integral timer units. If the value of pulseTime is constant, this wastes not only execution time but code space as well. Don P.S. there are other similarly useful tidbits of information about the code generated by the compiler in Mike Perks' excellent series of articles on the BasicX internals: http://home.austin.rr.com/perks/basicx/Articles |
