I second that! Have a timer that continuesly counts incoming pulses. Have a second timer with *automatic reload* that generates periodic interrupt, to read the first counter and process the result. Note 1: I'd suggest you *store* the result in the isr and use the main routine to do the actual processing. Note2: the automatic reload gives you an interval based on the xtal frequency and timer setting only. Other timer require compensation for the isr code length / order until reload.
Joep 2013/7/31 Oliver Seitz <[email protected]> > My way would be: > > On overflow, increment an additional upper counter, and just leave the > timer running until the time has passed. You can use variables as big as > you want in JAL. So there's no need for prescalers, as long as the timer > can keep up with the external frequency. > > On 18F26K22 chips, for example, in asyncronous mode, the timers can count > 16MHz. Counting one second, the timer could overflow (16000000/65536=) 244 > times, so only an additional one-byte variable is needed to count that > frequency with 1Hz resolution. > > To count hundreds of MHz, you need to start with a high setting on the > external prescaler, for you can't know if the frequency is too high for the > timer and it might miss pulses then. > > A microcontroller can easily do thousands of interrupts per second without > "going crazy", don't worry. I've had programs where interrupts occured only > a few microseconds after another. This was on 64MHz, though. > > Greets, > Kiste > > ------------------------------ > *Von:* Ing. Pavel Milanes Costa <[email protected]> > *An:* [email protected] > *Gesendet:* 14:46 Mittwoch, 31.Juli 2013 > *Betreff:* Re: [jallib] Freq Counter? + break a _usec_delay() instruction? > > Hi to all... > > Last night I was thinking on the bed before sleep... I think there is > another more elegant KISS solution... > > On overflow, STOP the counting (unset TMR1ON), and then stop the > counting and the overflow process... > > As simple as that... > > I will try it in the afternoon, I will update to all about the progress > of this instrument... > > Cheers... > > > El 30/07/13 23:44, Ing. Pavel Milanes Costa escribió: > > Hi all again. > > > > With your ideas and code I'm writing a frequency meter. > > > > From 0hz to 280 Mhz using various "prescalers" in conjunction (variable > > time of sampling + internal prescaler of TM1 + external prescalers) > > > > The most interesting features is that it "will have" an "auto scale" > > feature, for make readings with the more exact method for the freq being > > measured (aka. minimizing the error for that freq) > > > > But... (as always) I have a problem... > > > > I need to BREAK the counting of a running _usec_delay() instruction from > > a interrupt routine... > > > > I explain (code attached): > > > > I start counting TMR1 pulses on RB6 for 1 sec time lapse, and with > > interrupts on the overflow of it I detect the need of jump on the "range > > / scale", then I change any of the sampling period, internal prescaler > > and/or external prescaler to suit the next scale and then you have a > > autorange freq. meter... > > > > The problem is found when I measure a freq that is much BIGGER for the > > initial sampling period of 1s... > > > > Think on it and dive in the code.... > > > > 7110khz (7110000 pulses in ONE second) is around 108 interrupts in ONE > > second... so the autorange function goes crazy and get to the top of > > scale from overloaded interrupts per seconds... > > > > The obvious solution is breaking the _usec_delay() instruction from the > > interrupt routine... that will require asm which I do not know... or > > another dirty trick... > > > > But, Hey!... I realize NOW that using another timer for setting the > > sampling period can be the solution... (GGGGGRRRRR somebody suggest this > > before and I have not listen to it...) > > > > Yes, forcing the timer of the sampling period to timeout an thereof > > ending the sampling period will be the way... > > > > I will try that tomorrow, nevertheless, the code is attached, comments, > > suggestions, etc, will be welcomed... > > > > I have the proteus project if anyone like to try it... > > > > Just ignore the lcd for now and attach a serial console at 38_400 bauds > > to the PIC and see the debug info... > > > > The code is a work in progress, no optimization or cleaning yet... > > > > Cheers... and enjoy it > > > > PS: Forgive my english if you found an error or two, I'm a spanish > > speaking person... > > > > El 27/07/13 22:41, Ing. Pavel Milanes Costa escribió: > >> Hi all. > >> > >> I'm here reading and searching but I can't find a way of counting > >> asynchronous TTL pulses with jal/jallib over a given time slot... > >> > >> It must be done with the timer module of the pic... (I think...) > >> > >> I explain: > >> > >> I want to make a frequency counter for zero to 250 Mhz, with 2 external > >> prescaler, using direct counting for low freq's, med prescaler to about > >> 50 Mhz and a dedicated prescaler for above 50 Mhz - 250 Mhz+ > >> > >> But I have not a clue how to use the timer1 as an asynconous 16 bit > >> pulse counter of the PIC16F88 I have for the project. > >> > >> Output will be to a cheap 4bit LCD or UART serial to a PC, click will be > >> HS 20 Mhz XTAL... > >> > >> Other candidate is a PIC16F628 in my junkbox. > >> > >> Math is not a problem when I can say something like: > >> > >> <pseudo-code> > >> a = count(pin_b1,100) -- count pulses on pin B1 for 100ms > >> </pseudo-code> > >> > >> Any clue, sample code or tip is welcomed. > >> > >> 73 de CO7WT, Pavel in Cuba Island. > >> > > > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/jallib. > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/jallib. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "jallib" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/jallib. For more options, visit https://groups.google.com/groups/opt_out.
