----------

Very interesting.......

A way to get around the necessary of adding extra hardware to
"find what was left in the prescaler" may be to take two timmings.
One at divide by 256, and the second at devide by one.  Then ignore
the count of the divide by 1 RTC untill the second is up.
Then the count in the RTC should be simular to what was left in
the prescaler after the devide by 256 sample.

This concept falls apart if the frequency being sampled is
unstable (because there are two samples taken at different times)
or if the devide by 1 remaining count is near zero (the devide by
256 count may or may not have counted the last pulse).

This error could be reduced by also doing a 100 ms sample on both
divide by 256 and divide by 1m and by software smothing.  While this
method may have "some" problems, it doesn't require additional
hardware for counting.

Also, autoranging may be used to find the lowest divide by count
that can be used, and just take one sample and live with the
error of counts left in prescaler.

Another way to use the "two sampse" method (devide by 256,
devide by 1) could be to read each sample three times.  The first
time read just before the end of the one second sample, then at
the end of the one second sample and lastly, just past the end
of the one second sample.  This will give an indication of the
devide by 256 sample changing near the end of the sample time.

And the last way (that I can think of) is to have a "error"
flag/indicator.  If the devide by 1 count is too
near zero or the counts are unstable, then set the "error"
flag/indicator to show the error rate is +255 -0, and just use
the devide by 256 sample.

These ideas do not improve the operation of the PIC frequency
counter, they just reduce the parts count.

   ---------
   Bill Cornutt
   billcorn@infoserv.com
   Located in Ione California USA.
   A small town in Northern California.
   Sitting against the foothills of the Mother Lode.
   ----------------------------------------------------

>Harrison Cooper <hcooper@ES.COM> wrote:
>
>>Anyone ever implemented a frequency counter with a C84 or C54 ?
>>Schematics,source code, etc.
>
>Harrison:
>
>Since the 16C54's RTCC prescaler can be clocked at speeds WAY higher
>than the PIC's clock speed, set the prescaler to divide-by-256 and
>count the number of RTCC increments during a 1-second period.  If
>you're smart, you'll do the counting in BCD so you won't have to
>convert from hex afterwards.  Remember that each RTCC count represents
>256 pulses from your signal source; to get a truly accurate count of
>the number of pulses per second, you'll need to know the value of the
>RTCC prescaler at the end of your one-second sampling time.
>
>Since the prescaler can't be read directly, put a couple of gates
>between your signal source and the PIC's RTCC pin so that you can
>switch the signal off.  You'll also need a way to clock the RTCC pin
>one pulse at a time under PIC control.  Then, after you sample for one
>second, turn off the signal and clock the RTCC pin, counting the number
>of pulses you have to send before the RTCC register increments.  Since
>the prescaler is set to divide-by-256, subtract this number from 256
>and add it to the "256 * [number of RTCC increments]" number you've
>accumulated.  This will give you an exact (within 1 pulse) count of how
>many pulses appeared at the RTCC pin in one second.
>
>One thing you have to keep in mind is that the accuracy of the counter
>will be proportional to the accuracy of the oscillator you use for
>clocking the PIC (you need a VERY accurate 1-second sampling time).
>
>Another item to consider is that you need a very special driver between
>the signal source and the RTCC pin; most buffers won't handle the
>really high frequencies.  I'd recommend something like a -- I'm
>guessing at the part number here -- Motorola ACT132 inverter; it'll
>convert the incoming TTL signal to the CMOS levels that the RTCC pin
>needs to see, and I think it's Schmitt-triggered, too.  It should
>easily handle any frequency you'd want to measure.
>
>A friend of mine has built this circuit; it works up to 50 MHz in
>"normal" mode, and up to 1 GHz in "high-speed" mode (the high-speed
>mode interposes a hardware divide-by-64 between the signal source and
>the RTCC pin).  If you're interested in paying him for the schematic
>and source code, let me know in private e-mail and I'll give you his
>phone number.
>
>-Andy
>
>--
>Andrew Warren - fastfwd@ix.netcom.com
>Fast Forward Engineering, Vista, California
>