Searching \ for '[PIC]: Measuring Frequency with a PIC' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Measuring Frequency with a PIC'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Measuring Frequency with a PIC'
2001\01\31@104945 by Brian Gregory

flavicon
face
Measuring Frequency with a PIC.

I need to measure the frequency of a square(ish) wave at about 1000 - 1500Hz
to about 20Hz resolution using a PIC16C710/711/715 PIC. Absolute accuracy is
not required, I just need to check for an approx 90Hz change in input
frequency from normal.

Anybody got any ideas?

My first thought was to change to a PIC with a CCP unit and use that but
when I read up on the CCP it doesn't look as if it's really that suitable.

My current thinking is to feed the signal into RA4/T0CKI and use timer 0.
The idea would be that when I need to read the frequency I disable all
interrupts, change Timer 0 over from whatever it was doing to external
clock,
clear it and do a software delay of 0.1 sec. Then I read the value from
Timer 0, set timer 0 back as it was (probably generating tick interrupts)
and re enable interrupts.

Can anybody see anything wrong with that?

TIA

Brian Gregory.
spam_OUTbriangTakeThisOuTspamcix.compulink.co.uk

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2001\01\31@105818 by James Paul

flavicon
face
Brian,

That should work fine.  Microship has an App Note on this very thing.
Can't recall the number off hand, but it was one of the early ones.
Check out the Microchip website to find it.  All the software is done
in assembly though.

                                               Regards,

                                                 Jim



On Wed, 31 January 2001, Brian Gregory wrote:

{Quote hidden}

EraseMEjimspam_OUTspamTakeThisOuTjpes.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu


2001\01\31@112951 by Dan Michaels

flavicon
face
Brian Gregory wrote:
>Measuring Frequency with a PIC.
>
>I need to measure the frequency of a square(ish) wave at about 1000 - 1500Hz
>to about 20Hz resolution using a PIC16C710/711/715 PIC. Absolute accuracy is
>not required, I just need to check for an approx 90Hz change in input
>frequency from normal.
>
>Anybody got any ideas?
>

Take a look at Mchp appnote AN592.
=============

>My first thought was to change to a PIC with a CCP unit and use that but
>when I read up on the CCP it doesn't look as if it's really that suitable.
>

With one of these PICs, 72/73/74/76/etc, you can simply use Timer1 as
a straight-forward 16-bit counter with prescaler, and Timer0 to clock
the duration of counting. Despite what the specs say about input signal
risetimes/periods [which is very confusing and has been revised several
times in the past couple of years], this channel will easily measure
pulse frequencies to over 50 Mhz.

hope this helps,
- Dan Michaels
Oricom Technologies
http://www.oricomtech.com
=========================

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\01\31@135634 by Thomas McGahee

flavicon
face
If you are already generating tick interrupts using timer0,
why not do your period measurement using ticks instead of
say .1 second? This works BEST, of course, when the ticks
are something nice, like once every ms, BUT you can actually
use almost any tick size if you are sneaky.

Let's first take the case where the tick size is something
nice like once each ms. To get a period of .1 second you
would count for 100 ticks. The counting would be done in the
interrupt routine. Prefereably at the beginning. A COUNTDOWN
register is decremented if a flag called DOCOUNT is High.
Otherwise the counter (which can be 8 bit or 16 bit) is
left untouched. Once the COUNTDOWN register reaches zero,
the count value in the timer connected to the external frequency
to be measured is copied over to a register pair TOTCNTHI and
TOTCNTLO. Once the count has been transferred, DOCOUNT is
set LOW to indicate that the count has been copied.

An external routine begins by setting DOCOUNT LOW.
Then the appropriate timer is cleared.
The TICKCOUNTER is set to 100 so that the gate time is 100 ticks.
DOCOUNT is now set HIGH.
The state of DOCOUNT is monitored.
When DOCOUNT goes LOW that indicates that the gating period is done.
The frequency can now be determined as totalcounts/(100*ticktime).

The advantage of this scheme is that all other normal tick
related interrupt processing can continue on as usual
during the time the frequency counting is going on.

Another nice feature is that once the interrupt routine
has transferred the frequency count data to TOTCNTHI and TOTCNTLO,
the external routine that set DOCOUNT HIGH can go on and do
other useful things without worrying about missing the flipping
of DOCOUNT LOW by the interrupt routine. The data will remain
as-is until the routine itself clears it and starts another
frequency measurement by setting DOCOUNT HIGH again.
In other words, the routine does not have to hang around
in a loop waiting for DOCOUNT to go low. It is enough
to simply check it once in a while to see if it has gone low.


If you are using prescaling on the input frequency, then you
will have to use the usual trick to determine the count
contained in the low byte.

******
When the tick interval is NOT something nice like once every ms, then
you may have to do a little massaging of the data to convert
it into a frequency value. Other than that, the technique would
be the same.

***********
Alternate method that does not require the usual trick:

Instead of using one of the timers to handle the frequency
count, instead maintain a two register counter of your own.

To find the frequency do the following:

findfrequency:
    Clear your two-register counter MYCOUNTER.
    Set TICKCOUNTER to 100. (gate period is 100 ms in this example)
    SET DOCOUNT flag=1. (Countdown begins at next interrupt)

checkdocount:
    IF DOCOUNT=0 then GOTO countdone (interrupt will clear DOCOUNT)
    Otherwise {Increment two-register counter MYCOUNTER
              GOTO checkdocount}

countdone:
   Calculate frequency using frequency=MYCOUNTER/TIME
   (where TIME is .1 second)
   (done)

Fr. Tom McGahee




{Original Message removed}

2001\01\31@163646 by Olin Lathrop

face picon face
> I need to measure the frequency of a square(ish) wave at about 1000 -
1500Hz
> to about 20Hz resolution using a PIC16C710/711/715 PIC. Absolute accuracy
is
> not required, I just need to check for an approx 90Hz change in input
> frequency from normal.
>
> Anybody got any ideas?
>
> My first thought was to change to a PIC with a CCP unit and use that but
> when I read up on the CCP it doesn't look as if it's really that suitable.

Yes, you could switch to a 16C712 or '716 which have CCP modules.  These are
ideally suited to measuring period.  I've done this many times.  What was
the problem you saw with measuring period with a CCP module?

> My current thinking is to feed the signal into RA4/T0CKI and use timer 0.
> The idea would be that when I need to read the frequency I disable all
> interrupts, change Timer 0 over from whatever it was doing to external
> clock,
> clear it and do a software delay of 0.1 sec. Then I read the value from
> Timer 0, set timer 0 back as it was (probably generating tick interrupts)
> and re enable interrupts.

That would work, but there are other approches too.  Fortunately you have a
relatively low frequency and only need 20Hz resolution.  You could therefore
just count cycles over a 50mS period, or longer if you can tolerate getting
an answer less often.  1500Hz is slow enough to allow an interrupt every
cycle.  You could use timer 0 to set up a periodic 50mS or 100mS interrupt,
then have your input frequency trigger an RB0 interrupt every cycle.  You
save the old value then clear the counter every timer 0 interrupt, and
increment the counter every RB0 interrupt.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, KILLspamolinKILLspamspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\01\31@180654 by briang

flavicon
face
In-Reply-To: <001701c08bca$a2742830$260bf6cd@pc>

Olin Lathrop <spamBeGoneolin_piclistspamBeGonespamEMBEDINC.COM> wrote:

> Yes, you could switch to a 16C712 or '716 which have CCP modules.  These are
> ideally suited to measuring period.  I've done this many times.  What was
> the problem you saw with measuring period with a CCP module?

I may have been mistaken.
Note though that measuring the period of one cycle would not be accurate
enough because the signal may have jitter on it.

If I could measure the length of a few cycles (ideally consecutive cycles) and
average them I guess that would work.

> That would work, but there are other approches too.  Fortunately you have a
> relatively low frequency and only need 20Hz resolution.  You could therefore
> just count cycles over a 50mS period, or longer if you can tolerate getting
> an answer less often.  1500Hz is slow enough to allow an interrupt every
> cycle.  You could use timer 0 to set up a periodic 50mS or 100mS interrupt,
> then have your input frequency trigger an RB0 interrupt every cycle.  You
> save the old value then clear the counter every timer 0 interrupt, and
> increment the counter every RB0 interrupt.

I hadn't thought of having an interrupt every cycle but you are right, the PIC
should be fast enough - just (I'm programming in 'C' it would easily be fast
enough in assembler).

I think maybe that's what Thomas McGahee meant in his suggestion though I
don't think he actually said how the cycle counter would get incremented.

Thanks.

Brian Gregory.
TakeThisOuTbriangEraseMEspamspam_OUTcix.compulink.co.uk

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu



'[PIC]: Measuring Frequency with a PIC'
2001\02\01@084048 by Michael Rigby-Jones
flavicon
face
> Olin Lathrop <olin_piclistEraseMEspam.....EMBEDINC.COM> wrote:
>
> > Yes, you could switch to a 16C712 or '716 which have CCP modules.  These
> are
> > ideally suited to measuring period.  I've done this many times.  What
> was
> > the problem you saw with measuring period with a CCP module?
>
> {Original Message removed}

2001\02\02@090531 by Olin Lathrop

face picon face
> > Yes, you could switch to a 16C712 or '716 which have CCP modules.  These
are
> > ideally suited to measuring period.  I've done this many times.  What
was
> > the problem you saw with measuring period with a CCP module?
>
> I may have been mistaken.
> Note though that measuring the period of one cycle would not be accurate
> enough because the signal may have jitter on it.
>
> If I could measure the length of a few cycles (ideally consecutive cycles)
and
> average them I guess that would work.

I usually use a single pole low pass filter.  These are computationally
simple and require only one value to be kept.  You can think of that as a
"weighed average" with the more recent readings having higher weight.

> I hadn't thought of having an interrupt every cycle but you are right, the
PIC
> should be fast enough - just (I'm programming in 'C' it would easily be
fast
> enough in assembler).

I can't say what kind of mess your compiler may leave, but I routinely use
1mS interrupts on PICs.  At 20MHz clock that is one interrupt every 5000
instructions.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, EraseMEolinspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\02\02@090535 by Olin Lathrop

face picon face
> So you could average 4 or 16 cycles with only a tiny software overhead.
> Note that by doing this you effectively reduce the maximum pulse length
you
> can measure before the counter rolls over although I guess you could
capture
> the roll over interrupt and increment a counter to give more resolution.
> Not tried that but should work.

The timer 1 wrap around only needs to be dealt with once every 65000
instructions.  I usually set up a timer for about half that which sets a
flag so that the foreground event loop handles the wrap around when it gets
to it.  Note that you can simplify things by only dealing with the high byte
of timer 1 in the wrap handler.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinEraseMEspamEraseMEembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...