Re: RTC

Started by Art Church March 12, 2005
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



--- 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