CCP1 question

[oxxyfx]

Hello,

I am working on a project where I have to accurately measure the width of an incoming pulse. I chose the PIC12F1840 for this project, it seems quite a versatile little PIC.

My compiler version is 4.135.

I have connected the incoming signal to PIN A2 and I enabled the interrupt for the RE.

[Ttelmah]

You can just change the programming of CCP1, to be on the falling edge at the start of the interrupt. So the sequence becomes:
1) Read the CCP, into ccp_val[flag].
2) Test flag - if set, this is the second edge, goto 4
3) Change the interrupt edge, and set the flag - exit
4) Now the time is ccp_val[1]-ccp_val[0]. If this is -ve add 65536.
5) clear flag, and exit.

Big advantage is you won't be stuck waiting in the interrupt. If (for instance), the signal does not drop, you would be stuck forever waiting in

While(Input(Signal)){};

Code for doing this with a single CCP has been posted here in the past. A search should find it.
It'll be slightly more accurate (the latency of the while loop).

Best Wishes

[oxxyfx]

Thank you,

so this is the code I came up with based on your reply:

[Ttelmah]

Yes, you can change the capture mode at any time.
Only problem you will have, is if the timer has overflowed between reading the rising edge, and the falling edge. Then fall will be less than rise, and you need to wrap the arithmetic.

Best Wishes

[oxxyfx]

Thank you.

So my Timer 1 is defined as:

[Ttelmah]

Not true.
Remember the timer is running all the time, and is independant of your pulse. It could wrap on the very next clock cycle after the rising edge is detected, or at any time between the two edges.

Best Wishes

[asmboy]

[oxxyfx]

Thank you,

so what is the value the timer 1 overflows at? The compiler says it will overflow every 13.1ms, which would be 13100 micro s.

S if I out an IF statement there to check the value of the "rise" compared to the value of "fall", and if the "fall" is smaller than it is obvious it was an overflow.

In that case I could compute the exact value of the pulse by knowing where was the overflow value.

So is it overflowing at 13100?

[asmboy]

[oxxyfx]

Thank you, no offense but that sounds like chinese to me

So that all said the clock overflows at 65535.

I do not have a preset timer, I am assuming that would mean:

set_timer1(0xfffe)

but I do not have that. Since I am using a 4Mhz internal clock with a div_1 as you previously mentioned and a delay clock of 4Mhz as well, what is the highest decimal value the

fall = CCP1

can have? Is it 65535 or 13100?

[asmboy]

One clock to overflow will not work in reality

The code overhead of setting 0xfffe will allow an overflow after the NEXT 2 instructions in your program. ie 2 normal instructions later....

You have to get a GRIP on the time domain implications of what you are trying to do and THINK harder.

So what resolution do you need?

What absolute accuracy?

How much delta / jitter can you accept in the data points you get ?

Surely you can see that higher clock rates can provide better resolution,
and as i said the 4 mhz INTRC clock is pretty coarse in the time increment department too-
and
orders of magnitude less absolutely accurate than a crystal source - as well as more jittery over time and temp.

Accurate and INTRC don't go in the same sentence - really.......

[oxxyfx]

I am happy with the resolution the 4Mhz provides.

So what is the maximum value I am looking for?

[asmboy]

the BEST THEORETICAL resolution you can hope for - using a crystal oscillator at 4 mhz HAS TO BE much greater than 1 usec ,
tho in practice this may be impossible to achieve -
i would suggest that 1 usec is therefore your probable jitter spec.

with INTRC , absolute jitter is sure to be worse than that

as to the HOW of it:

everything i know about it -
i first learned from section 11.3 of the 16f887 data sheet .

my understanding of it was cemented by building and testing circuits.

"11.3" is an excellent guide to the task you are undertaking .
do check it out.

from a PRACTICAL standpoint
due to interrupt latency , and the likely count of the instrux U will need to handle the capture - and with a div_1 for timer1 ::

i'd say the MIN pulse you can catch is somewhere > 100usec and obviously r <65536 usec, right ?

[oxxyfx]

My pulses are between 1ms and 2ms. It is a standard RC receiver output.

The minimum pulse is not an issue, the incoming pulse never goes under 7-800us and the maximum never goes above 22-2300us.

However the pulses repeat themselves every 20-22.5ms and I am capturing every single one of them. These go into a rolling buffer and get averaged for the output. I am just trying to minimize the error pulses, so I have two options. When there is a buffer overflow I can throw out that pulse and ignore it - or I can calculate the correct length with the following formula:

[Ttelmah]

Your accuracy will go _down_ if you set the clock in the interrupt.
Problem is that it takes significant _time_ to get into the interrupt handler.
The whole 'point' about the CCP, is that it (without you having to do anything), records the timer reading when an edge occurs. This is then available for you to read at any point till it updates again. When you arrive in the handler, it is probably already about 30 clocks _after_ the recording was made.
The approach you already have, should be fine, and as good as your are going to get from the hardware, with 1000 possible values between 1mSec, and 2mSec.

That you are getting chatter at all in the signal, suggests you are using a fairly 'basic' RC. Most modern digital sets, will hold the output pulse accurate to tiny fractions, if the input source is stable, and will maintain that accuracy, even if the transmission is interrupted (usually switching to an 'emergency' output setting if the break is longer than a few seconds).

However, if you have chatter, something like an Olympic average, may be far better suited to this application, than a simple sum and divide average.

Best Wishes