Hi Oliver, thx! I meant coding in pure assembler cod when talking about counting 50MHz. Of course I don't want in this way... Se here: http://www.qsl.net/dl4yhf/freq_counter/freq_counter.html
On the other hand the timing must be generated inside the pic, INTOSC has enough accuracy for my application. thanks again guys! Vasile On Thu, Jul 7, 2016 at 10:59 AM, 'Oliver Seitz' via jallib < [email protected]> wrote: > Hi Vasile! > > T1G stands for "Timer One Gate", and it can be used to measure low > frequencies within one cycle of the frequency to measure. It is no good for > counting high frequencies. You need to use T1CKI pin for that purpose. That > pin can count 16MHz on the 12F1572 or 32MHz if you use the prescaler. These > values are independent from the core frequency and result from the AC > caracteristics (in my datasheet "TABLE 26-12: TIMER0 AND TIMER1 EXTERNAL > CLOCK REQUIREMENTS"). The reference clock can be generated internally by > TMR0 if the accuracy of the internal oscillator is enough. You can even set > up TMR0 to control T1G to start and stop counting on TMR1, so your main > program would only set things up and wait for TMR0 to overflow twice. Then > TMR1 will have counted for a certain time solely determined by independent > peripherals without any influence of the processor core. > > This chip can in no way count 50MHz without external prescaler. > > Greets, > Kiste > -------------------------------------------- > Vasile Surducan <[email protected]> schrieb am Do, 7.7.2016: > > Betreff: Re: [jallib] Freq Counter? [SOLVED+CODE] > An: [email protected] > Datum: Donnerstag, 7. Juli, 2016 09:33 Uhr > > Hi Matt, > > Your code looks great, > however I need to generate the time base inside the PIC. > I will start testing after I'll > finish the PCBs... > In assembler it > could be done up to 50MHz on any PIC running at 4MHz. > The problem is I want to write it with > the compiler...:) so perhaps with INTOSC at 32MHz (looks it > should work) I will be able to measure up to 3MHz. > > thanks for the > sample! > > On Thu, Jul 7, 2016 at 4:03 > AM, Matt Schinkel <[email protected]> > wrote: > From the looks of > it T1G is just a trigger for the > counter/timer. This is similar to what my sample > does. > Not sure > if you can run a 2nd timer instead of using an external 1hz > signal. I just figured a 1hz signal would make my sample > fairly accurate. > The > other sample of mine uses the osc in pin as the signal > input. It can measure a frequency equivalent to the max pic > osc frequency. So on 18f67j50, i could measure up to 64mhz. > This one would require the 1hz input for sure. > Matt. > On Jul 6, > 2016, at 12:27 PM, vasile <[email protected]> > wrote: > > Hi Pavel,So, in the > final version of your code, still need > compensation? > I need > to measure a frequency up to 3MHz. I'm using a new > generation PIC with T1G (PIC12F1572).I found some > Microchip application note for measuring pulse duration but > not for frequency measurement using T1G input.I > saw also Matt frequency counter at github, but that one need > an external 1Hz reference signal. > Anyone tried the newer PICs for > frequency measuremets? > thank you all,Vasile > > On Thursday, August 8, 2013 at > 5:02:39 AM UTC+3, Ing. Pavel Milanes Costa wrote:Hi all... as I promised > this is the > code... > > > > This is a home project so code is GPL... > see comments... > > > > The hardware can and must be adjusted by > serial port, see comments on > > the header of the file... > > > > This code "as is" can count up to > 5Mhz (in a proteus/isis simulation can > > reach to about 12 Mhz, but 5Mhz as clock/4 > is the max safe value...) > > > > on +5v RB3 the internal code will *8 the > input freq > > on +5v RB4 the internal code will *64 the > input freq > > both RB3 and RB4 at +5v will *8*64 the > input freq > > > > This ARE NOT push buttons, this is TTL > levels > > > > This is as you may guessed by now for > prescaling purposes > > > > Feel free to make any > comments/suggestions/critics/etc... > > > > On the next weeks I will build it for real > (no more proteus/isis > > simulations) and will comment the results > to the list. > > > > This is my first complex code that will be > burned to a "production" pic, > > so I'm very excited about it. > > > > Cheers to all and thanks to all who give me > ideas and tips about this... > > > > Again: sorry any misspelling/typo/grammar > etc... I'm a native Spanish > > speaking person, I'm trying to do my > best at English... > > > > El 03/08/13 11:05, Ing. Pavel Milanes Costa > escribi�: > > > Hey!!! ... this way works 130% (thanks > Oliver Seitz) > > > > > > I explain: > > > > > > I use a PIC16F88, I set the isr > routine for 1ms interrupt and counting > > > for 500ms, this is TMR0... > > > > > > TMR1 is in pulse counter with > prescaler 1:1, on overflow the interrupt > > > of TM1 increment a internal counter as > a way of internal postcaler > > > > > > Each 500ms the TMR1 and his internal > postcaler is read & cleared. > > > > > > Then the freq is computed, with a > trick... > > > > > > The pic is running XTAL at 20Mhz, so > XTAL/4 is 5 Mhz (maximum freq to > > > measure), that is 5000000 pulses per > seconds or 2500000 each 1/2 sec. or > > > 38 * postcaler + remaining pulses... > so postcaler is a byte var... > > > > > > But the ISR of TMR0 & TMR1 puts a > delay on the reading that depends on > > > the things the pic is doing in each > cycle of the forever loop. > > > > > > I adjust the delay as a percent of > useful time on each postcaler cycle, > > > feeding the pic with almost full count > before postcaler get incremented > > > and get by serial port the internal > count, as I knows the freq I can say > > > how much pulses has to count for exact > and how much pulses are the pic > > > counting... > > > > > > For my experimentation the percent of > adjust if in the order of 99% > > > (99.0298891% of the pic reading in my > last calibration) and of course > > > this correction factor must be scaled > to every postcaler count, normally > > > a postcaler count will be poscaller * > 65536, but to adjust I compute > > > 65536 * 99.0298891% so. > > > > > > Freq = poscaler * (65536 * > 99.0298891%) > > > Freq = Freq + (pulses * 99.0298891%) > > > > > > As we want an accurate reading, we > have to work wit decimal shifting the > > > decimal point and div then, so > > > > > > Corr_postcaler_pulses = (65536 * > 99029) /100000 -- this is a constant > > > Corr_pulses = (pulses * 9903) / 10000 > > > Freq = (postcaler * > Corr_postcaler_pulses) + Corr_pulses > > > > > > And as I'm reading 1/2 sec > > > > > > Freq = Freq * 2 > > > > > > This give me an accuracy of about +/- > 10 Hz at 5Mhz (4.99M) in the > > > proteus simulation, I know that the > stability of the 20Mhz XTAL and the > > > source under measure will mask this > error, but nevertheless this is GOOD > > > accuracy.. > > > > > > This is the best method I have tried > and the freq_meter is in his 4.0 > > > version (aka 4th method) > > > > > > Then with a external prescaler of 8 > (5Mhz * 8) I can count up to 40 > > > Mhz... the external prescaler can be a > pair of 74hc74 (3 half in 3 bit > > > count = /8 this can work up to 60-80 > Mhz range) > > > > > > Here I can find a 250 Mhz /64 & > /65 prescalers as well as 1Ghz /2 & /4 & > > > /8 external prescaler, > > > > > > So, I can make it with 5 scales > > > > > > 1Ghz (/8 + /64 = out max 1.9Mhz, > error max ~10Khz) > > > 250Mhz (/64 = out max 3.9Mhz, > error max ~1.2Khz) > > > 40Mhz (/8 = out max 5.0Mhz, error > max ~150hz) > > > 5Mhz (direct, error max ~20hz) > > > 500Khz (direct, error max ~2hz) > > > > > > The core counting engine is working, > I'm working on the lcd output > > > formatting, external prescaling & > serial interface to externally adjust > > > for freq compensation via serial on > the final hardware. > > > > > > I'm thinking also in a > abbreviated/full display option kind of > > > > > > 145.170051 Mhz => 145.170 Mhz > > > 51.110402 Mhz => 51.1104 Mhz > > > > > > For "masking" the error when > full accuracy is not needed > > > > > > And even a averaging of the last n > readings for stable display numbers > > > and accurate readings on > 100 Mhz > freqs when the error gets bigger > > > > > > When I have a working piece of this > functions I will post the example to > > > the list. > > > > > > Thanks to all for the ideas and > tips... > > > > > > Cheers. > > > > > > El 31/07/13 09:50, Oliver Seitz > escribi�: > > >> 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]. > > >> <mailto:[email protected].> > > >> To post to this group, send > email to [email protected]. > > >> <mailto:[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 https://groups.google.com/group/jallib. > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > 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 https://groups.google.com/group/jallib. > > For more options, visit https://groups.google.com/d/optout. > > > > > > > -- > > 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 https://groups.google.com/group/jallib. > > For more options, visit https://groups.google.com/d/optout. > > -- > 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 https://groups.google.com/group/jallib. > For more options, visit https://groups.google.com/d/optout. > -- 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 https://groups.google.com/group/jallib. For more options, visit https://groups.google.com/d/optout.
