Post by thread:[PIC]: Frequency counting

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-requestTakeThisOuTmitvma.mit.edu

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

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.

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.

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.

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" speffKILLspaminterlog.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.

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.

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.

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.

Dan Michaels wrote: {Quote hidden}> > 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 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.

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 .....listservKILLspam.....mitvma.mit.edu with SET PICList DIGEST in the body

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_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

> -----Original Message----- > From: Roman Black [SMTP:fastvidspam_OUTEZY.NET.AU] > Sent: Saturday, February 24, 2001 4:17 AM > To: @spam@PICLISTKILLspamMITVMA.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

Michael Rigby-Jones wrote: {Quote hidden}> > > -----Original Message----- > > From: Roman Black [SMTP:KILLspamfastvidKILLspamEZY.NET.AU] > > Sent: Saturday, February 24, 2001 4:17 AM > > To: RemoveMEPICLISTTakeThisOuTMITVMA.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 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

Roman Black wrote: {Quote hidden}>Michael Rigby-Jones wrote: >> > 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. >> > >> 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 > > >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 > 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

> 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

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 spamBeGonelistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

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}>> 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. 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}> >> 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. > 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 TakeThisOuTlistservEraseMEspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body