| View previous topic :: View next topic |
| Author |
Message |
Ttelmah
Joined: 11 Mar 2010
Posts: 19795
|
|
 Posted: Tue Aug 28, 2012 7:02 am |
 |
|
pulse_width = 65535-rise+fall;
Correct value is 65536, not 65535.
The counter counts from 0 to 65535, then back to 0. 65536 counts from 0 to 0.
Best Wishes |
|
 |
oxxyfx
Joined: 24 May 2007
Posts: 97
|
|
| Posted: Tue Aug 28, 2012 7:57 am |
|
|
Thank you.
For the reason of minimizing the hardware, keeping the designed circuit board as small as possible as well as minimizing the costs, I do not want to add an external oscillator or crystal. I will have to make this as good as it gets with the internal oscillator.
So based on all the previous posts - not to use timer interrupt, try to keep it as short and clear as possible here is the ccp1 interrupt rutine:
| Code: |
#int_CCP1
void CCP1_isr(void)
{
If (!ccpflag){
rise = CCP_1;
ccpflag = 1;
setup_ccp1(CCP_CAPTURE_FE);
}
Else {
fall = CCP_1;
If (rise < fall) pulse_width = fall - rise;
Else {
pulse_width = 65536-rise+fall;
}
iflag = 1;
ccpflag = 0;
setup_ccp1(CCP_CAPTURE_RE);
}
}
|
this way if an overflow is detected it will calculate the correct value of the pulse with the "Else" condition and while no overflow is detected it will use the "if" portion of the statement. I think this is as good as it can get with the existing hardware. |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Tue Aug 28, 2012 1:10 pm |
|
|
you are SO NOT GETTING the point of what you are being told:
let me quote:
| Quote: |
In Capture mode, the CCPRxH, CCPRxL register pair
captures the 16-bit value of the TMR1 register when an
event occurs on pin CCPx. An event is defined as one
of the following and is configured by the CCP1M<3:0>
bits of the CCP1CON register:
• Every falling edge <--
• Every rising edge
|
nearly everything you need to understand about doing this is in the quote above and HINT: it has nothing to do with reading timer1 inside an ISR , either !!!
if done right - with the timer overflow margin YOU Have - will work fine - no wrap worries and NOT be influenced by INT latency either .....
as 65535 usecs of range is FAR longer than you require for RC servo pulse width measurement. you can imagine the improvement in resolution that an 8 or 16 mhz clock could offer and still have 32 or 16 seconds of total range.
think hard about that quote - versus what you coded |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
