Post by thread:[PIC]: freq counter

I need to make a freq counter with fixed offset additions good for about 134 mhz.... having studied those (three/four) PIC designs for freq. counters already out there, there seem to be two techniques for this, 2 of them follow the microchip notes route of using TMRO and then clocking the lsb out of the prescalar. this...will only give me a 16 bit counter which leaves me with resolution at around 4khz after using an external hardware prescaler and then the internal prescaler of tmro....if I want to go to 24 bit, ie 16 bit tmro count+clocked out prescalar (better resolution) I need to a) write code for 24 bit math, yuk after 20 years out I am only just returning to ASSEMBLER, AND ensure this code looks for and counts 'overflow' of TMRO, AND in a tight timing loop (this is during 'gate open' time)....ie I can see how to do it, but do not fancy it much... daunting....to a 'two byte hacker' like me...:-) I do not want to just use what is out there because I need additional math to add an offset to frequencies read in and want to use an LCD not the multiplexed LEDS found in existing designs.. 1...has anyone done this ? 2...is there another route of using an external dedicated freq counter chip and getting either a 'data' output (doesn't fix the 24 bit math issues, but does fix the tight loop overflow tracking issue ...can't seem to find one of those) OR 'hijacking' it's display output into a PIC so I can do the math I need (in the cosier enviroment of PBP in my own time and use the 'easy' lcd driver routines in there as well) and then display it how I want... 3...if not, I figured there might be some mileage is including a simple(r) tight timed loop 24 bit counter (gating routine) in inserted ASM into a PBP program (picking off the ASM updated variables from within PBP,I can hack the 3 byte math easier from there !!)....anyone done that one or similar ???? Graham -Need *high IP3* AND good N/F ?? try this- http://www.rfham.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

> I need to make a freq counter with fixed offset additions good for about 134 > mhz.... The most accurate way to measure frequency with a PIC is to use a CCP module to determine the period. In your case you need an external divider to get the frequency down to what a PIC can reasonably handle. If you use a 20MHz PIC, then your period resolution will be 200nS. If this is just meant to update a display in human time, then you can easily afford a measurement period of around 100mS. That gives you an accuracy of almost 19 bits, or 2ppm, which probably exceeds the accuracy of your reference oscillator (the PIC instruction clock). > 1...has anyone done this ? Yes, I've done this sort of thing a number of times. One of them was a tachometer application, which is essentially a frequency meter. This was done on a 16C923 using the CCP module as I described above. The '923 also drove an LCD display directly to show the result to the user. The 923/924 are pretty neat devices that don't seem to be that well known. Maybe that's because they have limited clock speed (8MHz) and usually not enough program memory space, and only 8 bit A/Ds. Fortunately the new parts coming out will provide 10 bit A/Ds and more program memory, but Microchip still blew it by not adding a UART. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, spam_OUTolinTakeThisOuTcognivis.com, http://www.cognivis.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

----- Original Message ----- From: Olin Lathrop <.....olin_piclistKILLspam@spam@COGNIVIS.COM> To: <PICLISTKILLspamMITVMA.MIT.EDU> Sent: Tuesday, September 19, 2000 9:40 AM Subject: Re: [PIC]: freq counter > > I need to make a freq counter with fixed offset additions good for about > 134 > > mhz.... > > The most accurate way to measure frequency with a PIC is to use a CCP module > to determine the period. In your case you need an external divider to get > the frequency down to what a PIC can reasonably handle. If you use a 20MHz > PIC, then your period resolution will be 200nS. If this is just meant to > update a display in human time, then you can easily afford a measurement > period of around 100mS. That gives you an accuracy of almost 19 bits, or > 2ppm, which probably exceeds the accuracy of your reference oscillator (the > PIC instruction clock). But then you have to deal with the ugly F = 1/period equation, which is a pain in assembly, and hides a lot of overhead in "C". > > 1...has anyone done this ? > > Yes, I've done this sort of thing a number of times. One of them was a > tachometer application, which is essentially a frequency meter. This was > done on a 16C923 using the CCP module as I described above. The '923 also > drove an LCD display directly to show the result to the user. > > The 923/924 are pretty neat devices that don't seem to be that well known. > Maybe that's because they have limited clock speed (8MHz) and usually not > enough program memory space, and only 8 bit A/Ds. Fortunately the new parts {Quote hidden}> coming out will provide 10 bit A/Ds and more program memory, but Microchip > still blew it by not adding a UART. > > > ***************************************************************** > Olin Lathrop, embedded systems consultant in Devens Massachusetts > (978) 772-3129, .....olinKILLspam.....cognivis.com, http://www.cognivis.com > > -- > http://www.piclist.com hint: PICList Posts must start with ONE topic: > "[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's > > -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

> But then you have to deal with the ugly F = 1/period equation, which is a > pain in assembly, and hides a lot of overhead in "C". How can there be much overhead? It's just one little "/"? ;-) Seriously though, yes you do have to do a divide. That's why I have 32 bit integer and 24 bit floating point math routines. I don't consider calling a divide routine all that "ugly" or much of a pain. It's just what it happens to take to get the job done. The application was described as a frequency meter that displays its results to humans on an LCD, so there is no lack of cycles for doing a 32 bit integer divide. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, EraseMEolinspam_OUTTakeThisOuTcognivis.com, http://www.cognivis.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

I did a 24 bit counter on a '54 a few years ago. It is not so hard. The loop to check for the oveflow of TMR0 is not so tight, as you are looking for MSB rollover in TMR0 (0x7F -> 0x80) and that occurs slowly (1/256 of gate time worst case so you need to poll at least twice as fast - hint hint). I had constant run time code for this to also implement gate timing ('54 has no interrupts). Adding the offset was not a problem, carry propagates as designed when using successive addwfs/subwfs ;-) The problem was converting to ASCII for display. I wrote a routine to convert using successive substraction on 24 bits (then 16, then 8, as the remainder got shorter I jumped back to a 'later' byte's substract). Whenever I had a digit done I added the ASCII ofset '0' and sent it out to the LCD which was in 4-bit mode, 2x16. There was no flicker. I also had leading zero suppression and '\'' ticks between thousands. imho your problem will be to locate a prescaler that is available for that frequency range and does not consume more power than your whole project together. hope this helps, Peter -- 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