Calculating wrong RPM.....

prayami · Joined: 22 Dec 2004 Posts: 78

Hi...

I am using 18F452 and CCS PCH C Compiler, Version 3.249 . Crystal
oscillator is 10Mhz.

Thus frequency = 10MHzX4 = 40MHz.

Here I am running a simple program which is sometime calculating
the wrong RPM.

If I continuos change the input frequency on pin CCP1 from 1600rpm
to 1900 rpm (i.e. frequency from 107Hz to 124Hz) then once approximately within 3 minutes it is calculating rpm over 2000rpm. And turns PIN_D4 on.

My frequency generator is good and circuit is simple, nothing xtra stuff
connected, just processor and oscillator circuitry...

As I have calculated TimerCycle for above frequency range then it should not match following condition within 3minutes but is happening.....Don't know how it can be possible.....

asmallri · Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia

You are incrementing 16 bit variables inside your interrupt handler. Outside the handler you are testing and changing there variables without disabling interrupts during the process. Each line of C can translate into many instructions. It is possible and not uncommon for an interrupt to occur inside the mainline test conditions in which case the most significant byte and the least signficant byte may be unrelated. For example lets say the value of a 16 bit variable was 0x01ff at the start of the test in mainline. The first part of the test sees 0x01 as the most significant byte. Now an interrupt occurs and the value is incremented by the handler (the new value seen by the handler is 0x0200). The handler returns to the mainline test code which now tests the least significant byte and sees that the value is 0x00. So the mainline interprets the value as 0x0100 whereas the interrupt handler sees the value as 0x0200.

You get the idea.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

prayami · Joined: 22 Dec 2004 Posts: 78

Thanks for reply asmallri....

I tried as you suggested and thus modified my original post with that
change you have suggested....But I have handled the disable_interrupt that you suggested in different way...

But it is still counting Timer Cycle less than frequency 124Hz....that is
calculating more than 124Hz once every 2 to 3 minutes....

Can it be bug some where..??!!!

I have also modified my original post with more details......

Thanks in advanced........plz......

asmallri · Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia

You need to disable interrupts in the main line..

prayami · Joined: 22 Dec 2004 Posts: 78

Thanks....

I tried as per you suggested...but same thing....I minimized the code
as under but it is definately calculating wrong TimerCycle.

I am applying varing frequency between 107Hz to 125Hz

I don't know what are the possibilities for that....

I tried to change new processor but same.....

But it is calculating

asmallri · Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia

prayami · Joined: 22 Dec 2004 Posts: 78

Hi...

I have written delay_ms(5000); on the beginning of the main loop.
And it is not doing at very beginning. It is doing every 2 to 3 minutes.

This if loop is to check whether it is going >127Hz or not....

My frequency generator is good and input signal is also ok.....

It is really hard for me to figure out...what are the possible problem...

Thanks....

Ttelmah · Guest

A number of minor comments.
First, clear the interrupts before enabling them. Otherwise it is quite likely that before the timer is setup, it can run at full frequency, and an interrupt may already have occured. Shouldn't give your random behaviour but is worth doing.
Second, why are you reading the timer in the INT_CCP?. The whole point of the CCP capture mode, is that _it_ captures the count at the moment the hardware event occurs. This count will be available in the CCP registers inside the interrupt. By reading the timer, the extra time needed to enter the interrupt will be incurred, and also if there was a delay (because perhaps you were inside int_timer1), there will be an errpneous reading.
The big one though is the third.
What happens if the timer wraps after the CCP event triggers, but before it reaches the CCP routine?. What happens if the timer event triggers, but the CCP event triggers before the timer routine is reached?. The answer is that in both cases it will go to the CCP handler routine, and arrive without the timer overflow having been incremented, resulting in a massively wrong reading (out by 65536 counts). There are a number of possible solutions. The first is to add a test in the CCP routine, and in the next instruction, test if the Timer1 interrupt flag is set. If it is, carry out an extra increment to the carry bit. The second is to get rid of the timer1 overflow handling completely. Just set the CCP, to capture the counter on each edge. Then in the CCP interrupt, record the value stored in the CCP registers. In the main, calculate this minus the last count, and while this result is less than 80000, keep adding 65536. Since your results should always be in the range 80000 to 93457, this will generate the right result.
Finally, don't fiddle around converting a value to a float, dividing by four, and then converting back, this takes a huge amount of time, and gives _less_ accurate results than working in 32bit integer. A 'float', only has 24 bit basic accuracy, and since you are working with an integer +ve value, you gain nothing by this.

Best Wishes

prayami · Joined: 22 Dec 2004 Posts: 78

Thanks...Ttelmah....you are greate....

I have tried the one you have suggested. And that seems working. The only thing is if I use CCP_1 for reading timer as under then it is doing what it was. But with "temptimer1 = get_timer1();" it is fine.

Is there any thing else left for using CCP_1 ?