Searching \ for '[PIC]: Frequency counting' 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/time.htm?key=count
Search entire site for: 'Frequency counting'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Frequency counting'
2001\02\20@181517 by Edson Brusque

face
flavicon
face
Hello,

   I've made a routine to make frequency counting with CCS. Code snipet
follow:

uns16 interrupt_counter;

#INT_TIMER1
void interrupt(void)
{
interrupt_counter++;
}

uns16 get_freq(void)
{
uns8 x;
uns8 counter;
float total;

PIR1.TMR1IF = 0;
PIE1.TMR1IE = 1;
INTCON.PEIE = 1;
INTCON.GIE  = 1;

T1CON.T1CKPS1 = 0;
T1CON.T1CKPS0 = 0;
// T1CON.T1OSCEN = 1;
T1CON.NOT_T1SYNC = 1;
T1CON.TMR1CS  = 0;
T1CON.TMR1ON  = 0;

interrupt_counter = 0;
TMR1H = 0;
TMR1L = 0;

// Esperando final da onda atual
while(!PORTC.B0);
while(PORTC.B0);

// Contagem do tempo necessário para fechar 32 ciclos
T1CON.TMR1ON = 1;
while(!PORTC.B0);
while(PORTC.B0);
for (x=0; x < 30; x++) {
 while(!PORTC.B0);
 while(PORTC.B0);
}
while(!PORTC.B0);
while(PORTC.B0);
T1CON.TMR1ON = 0;

total = ((float)interrupt_counter * 65536) + ((float)TMR1H * 256) +
((float)TMR1L);
total /= 32;
total = 2500000 / total;

return total;
}

   The idea here is to measure the time it takes to complete 32 cycles,
then divide it by 32 to get the period of one wave. Then divide the number
of instructions by second the PIC executes (here 2500000 with a 10MHz clock)
to get the frequency.

   But this method isn't working very reliably. Someone got a better idea?
Also, I have to implement a timeout on this routine.

   Best regards,

   Brusque

-----------------------------------
Edson Brusque
Research and Development
C.I.Tronics Lighting Designers Ltda
(47) 323-2685  /  (47) 9993-6453
Blumenau  -  SC  -  Brazil
http://www.citronics.com.br
-----------------------------------

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


2001\02\20@222223 by Dan Michaels

flavicon
face
Edson Brusque wrote:
>
>    I've made a routine to make frequency counting with CCS. Code snipet
>follow:
>

What frequency range do you want to count over?

<= 1 hz --> 100 hz

>= 10mhz

???????

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


2001\02\21@132059 by Edson Brusque

face
flavicon
face
Hello Dan,

> What frequency range do you want to count over?

   just audible frequencies. From 20Hz to 20kHz.

   Regards,

   Brusque

-----------------------------------
Edson Brusque
Research and Development
C.I.Tronics Lighting Designers Ltda
(47) 323-2685  /  (47) 9993-6453
Blumenau  -  SC  -  Brazil
http://www.citronics.com.br
-----------------------------------

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\22@160830 by Edson Brusque

face
flavicon
face
Hello All,

   I've made some alterations and put a lot of comments (in english this
time :) in my frequency counting routine (code is on the end of this email),
but it's still not working very well.

   When I put a square-wave of 1,000 Hz, it counts 2480 instructions for a
complete cycle when the correct would be 2500. Also, it tells readings like:
       2480, 2480, 2425, 2480, 2425

   I think this is really strange. The reading are more weird with lower or
higher frequencies.

   Can someone take a look at my routine? I think it deserves a good look,
because It works on a different way from the common
count-cycles-for-a-second approach.

   Best regards,

   Brusque

-----------------------------------
Edson Brusque
Research and Development
C.I.Tronics Lighting Designers Ltda
(47) 323-2685  /  (47) 9993-6453
Blumenau  -  SC  -  Brazil
http://www.citronics.com.br
-----------------------------------

****************************************
* PIC Frequency Counting using CCS PIC-C
****************************************

uns16 interrupt_counter;

// This interrupt is used during the frequency counting routine to
// implement a 32 bit counter
#INT_GLOBAL
void interrupt(void)
{
interrupt_counter++;
PIR1.TMR1IF = 0;
}

// This routine counts the frequency by getting the time (in instructions)
// it takes to complete 32 cycles
uns16 get_freq(void)
{
uns8 x;
uns8 counter;
float total;

// Now we're setting the Timer1 interrupt
PIR1.TMR1IF = 0;
PIE1.TMR1IE = 1;
INTCON.PEIE = 1;
INTCON.GIE  = 1;

// Now we're setting the Timer1 itself
T1CON.T1CKPS1 = 0;
T1CON.T1CKPS0 = 0;
// T1CON.T1OSCEN = 1;
T1CON.NOT_T1SYNC = 1;
T1CON.TMR1CS  = 0;
T1CON.TMR1ON  = 0;

// Clearing the counter (we're, obviously, using the TMR1 for this)
interrupt_counter = 0;
TMR1H = 0;
TMR1L = 0;

// Setting the direction for the pin we'll use to detect the cycles
TRISC.B7 = 1;

// Waiting for the end of the actual cycle
while(!PORTC.B7);
while(PORTC.B7);

// Counting the time (in instructions) that it takes to detect 32 cycles
T1CON.TMR1ON = 1;
for (x=0; x < 32; x++) {
 while(!PORTC.B7);
 while(PORTC.B7);
}
T1CON.TMR1ON = 0;

// Calculating the frequency from the time in instructions
total = ((float)interrupt_counter * 65536) + ((float)TMR1H * 256) +
((float)TMR1L);
total /= 32;
total = 2500000 / total;
// 2500000 is for a 10MHz clock (2,500,000 instructions for sec)

return total;
}

--
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\23@004923 by Dan Michaels

flavicon
face
> // Now we're setting the Timer1 interrupt
> PIR1.TMR1IF = 0;
> PIE1.TMR1IE = 1;
> INTCON.PEIE = 1;
> INTCON.GIE  = 1;
>

does the c compiler take into account that PIE1 is in a
different ram bank?

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\23@123454 by Edson Brusque

face
flavicon
face
Hello Dan,

> does the c compiler take into account that PIE1 is in a
> different ram bank?

   yes, it does. It's very easy to make this kind of bit manipulations in
CCS. I have a header file where:

         struct PIE1_map {
                    boolean TMR1IE;
                    boolean TMR2IE;
                    boolean CCP1IE;
                    boolean SSPIE;
                    boolean TXIE;
                    boolean RCIE;
                    boolean ADIE;
                    boolean PSPIE;
          } PIE1;

         struct PIR1_map {
                    boolean TMR1IF;
                    boolean TMR2IF;
                    boolean CCP1IF;
                    boolean SSPIF;
                    boolean TXIF;
                    boolean RCIF;
                    boolean ADIF;
                    boolean PSPIF;
          } PIR1;

         #byte PIR1    = 0x0C
         #byte PIE1    = 0x8C

   And this gives me the flexibility to do the:
           PIR1.TMR1IF = 0;
           PIE1.TMR1IE = 1;

   What do you think of about my routine?

   Best regards,

   Brusque

-----------------------------------
Edson Brusque
Research and Development
C.I.Tronics Lighting Designers Ltda
(47) 323-2685  /  (47) 9993-6453
Blumenau  -  SC  -  Brazil
http://www.citronics.com.br
-----------------------------------

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\23@132647 by Dan Michaels

flavicon
face
Brusque wrote:

>    What do you think of about my routine?
>

Your routine looks interesting, but I was wondering whether
the interrupt and other overhead - due to using C - may be
producing your incorrect answers. All of your answers are
on the low side, meaning the timing took slightly too long.

In my timer/counter routines, I always use assembler, because
then I know exactly how many clock cycles everything takes,
and still the overhead is sometimes a problem - but then my routines
use timer1 to measure up to 60 Mhz.

Using (float)casting, I guess round-off errors during division
isn't going to be a problem.

But given your algorithm with all of its inversons/etc, do you
have any idea how many Timer1 ticks is the difference between
measuring 2480 and 2500?

- dan

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\23@150218 by Drew Vassallo

picon face
my timer/counter routines, I always use assembler, because
>then I know exactly how many clock cycles everything takes,
>and still the overhead is sometimes a problem - but then my routines
>use timer1 to measure up to 60 Mhz.

How do you measure 60MHz with a PIC?
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\23@150844 by Edson Brusque

face
flavicon
face
Hello Dan,

> Your routine looks interesting, but I was wondering whether
> the interrupt and other overhead - due to using C - may be
> producing your incorrect answers. All of your answers are
> on the low side, meaning the timing took slightly too long.

   I've took a look at the Assembly code generated by the compiler
and it's very tight.

> In my timer/counter routines, I always use assembler, because
> then I know exactly how many clock cycles everything takes,
> and still the overhead is sometimes a problem - but then my routines
> use timer1 to measure up to 60 Mhz.

   The maximum frequency this would have to count would be about 20khz.
The strange fact is that when I suply a 100hz square wave to the circuit,
the countings turns a lot random.

   Could you please suply some code excerpts from your frequency
counting routines?

> Using (float)casting, I guess round-off errors during division
> isn't going to be a problem.

   I'm only using it because of the need for a 32 bit counting. Maybe
I'll try to make some kind of 32 bit integer maths with CCS.

> But given your algorithm with all of its inversons/etc, do you
> have any idea how many Timer1 ticks is the difference between
> measuring 2480 and 2500?

   That values are in ticks. The input on the PIC was a 1000hz square
wave. Every cycle takes 1ms. The Timer1 tickles 2500 times in one 1ms
with 10mhz clock.

   Regards,

   Brusque

-----------------------------------
Edson Brusque
Research and Development
C.I.Tronics Lighting Designers Ltda
(47) 323-2685  /  (47) 9993-6453
Blumenau  -  SC  -  Brazil
http://www.citronics.com.br
-----------------------------------

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\23@150849 by Robert Rolf

picon face
Drew Vassallo wrote:
>
> my timer/counter routines, I always use assembler, because
> >then I know exactly how many clock cycles everything takes,
> >and still the overhead is sometimes a problem - but then my routines
> >use timer1 to measure up to 60 Mhz.
>
> How do you measure 60MHz with a PIC?

Very very quickly.

More likely, with an external prescaler.

R

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\23@153828 by Spehro Pefhany

picon face
At 03:02 PM 2/23/01 -0500, you wrote:
>my timer/counter routines, I always use assembler, because
>>then I know exactly how many clock cycles everything takes,
>>and still the overhead is sometimes a problem - but then my routines
>>use timer1 to measure up to 60 Mhz.
>
>How do you measure 60MHz with a PIC?

The baseline PICs will probably work up that frequency, at room
temperature and with a square wave input. The data sheet says 50MHz
for the PIC16C54C, for example, over the temperature range, as
a "characterized but not tested" minimum. (Page 126).

Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamKILLspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\23@155448 by Dan Michaels

flavicon
face
Robert Rolf wrote:
>Drew Vassallo wrote:
>>
>> my timer/counter routines, I always use assembler, because
>> >then I know exactly how many clock cycles everything takes,
>> >and still the overhead is sometimes a problem - but then my routines
>> >use timer1 to measure up to 60 Mhz.
>>
>> How do you measure 60MHz with a PIC?
>
>Very very quickly.
>
>More likely, with an external prescaler.
>


Actually, I use the "internal" prescaler. With an external prescaler,
ie 74AC74 it can do >150 Mhz [maybe faster, but I don't have anything
goes any faster to feed in].

Basically, 16-bit Timer1 fed by the internal prescaler on pin RC0
responds successfully to signals up to 50-60 Mhz [but not to 80 or 100].
Use Timer0 to count seconds, or fractions thereof, and another counter
in RAM to keep track of TMR1IF overflows. Note - this does not require
using interrupts, just polling the flag.

The errors come in, for very fast input frequencies, in terms of the
#times the input changes as related to the overhead of monitoring the
timer flags. In other words, if it takes 2 usec to execute the loop,
during which the input changes 100 times, there is your error.

Also note --> if you look at the Mchp datasheets regarding risetimes/etc
for Timer1, you will become very confused. Mchp has revised the table
several times since the 1995 databook - so apparently they are not too
sure themselves. When feeding in 60 mhz to RC0-->prescaler-->Timer1,
you are "apparently" violating what the datasheet says, but it sure
works fine.

- dan michaels
http://www.oricomtech.com
==================

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\23@155503 by Dan Michaels

flavicon
face
Brusque wrote:


>    The maximum frequency this would have to count would be about 20khz.
>The strange fact is that when I suply a 100hz square wave to the circuit,
>the countings turns a lot random.
>

I'll take a closer look at your algorithm tonite, and see what I can see.
===========

>    Could you please suply some code excerpts from your frequency
>counting routines?
>

see other answer for basics.
===========

>> Using (float)casting, I guess round-off errors during division
>> isn't going to be a problem.
>
>    I'm only using it because of the need for a 32 bit counting. Maybe
>I'll try to make some kind of 32 bit integer maths with CCS.
>

No, actually, I meant you are probably better off using float, since
integer math more easily gives round-off errors and overflows, etc.
===========

>> But given your algorithm with all of its inversons/etc, do you
>> have any idea how many Timer1 ticks is the difference between
>> measuring 2480 and 2500?
>
>    That values are in ticks. The input on the PIC was a 1000hz square
>wave. Every cycle takes 1ms. The Timer1 tickles 2500 times in one 1ms
>with 10mhz clock.
>

Hmm, so then 2500-2480 = 20 amounts to 20*.4usec = 8 usec. Something
so short could be due to overhead problems. I look at it more closely
tonite [and hopefully someone else will have fixed it by then :)].

- dan michaels
http://www.oricomtech.com
==================

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\23@155934 by Dan Michaels

flavicon
face
Spehro Pefhany wrote:
>At 03:02 PM 2/23/01 -0500, you wrote:
>>my timer/counter routines, I always use assembler, because
>>>then I know exactly how many clock cycles everything takes,
>>>and still the overhead is sometimes a problem - but then my routines
>>>use timer1 to measure up to 60 Mhz.
>>
>>How do you measure 60MHz with a PIC?
>
>The baseline PICs will probably work up that frequency, at room
>temperature and with a square wave input. The data sheet says 50MHz
>for the PIC16C54C, for example, over the temperature range, as
>a "characterized but not tested" minimum. (Page 126).
>


Actually, this refers to the RTCC input. Timer1 is another matter,
as described in my other msg. However, it also appears to work
to that same frequency range.

- dan michaels
http://www.oricomtech,com
==================

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\23@231712 by Roman Black

flavicon
face
Dan Michaels wrote:
{Quote hidden}

Dan, My 16C84 datasheet (page 27) says re using
external pulse input, internal prescaler to
TIMER0 counter, that the only requirement for
the input signal is that the high and low period
are each greater than 10nS.

So that would be 50MHz. And completely in spec,
if I read it right. It was actually talking about
using the external clock as the osc, so since there
is a lot less timing critical hardware just using
it as a TIMER0 counter, 60MHz should be real safe.
-Roman

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\24@114125 by Dan Michaels

flavicon
face
Brusque wrote:

>
>    When I put a square-wave of 1,000 Hz, it counts 2480 instructions for a
>complete cycle when the correct would be 2500. Also, it tells readings like:
>        2480, 2480, 2425, 2480, 2425
>
.......
> // Counting the time (in instructions) that it takes to detect 32 cycles
> T1CON.TMR1ON = 1;
> for (x=0; x < 32; x++) {
>  while(!PORTC.B7);
>  while(PORTC.B7);
> }
> T1CON.TMR1ON = 0;
>

Hi Edson,

It doesn't look like anyone else has solved the problem. I looked
over the algorithm again, and couldn't see anything obviously wrong.

The only thing that really stands out to me is that the difference
between 2500 and 2480 is 20 instruction cycles, or 4 usec, and this
could possibly the overhead involved in your for() loop above,
related to terminating the loop and turning off the timer. This is
why I code timing routines in assembler - so I know exactly what
the overhead will be.

Another issue relates to how accurate your input signal is. May not
be 1000 hz, but actually 992 hz.

Also, variability between readings - sometimes 2480 and sometimes
2425 - usually indicates something flaky in the initialization or
startup procedures, but I don't see anything obvious.

????????
============

Other comments:

All in all, this algorithm looks nice in terms of being able to
measure very very slow signals - however, clearly the loop overhead
is going to affect accuracy for faster signals.

It alos occurred to me that you have no way to bail out of the
for() loop in the case that signal freq = 0hz [no signal] or signal
disappears during measurement. Adding in bailout code, however, is
going to make the loop overhead that much longer.

- dan michaels
http://www.oricomtech.com
==================

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\02\24@114138 by Dan Michaels

flavicon
face
Roman Black wrote:
.......
>> Also note --> if you look at the Mchp datasheets regarding risetimes/etc
>> for Timer1, you will become very confused. Mchp has revised the table
>> several times since the 1995 databook - so apparently they are not too
>> sure themselves. When feeding in 60 mhz to RC0-->prescaler-->Timer1,
>> you are "apparently" violating what the datasheet says, but it sure
>> works fine.
>>
>> - dan michaels
>
>
>Dan, My 16C84 datasheet (page 27) says re using
>external pulse input, internal prescaler to
>TIMER0 counter, that the only requirement for
>the input signal is that the high and low period
>are each greater than 10nS.
.......
>


Hi Roman, if you look again, you'll see that I was referring to
Timer "1". Timer0 is not an issue - however, the specs for Timer1
are a little confused - and the datasheets have been changed a
couple of times.

The real issue is what rise/fall times the prescalers can handle.

A year or so back, I talked on the phone with an app engineer at
Mchp, and of course he simply looked at the datasheet, and mumbled
something.

However, "my" comment to him was it did not make a lot of sense to me
that the specs should be different between the Timer0 prescaler and
the Timer1 prescaler - and the datasheet indicates about a 6:1
difference, IIRC.

At any rate, I routinely stick 50 Mhz into the Timer "1" input/prescaler
from a TTL oscillator chip/etc, and have not seen any problems. 80 mhz
oscillator input will not fly.

- dan michaels
http://www.oricomtech.com
==================

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\02\26@064150 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Roman Black [SMTP:fastvidspamspam_OUTEZY.NET.AU]
> Sent: Saturday, February 24, 2001 4:17 AM
> To:   @spam@PICLISTKILLspamspamMITVMA.MIT.EDU
> Subject:      Re: [PIC]: Frequency counting
>
>
> Dan, My 16C84 datasheet (page 27) says re using
> external pulse input, internal prescaler to
> TIMER0 counter, that the only requirement for
> the input signal is that the high and low period
> are each greater than 10nS.
>
> So that would be 50MHz. And completely in spec,
> if I read it right. It was actually talking about
> using the external clock as the osc, so since there
> is a lot less timing critical hardware just using
> it as a TIMER0 counter, 60MHz should be real safe.
> -Roman
>
Roman,

If you look at the actual specs for TMR0 on the 16C84 (page 81), when using
the pre-scaler the minimum high time for a pulse into T0CKI is 30ns and the
minimum low time is 20ns.  This give a period of 50ns = 20MHz.  This is why
all the frequency counters based on this part are only good for 20MHz.

Mike

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@095610 by Roman Black

flavicon
face
Michael Rigby-Jones wrote:
{Quote hidden}

OK, so see page 27, 3rd paragraph, re using an external
clocking source into TOCK1 to TIMER0 prescaler, "as long
as it doesn't have less than 10nS high or low times..."

I'm siding with Bob that 50MHz should be ok into
this input... :o)
-Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@110934 by Dan Michaels

flavicon
face
Roman Black wrote:
{Quote hidden}

Roman, Mike,

History repeats itself - I remember this "exact" same discussion from
about 8 or 9 months ago :).

You are both right - in your "statements" at least. However:

1 - the "text" in front of the datasheets regarding Timer0 is the same
   for all the PICs --> Roman's 10ns.

2 - but the info given in the Electrical Characteristics "tables" in the
   back is different in some cases --> 16C/F84s show 30 and 20ns, as
   Mike said.

3 - for other processors - ie, NON-Flash - the number given is 10 ns in
   both text and tables.

I checked this in both the 1995 databook and more recent datasheets.
Obviously, Mchp simply took the same original day-1 datasheet and cloned
it for later processors - they changed the tables in the back to reflect
different processors, but didn't always catch/update all the references
in the text in the front.

My guess is the tables in the back are more correct - so you should
get 50 Mhz out of a non-Flash part, and only 20 mhz out of a flash
part. But who really knows?

You could try asking an Mchp app engineer to come up with a definitive
answer, but ...........

hope this helps [ha],
- dan michaels
http://www.oricomtech.com
==================

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@114036 by Bob Ammerman

picon face
> OK, so see page 27, 3rd paragraph, re using an external
> clocking source into TOCK1 to TIMER0 prescaler, "as long
> as it doesn't have less than 10nS high or low times..."
>
> I'm siding with Bob that 50MHz should be ok into
> this input... :o)
> -Roman

Ah, but only a 'perfect' 50Mhz signal with zero rise and fall times meets
the spec.

Any real world signal will have some rise/fall time and thus be less than
50Mhz.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads



'[PIC]: Frequency counting'
2001\03\01@131328 by Edson Brusque
face
flavicon
face
Hello Dan,

> It doesn't look like anyone else has solved the problem. I looked
> over the algorithm again, and couldn't see anything obviously wrong.

   I'm glad I'm on the right track. :)

> The only thing that really stands out to me is that the difference
> between 2500 and 2480 is 20 instruction cycles, or 4 usec, and this
> could possibly the overhead involved in your for() loop above,
> related to terminating the loop and turning off the timer. This is
> why I code timing routines in assembler - so I know exactly what
> the overhead will be.

   I'll rewrite it in Assembly to see if I catch something.

> Another issue relates to how accurate your input signal is. May not
> be 1000 hz, but actually 992 hz.

   I think it's pretty accurate. I'm using my PC to generate a wave (tried
sine, triangle, saw, square) at the soundcard (a SoundBlaster Live!) output.
The soundcard output enters an LM393 comparator to be squared. The LM393
output goes to the freq-counting-input at the PIC.

> Also, variability between readings - sometimes 2480 and sometimes
> 2425 - usually indicates something flaky in the initialization or
> startup procedures, but I don't see anything obvious.

   Yes, I also suspect this. But as you can see, before the actual
time-counting, I have:

       // Waiting for the end of the actual cycle
       while(!PORTC.B7);
       while(PORTC.B7);

   for syncroing (is this the word? maybe syncronizing? syncing?) the start
of a cycle with the start of the counting-loop. This would have to eliminate
flakies.

> All in all, this algorithm looks nice in terms of being able to
> measure very very slow signals - however, clearly the loop overhead
> is going to affect accuracy for faster signals.

   Yes, I know that. But the maximum overhead I've detected is about 9
instructions for exiting the "while(PORTC.B7);" line, passing by the for
loop and entering the "while(!PORTC.B7);" line.

   9 instructions is 3.2uS. This should limits my countings (in theory) at
about 150kHz. Don't know if my thinkering is correct: 1sec/3.2uS = 312500
half-cycles = 156250kHz.

> It also occurred to me that you have no way to bail out of the
> for() loop in the case that signal freq = 0hz [no signal] or signal
> disappears during measurement. Adding in bailout code, however, is
> going to make the loop overhead that much longer.

   I'm thinking about using the Timer0 to implement the time-out.

   Best regards and thanks for you attention,

   Brusque

-----------------------------------
Edson Brusque
Research and Development
C.I.Tronics Lighting Designers Ltda
(47) 323-2685  /  (47) 9993-6453
Blumenau  -  SC  -  Brazil
http://www.citronics.com.br
-----------------------------------

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2001\03\01@141432 by Dan Michaels

flavicon
face
Brusque wrote:

>
>> Another issue relates to how accurate your input signal is. May not
>> be 1000 hz, but actually 992 hz.
>
>    I think it's pretty accurate. I'm using my PC to generate a wave (tried
>sine, triangle, saw, square) at the soundcard (a SoundBlaster Live!) output.
>The soundcard output enters an LM393 comparator to be squared. The LM393
>output goes to the freq-counting-input at the PIC.
>

Hello Edson,

Your description doesn't make me feel any better about possible
accuracy errors :). A PC + sound card used to generate a tone.

Personally, I would go with a xtal-controlled PIC, and PWM output.
You must have this lying around on the bench already.
================


{Quote hidden}

Yes, I had noticed your syncho code. However, "all" of these loops,
including the for() loop and the while() loops are going to add overhead
and jitter, and this may be enough to add up to 20 counts [ie, instructions].
==============

{Quote hidden}

Yes, but more importantly, I think, is that this overhead may be limiting
the accuracy of your measurements. After you get out of the last while()
loop below, you still have to go back up and clear the last index check
in the for() loop - I would thrink all this could easily add up to
20 instruction cycles.


> T1CON.TMR1ON = 1;
> for (x=0; x < 32; x++) {
>  while(!PORTC.B7);
>  while(PORTC.B7);
> }
> T1CON.TMR1ON = 0;

best regards,
- dan michaels
http://www.oricomtech,com
==================

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\03\02@040319 by Alan B. Pearce

face picon face
> The only thing that really stands out to me is that the difference
> between 2500 and 2480 is 20 instruction cycles, or 4 usec, and this

Do not forget that any count you do is never exact anyway. It is +/- 1 count,
and from the description you give, this 20 instruction variation you get is one
loop through your code which would be correct for +/- 1 count.

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


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