Capture Mode Input Frequency Measurement

[temtronic]

1st, go to Microchip's website, find their 'application notes', search for 'frequency counter' or such......You'll also find great info in their 'tips 'n tricks' books, online as well.

2nd you nee to post what range of frequencies you need to capture. Depending on that ,you could setup the clock speed,registers and counters so that a bit = a u-second,so a count of say 41666 is 41.666 miliseconds.

[ilker07]

unsigned int16 passedTime=0;
float f;
int1 show=0;
#INT_CCP3
void func1()
{

counter++;
if(counter==1) set_timer3(0); //start the timer in the first rising edge.
else if(counter==2){
passedTime=get_timer3();//get the value in the second rising edge.
counter=0;
f=(float)4000/(float)passedTime;

}

}
void main() {



setup_timer_3(T3_INTERNAL | T3_DIV_BY_4);



setup_ccp3(ccp_capture_re);
CCP_3_HIGH=0x00;
CCP_3_LOW=0x00;
clear_interrupt(INT_CCP3);
enable_interrupts(INT_CCP3);

enable_interrupts(GLOBAL);

while(True) {

}

}

I added something like this.

[temtronic]

floats are NOT required and can cause 'problems'.....

[ilker07]

[temtronic]

'time' ?
What are you referring to ?
Mr. T's reply was about overclocking a microcontroller.

BTW guessing is NOT a good thing when dealing with any computer.

[ilker07]

[gaugeguy]

Guaranteed correct operation of all peripherals will be less than one clock cycle.
YMMV

[Ttelmah]

The point is the chips are warranted to have failure rates below a specification
at their rated clocks. Go even a little over and this failure rate goes up. At 25%,
I'd actually expect you will find peripherals that don't work correctly from
day 1. Just odd memory cells that don't hold, or things like the ADC being
out of spec, of bytes getting lost from the memory. The failure rate will go
up as temperature increases.

[PrinceNai]

I think overclocking the chip and why not to do it was discussed in great length here. For the reliability of such a setup the answer you'd get from a crystal ball is as good as any. It's unknowable. Failure at once, maybe never.

But for the main part, measuring the frequency. To test the code internal 64MHz oscillator should be more than good enough. I believe that should be the main issue.

[ilker07]

[PrinceNai]

Well, I wouldn't like the brakes on my car being controlled by such a thing :-)

[Ttelmah]

Does depend massively on 'how much'. 5%, pretty much no problems,
especially if you restrict the operating temperature range by perhaps 10%.
10 to 15%, some chips will give problems from day 1, and failure after
weeks and months will be much more frequent.
Above 15%, really you are like the like the people chasing a rolling cheese
down a hill. Many will get away with it, but a very large percentage will end
up with sprains or breakages.
Understand that manufacturers want to tell you their chip is as fast as they
possibly can. If they could run a chip 15% faster and still meet their specified
operating temperature range and reliability, they would re-mark it as a 'B'
version, and launch a new dats sheet with this having the faster clock speed.
This happened years ago, with quite a few mciroprocessors as manufacturing
processes improved, and does still happen at times.

[PrinceNai]

There is also a debugging aspect. I like to be 100% confident my hardware works. So when I chase down the issues I can be sure it is because of something I wrote or didn't read the datasheet as I should have. Or my lack of programming skils. But NOT the hardware malfunctioning on me.

[Ttelmah]

and that (of course) is one of the most important things. The failures on
a chip when overclocked, can in particular be very insidious small things
that are very hard indeed to diagnose. There was an issue a posted
here a few years ago, where the UART was intermittently missing
characters. It was only after a long thread that the fact he was overclocking
came out. Went down to the legal speed, and the problem disappeared.
There have been several others (memory errors, I2C problems, and an
ADC problem that I remember).