Solved. Reading CCP1 value on PIC18F46Q84

[samiceng]

Hi everybody

CCS ver 5.112 & PIC18F46Q84
I am trying to measure frequency up to 100Hz (in 1Hz resolution).
I did that in the past (2021) on a PIC16F914.
But when I try the same way on PIC18F46Q84. It didn’t work.
In my code, I got the reading of ‘wave_width_MSD’ right. But the value of ‘wave_width_LSD’ is always zero.
I am feeding a 31Hz signal, so by math the ‘wave_width’ will be:
64000000/(4*Timer3_Pre*Freq) = 64000000/(4*1*31) = 516129 DEC
Which is ‘0111 110 0000 0010 0001’ Bin. The most right 4 bits (0111) is what will be in ‘wave_width_MSD’, and I got that.
But the remaining 16 bit (should be in ‘wave_width_LSD’ coming from CCP1) always reads zero.
The line that load ‘CCP_hi_byte’ into ‘wave_width_MSD’ is inside the CCP1 interrupt.
And it is working, which mean the CCP1 is working.
But the line that read CCP1 is not. Why?
wave_width_LSD = get_capture(1); is not working.

[Ttelmah]

OK.
I would just use CCP_1 to read the CCP value. However a quick build shows
that the get_capture is accessing the correct register. Just tested with your
compiler version. Register 340/341, which is the CCPR1 values.
So, that you are getting the interrupt, says it is capturing, and that this has
the correct overflow value from the timer, says the timer is running
correctly. You are not selecting to use the CCP pin, but this is the default
(CCP_CAPTURE_INPUT_CCP_PIN).
So all looks good. The timer is not getting stored into the CCP register.

One thing glares in the data sheet:

[samiceng]

Again thank you Ttelmah. Adding T3_SYNC to the timer3 setup line solved it.

I see what you mean by using CCP_1, that worked too.

But i am confused! you said that I did not select to use the CCP pin.
I have this line in may code: #pin_select CCP1=PIN_C0;
Then at the end, you said that I have correctly setup PPS.
Isn't that line doing it?

One more thing, after I posted this, I was playing around it and find a work around. I make it work by reading Timer3 value using wave_width_LSD = get_timer3();

I know it is not the right way to do it. but in may case here, both way gives exactly the same result.

[Ttelmah]

Brilliant.

You see that I say to use the pin is the default.
The point is that on the later chip the CCP can be clocked from a lot of
sources. So:

setup_ccp1(CCP_CAPTURE_RE | CCP_USE_TIMER3_AND_TIMER4 | CCP_CAPTURE_INPUT_CCP_PIN);

is technically the setup to use the pin defined as the CCP input. (With PPS
set as you show).

The point is though that this selection is '0', so makes no difference.
However it is worth perhaps specifying it, so that someone looking in
the future can say 'Ah, CCP input pin used'.
On the older chip the CCP could only be fed from the pin. On this one, it
can be fed from things like the CLC signals, and the IOC interrupt instead.


On the work around. They won't give _quite_ the same result. The CCP
captures the timer count at the moment the event happens. Your read
of the timer inside the interrupt will have the time it takes to get into the
interrupt included in the count. So perhaps 30 extra counts.

[samiceng]

If you notice. I am using the internal clock. which is not so accurate.
Also the feed signal is generated using a PIC16F819 and that too was using its internal clock. (just for testing).
In both ways, read CCP or timer. I was getting flickering reading.
That's why I said both are same.

[Ttelmah]

The 'flickering' is almost certainly because of how the code is done, not the
clocks. Though the internal clocks are not 'accurate', over the short term,
they are quite stable. A maximum of just a count or two should be all you
see.
However there are issues with the code approach:

Forst thing, this will be generating a reading every time a new edge comes
in. So 31* a second. Now the OLED takes time to wirite and display. Probably
better to disable the interrupt when a reading is taken, then when you are
ready to take a new reading, clear the timer, clear the interrupt, and
enable it again.
This way you get a single reading, and have time to display it without
it changing. I suspect you may find that in fact sometimes the interrupt
is being called during the display, so you get an erroneous reading and
more flicker than is really needed. You will always get a count of jitter, since
the clock that is sampling is not synchronous to the external signal, but
any more than one or two counts is a sign that there is an issue. The reading
will vary with temperature, and over time, but short term should be pretty
much perfect. If you stuck the clock from the 819, into a DFM, it might
we'll be 31.27Hz, bit expect the reading from the DFM, to still be saying
31.27, in a couple of minutes, It won't jump around much at all. The clock
on the Q84 will have similar behaviour.

[samiceng]

I thought to do that, but what will grantee that enabling the interrupt will be at the start of the input signal. have a look at this funky timing diagram:

____|````|____|````|____|````|____ input signal

------|------T-----| -> correct count value 'T'
----------|
----------| here was enabling the interrupt
----------|
----------|---t----| -> this will be the count value 't'

in that case I have to sync enabling the interrupt with the input signal too.

it is a slow signal and there will be other stuff the PIC will do. I only used the OLED as test way to see the result.