Osmeoisis 2022-09-06 15-33-19PIC - Enh - C - 14

© Gooligum Electronics 2015 www.gooligum.com.
au
Introduction to PIC Programming

Programming Enhanced Mid-Range PICs in C
by David Meiklejohn, Gooligum Electronics
Lesson 14: CCP, part 1 - Capture and Compare
We’ve seen in previous lessons that timers are very useful for timing and scheduling events. For example, in
lesson 4, we used Timer0 to measure the time between an LED being lit and a button press. In lesson 12, we
used Timer1 gating facility to measure the pulse width of a signal. In lesson 11, we used a Timer0 interrupt
to initiate periodic analog-to-digital conversions. And we’ve used the timers to flash LEDs many times...
This lesson introduces the Capture/Compare/PWM (CCP) and Enhanced CCP (ECCP) modules, beginning
with their capture and compare modes, which work with Timer1 to make it easy (in capture mode) to
accurately time external signals or (in compare mode) to automatically schedule an event, such as toggling a
pin or initiating an analog-to-digital conversion.
We’ll look at the pulse-width modulation (PWM) mode in the next lesson.
In summary, this lesson covers:
 Introduction to the CCP module and its capture and compare modes
 Using capture mode to measure signal period and pulse width
 Using compare mode to trigger accurately-timed external events (pin changes)
 Using compare mode to initiate regular analog-to-digital conversions
with examples implemented using XC8 (running in “Free mode”).
PIC16F1824 (E)CCP Modules

The PIC16F1824 includes two CCP modules and two ECCP modules.
The “enhanced” functionality in the ECCP modules relates only to their PWM modes; the capture and
compare functions are identical in all four modules (ECCP1, ECCP2, CCP3 and CCP4), which we will refer
to generically as “CCP” modules in this lesson.
Each CCP module is controlled by a CCPxCON register (where ‘x’ is ‘1’, ‘2’, ‘3’ or ‘4’):
Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
CCPxCON PxM<1:0> DCxB<1:0> CCPxM<3:0>
Bits 4 to 7 are only used in PWM mode, and will be described in the next lesson.
The CCPxM<3:0> bits select the operating mode.
Clearing these mode select bits turns off and resets the CCP module.
Enhanced Mid-Range PIC C, Lesson 14: CCP, part 1 – Capture and Compare Page 1
© Gooligum Electronics 2015 www.gooligum.com.au
We’ll look at the bit settings relevant to the capture and compare modes, below.
Capture Mode
Capture mode allows us to measure the duration of an external signal on one of the CCPx pins1.
A capture event is a defined change, or some number of changes, in the signal on CCPx.
When this occurs, the current value of TMR1 is copied into a pair of registers: CCPRxH and CCPRxL
(where ‘x’ is ‘1’, ‘2’, ‘3’ or ‘4’), forming the upper and lower 8 bits of the 16-bit captured timer value.
An interrupt request flag is also set, to indicate that an event has been captured.
Each CCP module has a separate interrupt flag, CCPxIF, located in one of the peripheral interrupt registers:
PIR1 TMR1GIF ADIF RCIF TXIF SSP1IF CCP1IF TMR2IF TMR1IF

PIR2 OSFIF C2IF C1IF EEIF BCL1IF – – CCP2IF

PIR3 – – CCP4IF CCP3IF TMR6IF – TMR4IF –
As always, an interrupt can only be triggered if the corresponding enable bit (CCPxIE) is set. These are
located in the peripheral interrupt enable registers:

PIE1 TMR1GIE ADIE RCIE TXIE SSP1IE CCP1IE TMR2IE TMR1IE

PIE2 OSFIE C2IE C1IE EEIE BCL1IE – – CCP2IE

PIE3 – – CCP4IE CCP3IE TMR6IE – TMR4IE –
The available capture events, and the

corresponding mode selection bit settings, are CCPxM<3:0> mode capture event
shown in the table on the right. 0000 off
0100 capture every falling edge
If TMR1 is incrementing at a known rate, this
allows us to measure the time between events, 0101 capture every rising edge
by subtracting the captured timer values. 0110 capture every 4th rising edge
Hopefully some examples will make this 0111 capture every 16th rising edge
clearer!
1
on the PIC16F1824, CCP1, CCP2, CCP3 and CCP4 are shared by default with RC5, RC3, RA2, and RC1
respectively, although CCP2 can alternatively be assigned to RA5, using the APFCON1 register (see the data sheet)
Example 1: Period measurement using capture mode

To show how capture mode can be used to measure the period of a digital signal, we’ll use the circuit
(similar to those used in the Timer1 gate control examples in lesson 12) shown below:
Once again, the 555 timer generates a train of digital pulses (square waves), with the potentiometer adjusting
the frequency between approximately 150 and 10000 Hz (depending on component values, which will vary
due to tolerances), generating active-high pulses ranging from less than 100 µs to more than 3000 µs.
This variable-frequency oscillator is included on the Gooligum training board, with the frequency controlled
by trimpot RP1. If you have the Gooligum board, you can implement this circuit by:
 placing shunts (six of them) across every position in jumper block JP4, connecting segments A-D, F
and G to pins RA0-1 and RC1-4
 placing a single shunt in position 2 (“RA/RB2”) of JP5, connecting segment E to pin RA2
 placing a shunt across pins 1 and 2 (“GND”) of JP6, connecting digit 1 to ground
 placing a shunt in position 1 (“CCP1”) of JP26, connecting the variable frequency digital output to
the CCP1 pin.
All other shunts should be removed.
If you are using the Microchip Low Pin Count Demo Board, you will need to build the 555-based oscillator
circuit separately and connect it to the 14-pin header on the demo board (RC5/CCP1 is available on pin 4 of
the header, while power and ground are pins 13 and 14).
We will display the measured period as a single hexadecimal digit on the 7-segment LED display – after
appropriate scaling, of course!
To measure the period of a signal, we need to record the time at the start of the signal (t1), and at the end of
the signal (t2). The period (T) is then the difference between the two: T = t2 – t1.
Our signal is a square wave, so the start of the signal is the rising edge of each pulse, and the end of the
signal is the rising edge of the next pulse (the end of one period is the start of the next).
Or, you could say that the period is the time between successive falling edges. With a simple square wave, it
doesn’t matter if we measure the time between rising or falling edges – we’ll get the same period, either way.
So, to measure the signal’s period, we need to record (or capture) the time of every rising or falling edge.
That’s a good task for the ECCP module, in capture mode!
To measure time, we need a timer, incrementing at a steady, known rate.

Since the ECCP module’s capture mode uses Timer1, we don’t have any choices here; we have to configure
Timer1 to provide the time base.
If you have an accurate external clock source available, you could use it to drive Timer1 in counter mode
(see example 3 in lesson 12). Or you could use Timer1’s LP oscillator with a watch crystal, as we did in
examples 4 and 5 in that lesson. But if you do use Timer1 in counter mode, you must configure it as a
synchronous counter, to ensure that it works correctly with the CCP modules.
In this example, we’ll configure Timer1 in timer mode, where the timing is derived from the processor clock.
We’re not aiming for high accuracy, so the internal RC oscillator is good enough to use as the time base.
It is easiest to calculate the period if the timer can run for the whole period without overflowing.
Given that Timer1 is a 16-bit timer, it will overflow after 65,536 increments, and ideally the period should be
less than this.
For the best time resolution, we should run Timer1 as quickly as possible, while keeping the period to less
than 65,536 increments.
Our signal has a minimum frequency of around 150 Hz, so the maximum period will be around 7 ms.
Given a 32 MHz processor clock, if we select the instruction clock (FOSC/4) with no prescaler as the Timer1
clock source, TMR1 will increment every 0.125 µs.
Timer1 will then overflow every 65,536 × 0.125 µs = 8.192 ms, allowing us to measure periods up to 8 ms or
so. That’s a little more than we need, but there’s not much margin for error – what if the maximum period is
a little longer than expected?
It would be better to use a 16 MHz processor clock, with FOSC/4 as the Timer1 clock source and no
prescaler, giving a maximum Timer1 period of 65,536 × 0.25 µs ≈ 16 ms.
So first, we configure the device to use the internal RC oscillator, as usual:

/***** CONFIGURATION *****/
// ext reset, internal oscillator (no clock out), 4xPLL off
#pragma config MCLRE = ON, FOSC = INTOSC, CLKOUTEN = OFF, PLLEN = OFF
// no watchdog timer, brownout resets enabled, low brownout voltage
#pragma config WDTE = OFF, BOREN = ON, BORV = LO
// no power-up timer, no failsafe clock monitor, two-speed start-up disabled
#pragma config PWRTE = OFF, FCMEN = OFF, IESO = OFF
// no code or data protect, no write protection
#pragma config CP = OFF, CPD = OFF, WRT = OFF
// stack resets on, high-voltage programming
#pragma config STVREN = ON, LVP = OFF
We then select the 16 MHz clock (see lesson 7):

// configure oscillator
OSCCONbits.SCS1 = 1; // select internal clock
OSCCONbits.IRCF = 0b1111; // internal oscillator = 16 MHz
We must configure the CCP1 pin (shared with RC5) as a digital input2:
// configure ports
LATA = 0; // start with all output pins low
LATC = 0; // (all LED segments off)
TRISA = 0; // configure PORTA and PORTC as all outputs
TRISC = 1<<5; // except RC5 (CCP1 input)
Timer1 is configured with the instruction clock source and no prescaler (see lesson 12):
// configure Timer1
T1CONbits.TMR1CS = 0b00; // use instruction clock
T1CONbits.T1CKPS = 0b00; // no prescaler
T1CONbits.TMR1ON = 1; // enable timer
// -> increment TMR1 every 0.25 us
Now we can configure the CCP module to capture every falling or rising edge, with:
// configure ECCP1 module
CCP1CONbits.CCP1M = 0b0101; // capture every rising edge on CCP1
or:
CCP1CONbits.CCP1M = 0b0100; // capture every falling edge on CCP1
Note that, since the variable signal is connected to the CCP1 (RA5) pin, we are using the ECCP1 module to
capture it.
If the signal was, for example, connected to the CCP3 (RA2) pin, we’d use the CCP3 module in exactly the
same way, but using the CCP3CON register instead. Once again, the four “CCP” modules are completely
interchangeable, as far as the capture mode is concerned.
With the CCP module and timer configured and running, we can process each capture event.
In pseudo code, the main loop will look like:
repeat
wait for a capture event
period = current capture time – previous (saved) capture time
scale and display period
save current capture time (for next period calculation)
forever
The first step, waiting for a capture event (such as a falling or rising edge on CCP1) is easy – simply poll the
CCP1IF flag:
// wait for capture event
while (!PIR1bits.CCP1IF) // wait for CCP1 interrupt flag to go high
;
PIR1bits.CCP1IF = 0; // clear flag for next event
2
a pin cannot be used as a CCP input if analog input mode is selected for that pin. For example, to use CCP3 as a
CCP input, you must configure RA2 (shared with CCP3) as a digital input by clearing the ANSELA<2> bit.
Note that the flag has to be cleared after the polling loop, ready to be set by the next capture event.
At this point, the CCPR1 registers hold the value of TMR1 when the event occurred.
We already have the “current capture time” – it is simply the current value of CCPR1.
But it’s clear that we will need to save this current value somewhere, so that it can become the “previous
capture time”, when the process the next event. This means that we will need an unsigned 16-bit variable to
hold our “saved” (or “previous”) capture time:
uint16_t ccpr1_s = 0; // saved value of CCPR1 (previous capture)
It’s being initialised to zero to ensure that the first period calculation will be valid.
Now we need to calculate and display the period.

The signal’s period is equal to the current capture time (held in the CCPR1 registers) minus the previous
capture time (saved in ccpr1_s).
XC8 makes the CCPR1 registers available as an unsigned 16-bit variable, ‘CCPR1’.
So, if we declare an unsigned 16-bit variable, ‘period’:
uint16_t ccpr1_s = 0; // signal period
the period calculation is simply:

period = CCPR1 – ccpr1_s; // period = current capture - saved
You may think that this is too simple – what if ccpr1_s is greater than CCPR1? Wouldn’t the result of the
subtraction then be negative? And how can we have a negative period?
If the calculation was done with signed integers, you would be right. However, these variables are all
unsigned 16-bit integers, and because of the way that fixed-length unsigned integer arithmetic operates, the
subtraction always “just works” and we will get the correct result. If you want to see how this is possible,
see enhanced mid-range assembler lesson 17, where this is explained in detail.
Having calculated the signal’s period, we need to display it as a single hex digit, which means that we must
scale it to the range 0 to 15 (four bits).
Our maximum period will be around 7 ms. At 0.25 µs per clock, that’s a maximum of 28,000 clock periods.
To avoid complicated (and slow) arithmetic, it’s best to scale using simple binary operations, such as shifts,
if possible. So, it’s easiest to work in binary if we can.
28,000 is close to 32,728 = 215.
This means that we can consider the period to be a 15-bit quantity. So, to convert it to a 4-bit quantity for
display, we divide it by 211 = 2048.
Since we have a single digit display, to be safe, we should also mask off (clear) the upper nybble (4 bits)
before trying to display the result, to ensure that we never try to display a value greater than ‘F’ (15).
So we have:
set7seg(period/2048 & 0x0f); // display scaled period
(using the 7-segment display function developed in lesson 10)
Thus, to calculate the period, scale and display it, we have:

period = CCPR1 – ccpr1_s; // period = current capture - saved
set7seg(period/2048 & 0x0f); // display scaled period
In this example, the only thing we’re doing with the period is displaying it, so we don’t need to keep the
period for any purpose, and we can collapse this down to a single expression within the function call:
// calculate and display scaled period
set7seg((CCPR1 - ccpr1_s)/2048 & 0x0f); // period = capture - saved
Finally, we need to save the current capture value for next time:
ccpr1_s = CCPR1;
Complete program
This is how it all fits together (using falling edges):
/************************************************************************
* *
* Description: Lesson 14, example 1b *
* *
* Demonstrates use of CCP capture mode *
* to measure the period of a digital signal on CCP1, *
* scaled and displayed as a single hex digit *
* *
* Period (in 0.25 us) between falling edges on CCP1 is captured *
* Result is divided by 2048 and displayed in hex on a single-digit *
* 7-segment LED display. *
* Time base is internal RC oscillator at 16 MHz. *
* *
*************************************************************************
* *
* Pin assignments: *
* RA0-2, RC1-4 = 7-segment display bus (common cathode) *
* CCP1 = signal to measure period of (8 ms max) *
* *
************************************************************************/
#include <xc.h>
#include <stdint.h>

/***** PROTOTYPES *****/

void set7seg(uint8_t digit); // display digit on 7-segment display
/***** MAIN PROGRAM *****/
void main()
{
uint16_t ccpr1_s = 0; // saved value of CCPR1 (previous capture)
/*** Initialisation ***/
// configure ports
// configure Timer1
// -> increment TMR1 every 0.25 us

CCP1CONbits.CCP1M = 0b0100; // capture every falling edge on CCP1
/*** Main loop ***/

for (;;)
{
// Measure period of pulses on CCP1 input
// wait for capture event

;

set7seg((CCPR1 - ccpr1_s)/2048 & 0x0f); // period = capture - saved
// save current capture time for next period

ccpr1_s = CCPR1;
}
}
/***** FUNCTIONS *****/
/***** Display digit on 7-segment display *****/

void set7seg(uint8_t digit)
{
// pattern table for 7 segment display on port A
const uint8_t pat7segA[16] = {
// RA2:0 = EFG
0b000110, // 0
0b000000, // 1
0b000101, // 2
0b000001, // 3
0b000011, // 4
0b000011, // 5
0b000111, // 6
0b000000, // 7
0b000111, // 8
0b000011, // 9
0b000111, // A
0b000111, // b
0b000110, // C
0b000101, // d
0b000111, // E
0b000111 // F
};
// pattern table for 7 segment display on port C

const uint8_t pat7segC[16] = {
// RC4:1 = CDBA
0b011110, // 0
0b010100, // 1
0b001110, // 2
0b011110, // 3
0b010100, // 4
0b011010, // 5
0b011010, // 6
0b010110, // 7
0b011110, // 8
0b011110, // 9
0b010110, // A
0b011000, // b
0b001010, // C
0b011100, // d
0b001010, // E
0b000010 // F
};
// lookup pattern bits and output them (via port latch registers)
LATA = pat7segA[digit];
LATC = pat7segC[digit];
}
Example 2: Pulse width measurement using capture mode

Capture mode can also be used to measure the width of a pulse, which we can demonstrate using the circuit
from the last example.
Given that the pulse width is the time between each rising edge and the next falling edge, we need to capture
the rising and falling edges. Then, for each pulse, we subtract the rising edge time from the falling edge
time, to get the pulse width.
This means that, instead of configuring the CCP module once, in our initialisation code, we need to
configure it at the start of the main loop to capture rising edges, wait for the rising edge, and then reconfigure
it to capture falling edges, wait for the falling edge, and finally subtract the two capture times to calculate the
pulse width.
So we begin the main loop by waiting for the rising edge at the start of the pulse:
// wait for rising edge (pulse start)
CCP1CONbits.CCP1M = 0b0101; // configure ECCP1 to capture rising edges
;
If we now save the captured time, we have a record of when the pulse started:
// save capture value at pulse start
ccpr1_s = CCPR1;
So far, this is the same as the period measurement technique. The difference with pulse width measurement
is that we now reconfigure the CCP module to capture falling edges, and wait for the end of the pulse:
// wait for falling edge (pulse end)
CCP1CONbits.CCP1M = 0b0100; // configure ECCP1 to capture falling edges
;
We can now subtract the two captured times, to give the width:
width = CCPR1 – ccpr1_s; // width = pulse end - pulse start
// = current capture – saved
This is the same as before, except that we’ve named the variable ‘width’, instead of ‘period’.
It holds the number of 0.25 µs periods (assuming that Timer1 has been configured to increment every 0.25
µs, as before) between the pulse’s rising and falling edges.
We have to scale this value for display as a single hex digit.
Although we could divide by 2048, as we did for the period measurement, we can get better resolution by
dividing by only 1024 – because although the signal’s period could be up to 8 ms, its pulse width should be
no more than 4 ms, with the component values shown.
So to scale and display the pulse width, we have:
set7seg(width/1024 & 0x0f); // display scaled pulse width
Again, we can do without the ‘width’ variable, collapsing these two statements down to one:
// calculate and display scaled width
set7seg((CCPR1 - ccpr1_s)/1024 & 0x0f); // width = pulse end - start
// = capture - saved
Finally, we can repeat the process – going back to wait for the next rising edge.
Our main loop is therefore:
/*** Main loop ***/
for (;;)
{
// Measure with of pulses on CCP1 input
// wait for rising edge (pulse start)

CCP1CONbits.CCP1M = 0b0101; // configure ECCP1 to capture rising edges
;
// save capture value at pulse start

ccpr1_s = CCPR1;
// wait for falling edge (pulse end)

CCP1CONbits.CCP1M = 0b0100; // configure ECCP1 to capture falling edges
;
// calculate and display scaled width

set7seg((CCPR1 - ccpr1_s)/1024 & 0x0f); // width = pulse end - start
// = capture - saved
}
The code is otherwise the same as it was in the first example, so there is no need to repeat it here.
As an exercise, you may wish to calculate the signal’s period, as well as its pulse width, by combining these
first two examples. The period calculation would be done immediately after each rising edge is captured,
before the falling edge is captured. By adding display multiplexing (see lesson 10), you could output the
period and pulse width on separate digits. And if you want a real challenge, you could divide the pulse width
by the period, to get the duty cycle, and display that (perhaps as a value from 00h to FFh, instead of as a
percentage) using a couple of 7-segment digits.
It’s interesting to compare the capture mode approach to the one we took in lesson 12, where we used
Timer1 gate control for pulse width measurement. Both methods use Timer1, and have the same time
resolution (dependent on how quickly Timer1 is incremented).
The Timer1 gate control method is simpler in some ways – so why would we choose to use capture mode?
Perhaps the most significant reason is that devices such as the PIC16F1824 commonly have several CCP
inputs, making it possible to capture multiple inputs (comparing the pulse widths of a couple of inputs, for
example), but they usually only have a single timer gate input.
Example 3: Period measurement using capture mode interrupts

Instead of polling the CCP interrupt flag, you may prefer to use an interrupt handler to process each capture
event – especially if your code needs to be doing other things “at the same time”.
In this example, we’ll continue to use the circuit from the first two examples, to show how CCP interrupts
can be used to measure the period of a square wave.
If enabled, the CCP interrupt is triggered on every capture event. The interrupt handler would then calculate
the signal’s period, in much the same way as we did in example 1. The ISR would typically store the period
in a variable, which would be processed and/or displayed by another routine, perhaps within the main loop or
in another interrupt handler – similar to what we did to display the ADC output in the ADC interrupt
example in lesson 11.
However, you probably don’t want the interrupt handler to run too often, or else you won’t have enough time
between interrupts to do much else.
With the oscillator running at up to 10 kHz, the CCP interrupt could be run as often as every 100 µs – if it is
triggered on every pulse.
Luckily, the CCP modules provide a way to limit how often each CCP interrupt is triggered: instead of
capturing every falling or rising edge, as we did in example 1, we can capture every 4th or 16th rising edge.
We can configure the ECCP1 module to capture every 16th rising edge, with:
CCP1CONbits.CCP1M = 0b0111; // capture every 16th rising edge on CCP1
With the oscillator running at 10 kHz, the CCP interrupt would now be triggered every 16 × 100 µs = 1.6 ms,
which is much more reasonable.
Another advantage of capturing every 16th rising edge is that we’re effectively measuring the average period
of a series of 16 pulses – which is useful if there is some jitter in the signal which we’d like to smooth out,
without having to implement an averaging filter, like the one in lesson 11.
However, if our oscillator runs at its minimum 150 Hz, giving a period of around 7 ms, the interrupt would
be triggered every 16 × 7 ms = 112 ms. If we continue to run the device at 16 MHz (0.25 µs per instruction
clock), that’s a period between capture events of up to 448,000 instruction cycles.
Our 16-bit timer, TMR1, can only count up to 65,535, so, if we don’t make any other changes, the timer will
overflow between capture events. We could run the PIC at a lower clock rate (see lesson 7), but that defeats
the purpose of reducing the number of interrupts (if we run the PIC more slowly, we can’t do as much
processing between interrupts).
The solution is simple – use a 1:8 prescaler with Timer1:
// configure Timer1
T1CONbits.T1CKPS = 0b11; // prescale = 8
// -> increment TMR1 every 2 us
With TMR1 incrementing every 2 µs, it will overflow every ~131 ms – long enough to measure our signal’s
period, even at the slowest oscillator speed.
Previously, when measuring a single pulse, our “full scale” of ~8 ms was 32,767 (215-1) × 0.25 µs counts.
Now that we’re capturing every 16th rising edge, and counting every 2 µs, our full scale of ~131 ms will be
65,535 (216-1) counts.
To convert this to a 4-bit quantity, for display as a single hex digit, we need to divide it by 212 = 4096.
So, to calculate, scale and display the period, we now have:
set7seg((CCPR1 - ccpr1_s)/4096); // period = current capture - saved
If you make these changes to the code from example 1, the resulting program should work the same way as
before, displaying a ‘0’ when (if you are using the Gooligum training board) trimpot RP1 is turned all the
way clockwise, and ‘d’ (or maybe ‘c’ or ‘E’, depending on component values) when it is at the other
extreme.
But of course, we want to implement this using interrupts!

First, we need to enable the CCP interrupt:
PIE1bits.CCP1IE = 1; // enable CCP1 interrupt
and of course peripheral and global interrupts, as usual:

INTCONbits.PEIE = 1; // enable peripheral interrupts
ei(); // enable global interrupts
Our interrupt handler should begin, as always, by clearing the CCP interrupt flag:
//*** Service CCP1 interrupt
//
// Triggered on capture event,
// every 16th rising edge on CCP1 input
//
// Measures average period of pulses on CCP1 input
//
// (only CCP1 interrupts are enabled)
//
PIR1bits.CCP1IF = 0; // clear interrupt flag
Then, within the interrupt handler, we can calculate the signal’s period:
// calculate period
period = CCPR1 - ccpr1_s; // = current capture - saved
As we’ve mentioned before, interrupt handlers should ideally be kept short, performing their specific task,
but no more than necessary. In this case, the CCP interrupt handler records the period between each capture
event, but that’s all it needs to do. Scaling and displaying the period can be done elsewhere, such as in the
main loop (as we’ll do in this example) and/or another interrupt handler.
That means that, because the ‘period’ variable is used to pass data (the signal’s period…) between
functions, it has to be defined as a global variable, before the main() function:
/***** GLOBAL VARIABLES *****/
uint16_t period; // signal period (raw)
On the other hand, the variable used to store the previous capture value, ccpr1_s, is only used within the
interrupt handler, so should be defined at the start of the interrupt service routine:
void interrupt isr(void)
{
static uint16_t ccpr1_s = 0; // saved value of CCPR1 (previous capture)
Since it has to be preserved between interrupts (the whole point of this variable is that, each time the CCP
interrupt runs, ccpr1_s holds the value that was in CCPR1, from the previous time the CCP interrupt ran),
it must be defined as ‘static’.
And, to ensure that the period calculation is correct the first time that the CCP interrupt handler runs, it is
initialised to zero.
Finally, save the current capture value, in CCPR1, for the next time the CCP interrupt is triggered:
// save current capture value for next period
ccpr1_s = CCPR1;
The main loop only has to display the period, which (you might suppose) we could do by:
for (;;)
{
// display scaled period
set7seg(period/4096);
}
However, we do need to be careful here.
The ‘period’ variable is updated by the interrupt service routine, which could run at any time.
It holds a 16-bit value and, as we’ve discussed before, the enhanced mid-range PICs can only operate on
eight bits at a time. This means that it is possible that the ISR will run, updating the value in ‘ period’, in
the middle of the ‘period/4096’ calculation.
Whether or not that might be a problem will depend on the compiler’s implementation of that expression. In
fact, with XC8 v1.34, running in “Free mode”, it’s not a problem. But there is no guarantee that a future
version of the compiler, or a different compiler (if you later port the code) will perform the calculation in the
same way. The danger is that, if ‘period/4096’ doesn’t evaluate correctly, a value greater than 15 might
be passed to the set7seg() function, which would then attempt to lookup a value beyond the end of the
pattern arrays, and the program would probably crash.
To avoid this potential problem we can use another variable, ‘digit’, which will hold the value of the digit
to be displayed.
First, ‘digit’ is defined as a local variable within main(), since it’s not accessed in any other part of the
program:
void main()
{
uint8_t digit; // digit to be displayed
We can disable interrupts while calculating the digit to display (the scaled period), by wrapping the
expression within a pair of ‘di()’ and ‘ei()’ statements:
// calculate scaled period
di(); // (disable interrupts while accessing period)
digit = period/4096;
ei();
We can now be sure that ‘period’ won’t change during this calculation.
As we’ve noted before, any such sections of code, where interrupts are disabled, should be kept as short as
possible, to give any interrupts a chance to run as soon as possible after the event that triggered them.
Finally, we can safely display the result:
set7seg(digit);
Complete program
Here is how these fragments fit together:
/************************************************************************
* *
* *
* Demonstrates use of CCP capture mode interrupts *
* to measure the period of a digital signal on CCP1, *
* scaled and displayed as a single hex digit *
* *
* Period between every 16th rising edge on CCP1 is captured *
* using CCP1 interrupt handler *
* Result is scaled and displayed in hex on a single-digit *
* 7-segment LED display. *
* Time base is internal RC oscillator at 16 MHz. *
* *
*************************************************************************
* RA0-2, RC1-4 = 7-segment display bus (common cathode) *
* CCP1 = signal to measure period of (8 ms max) *
************************************************************************/
#include <xc.h>
#include <stdint.h>


/***** GLOBAL VARIABLES *****/

uint16_t period; // signal period (raw)

void main()
{
uint8_t digit; // digit to be displayed
// configure ports
// -> 0.25 us / instruction cycle
// configure Timer1

CCP1CONbits.CCP1M = 0b0111; // capture every 16th rising edge on CCP1
// enable interrupts
/*** Main loop ***/

for (;;)
{
// calculate scaled period
di(); // (disable interrupts while accessing period)
digit = period/4096;
ei();

set7seg(digit);
}
}
/***** INTERRUPT SERVICE ROUTINE *****/

{
static uint16_t ccpr1_s = 0; // saved value of CCPR1 (previous capture)

//
// Triggered on capture event,
// every 16th rising edge on CCP1 input
//
// Measures average period of pulses on CCP1 input
//
//
// calculate period
period = CCPR1 - ccpr1_s; // = current capture - saved
// save current capture time for next period

ccpr1_s = CCPR1;
}
/***** FUNCTIONS *****/

{
// RA2:0 = EFG
0b000110, // 0
0b000000, // 1
0b000101, // 2
0b000001, // 3
0b000011, // 4
0b000011, // 5
0b000111, // 6
0b000000, // 7
0b000111, // 8
0b000011, // 9
0b000111, // A
0b000111, // b
0b000110, // C
0b000101, // d
0b000111, // E
0b000111 // F
};

// RC4:1 = CDBA
0b011110, // 0
0b010100, // 1
0b001110, // 2
0b011110, // 3
0b010100, // 4
0b011010, // 5
0b011010, // 6
0b010110, // 7
0b011110, // 8
0b011110, // 9
0b010110, // A
0b011000, // b
0b001010, // C
0b011100, // d
0b001010, // E
0b000010 // F
};
// lookup pattern bits and output them (via port latch registers)
}
Compare Mode
Compare mode automatically performs an action, such as changing the state of one of the CCPx pins,
whenever TMR1 matches the contents of the CCPRx registers. If TMR1 is incrementing at a known rate,
this allows us to schedule a particular action to be performed at a predetermined time.
The active CCP module’s CCPxIF interrupt request flag is also set, and an interrupt will be triggered if the
corresponding CCPxIE enable bit is set, and peripheral interrupts are enabled.
Compare mode is often used to generate precisely-timed pulses, such as those used in some serial modulation
formats. It is also used to schedule periodic interrupts, and to automatically sample the ADC at a steady rate,
as we shall see.
The available compare actions, and their CCPxM<3:0> mode compare action
corresponding mode selection bit settings,
are shown in the table on the right. 0000 off
0010 compare toggle CCPx output
1000 compare set CCPx output
Hopefully some more examples will make 1001 compare clear CCPx output
this clearer!
1010 compare none (interrupt only)
1011 compare clear TMR1,
initiate ADC if enabled
Example 4: Using compare mode to flash an LED

Although compare mode is most commonly used to generate short pulses, such as those used in serial
communications, we can make the compare mode actions visible (literally!) by, yet again, flashing an LED.
To make the CCP2 output visible, we can connect an LED to

the CCP2 pin (shared with RC3) of a PIC16F1824, as shown
on the right.
If you have the Gooligum training board, close jumper JP19

to enable the LED on RC3. All other jumpers should be
removed.
Or, if you are using Microchip’s Low Pin Count Demo Board,
you only need to plug in your PIC16F1824; the LED on RC3
is labelled DS4.
To flash the LED at 1 Hz, with a 50% duty cycle (as we’ve
done numerous times, going back to lesson 2), we need to
toggle the CCP2 output every 500 ms.
Therefore, we should select CCP mode ‘0010’: “Compare mode, toggle output on match”.
We then start Timer1 counting at some known, steady rate, and load a value into the CCPR2 registers such
that 500 ms will have passed when TMR1 reaches that value.
So, Timer1 has to be able to count for at least 500 ms without overflowing.
In lesson 12 we saw that, in instruction clock timer mode, with the default 500 kHz processor clock and no
prescaler, Timer1 will overflow every 524 ms. That’s more than the 500 ms we need, so we can configure
the PIC to use the internal RC oscillator, running at the default 500 kHz, and initialise Timer1 with:
OSCCONbits.IRCF = 0b0111; // internal oscillator = 500 kHz
// -> 8 us / instruction cycle
// initialise Timer1
TMR1 = 0; // clear timer
TMR1 is being cleared here, to make it easy to load the appropriate initial value into CCPR2, so that a
match will occur after 500 ms:
CCPR2 = 500000/8; // initial compare time = 0.5 s /8 us/count
We can then configure the ECCP2 module to toggle the CCP2 pin when TMR1 reaches the value stored in
the CCPR2 registers:
CCP2CONbits.CCP2M = 0b0010; // compare mode, toggle CCP2 on match
Note that, for CCP2 to be used as an output, the pin it shares (RC3) must also be configured as an output:
TRISC = ~(1<<3); // configure PORTC as all inputs
// except RC3 (CCP2 output)
Following a power-on reset, each CCPx output is initially low.

Therefore, after completing the previous initialisation instructions, the LED will be initially off. Meanwhile,
TMR1 will be counting, incrementing every 8 µs. After 500 ms, TMR1 will reach 62,500 (= 500,000 ÷ 8),
which is the value stored in CCPR2, and the CCP2 output will toggle – changing to high.
Thus, if we do nothing else, the LED will turn on, automatically, after 500 ms.
Since we want the LED to continually flash, we need to wait for CCP2 to toggle, then add the appropriate
value to CCPR2 (such that CCP2 will toggle again, after another 500 ms), and then repeat.
CCP2 will toggle when a CCP match occurs, and we can detect it by clearing the CCP2IF flag, and then
waiting until it goes high:
// wait for CCP match
PIR2bits.CCP2IF = 0; // clear CCP2 interrupt flag
while (!PIR2bits.CCP2IF) // wait for flag to go high
;
At this point, we know that the CCP2 output has toggled.

We can now add another 500 ms to the value in CCPR2:
// add 0.5 sec to last compare time
CCPR2 += 500000/8; // add 0.5 sec / 8 us/count
TMR1 will continue to increment (we don’t care about TMR1 overflows), and when it reaches this new
compare value, CCP2 (and our LED) will toggle again.
We then wait for this match to happen, add another 500 ms, wait again, add 500 ms, and so on.
Our main loop is then simply:

for (;;)
{
// Toggle CCP2 output every 0.5 sec

;
// add 0.5 sec to last compare time

}
Suppose, though, that instead of simply toggling the output at a steady rate, flashing the LED with a 50%
duty cycle, we wanted to flash the LED asymmetrically, with (say) a 20% duty cycle?
We would need to change our approach – clearing the CCP2 output (turning off the LED), waiting 800 ms,
setting the CCP2 output (lighting the LED), then waiting another 200 ms, and then repeating.
We could do that with the “toggle” action, as above, but it would be hard to keep track of what we were
doing. It’s easier to understand if we explicitly use the “set” and “clear” actions to turn the LED on and off.
This means that, instead of configuring the CCP module once, in the initialisation routine, we need to re-
configure it, to alternately set and clear CCP2, within the main loop.
But first, we have to address a small problem. Our LED has to stay off for 800 ms, which means that TMR1
has to be able to count for at least 800 ms without overflowing. But, as mentioned above, with the default
500 kHz processor clock and no prescaler, Timer1 will overflow every 524 ms.
In this case, the solution is easy – select a 1:2 prescale ratio!
The Timer1 initialisation then becomes:
TMR1 will now increment every 16 µs and will overflow every 1049 ms, which is long enough.
Recall that, following a power-on reset, the CCP2 output will initially be low.
That means that, when we start the main loop, we should assume that CCP2 is low, and the LED is off.
We want the LED to stay off for 800 ms, and then turn on, so we should configure the ECCP2 module to set
the CCP2 output (lighting the LED), 800 ms from now:
// add 0.8 sec to previous compare time
// configure ECCP2 to set CCP2 when compare time reached

CCP2CONbits.CCP2M = 0b1000; // compare mode, set CCP2 on match
There is nothing to do now but wait for the match to happen, which we can do by monitoring the CCP2IF
flag, as we did before:
;
At this point, we know that the CCP2 output has just gone high. We want the LED to stay on for 200 ms, so
we should re-configure the ECCP2 module to clear CCP2 (turning off the LED), after another 200 ms:
// configure ECCP2 to clear CCP2 when compare time reached

CCP2CONbits.CCP2M = 0b1001; // compare mode, clear CCP2 on match
Now we have to wait once more for TMR1 to match CCPR2:

;
When the CCP2IF flag goes high, we know that the CCP action (clearing CCP2) has occurred.
The LED has been turned off, we’re back to where we started, and we can restart the main loop.
Once we’re into the main loop, accurate pulse timing is maintained by adding fixed quantities to the compare
value stored in CCPR2, as TMR1 continues to steadily count. The timing of each transition is relative to the
last – the LED turns off 200 ms after it turns on, and we don’t care about the actual values are, at the start of
the loop. As long as we add the values corresponding to 200 ms and 800 ms, the correct timing will be
maintained, each time we go around the loop.
However, we need to start somewhere. If we want the LED to stay off for a full 800 ms, the first time the
main loop is entered, we need to clear TMR1 and CCPR2 before the main loop starts. But – and this is the
important point for understanding compare mode – having cleared CCPR2 once, we never have to load a
value into it again. It’s all done by adding, because the timing of each pulse is always relative.
Complete program
Here is how these fragments fit together, to form the “flash an LED with 20% duty cycle using CCP”
program:
/************************************************************************
* *
* Demonstrates use of CCP compare mode *
* to generate high and low pulses on the CCP2 pin *
* *
* Flashes an LED on CCP2 at 1 Hz, with 20% duty cycle *
* Time base is internal RC oscillator at 500 kHz. *
* *
*************************************************************************
* *
* CCP2 = indicator LED *
* *
************************************************************************/
#include <xc.h>
#include <stdint.h>


void main()
{
// configure ports
TRISC = ~(1<<3); // configure PORTC as all inputs
// except RC3 (CCP2 output)
// initialise ECCP2 module

CCPR2 = 0; // initial compare time = 0
// (CCP initially off, CCP2 output low)
/*** Main loop ***/

for (;;)
{
// Output low for 0.8 sec

// configure ECCP2 to set CCP2 when compare time reached

CCP2CONbits.CCP2M = 0b1000; // compare mode, set CCP2 on match

;
// Output high for 0.2 sec

// configure ECCP2 to clear CCP2 when compare time reached

CCP2CONbits.CCP2M = 0b1001; // compare mode, clear CCP2 on match

;
}
}
Example 5: Compare mode interrupts

Compare mode can also be used to generate precise intervals, without affecting any of the CCPx output pins.
We can illustrate that by using CCP interrupts to flash an
LED connected to RC0 (which is not shared with any of
the CCPx outputs), as shown in the circuit on the right, at
exactly 1 Hz.
If you have the Gooligum training board, close the jumper

JP16 to enable the LED on RC0.
Or, if you are using Microchip’s Low Pin Count Demo
Board, note that the LED on RC0 is labelled DS1.
In lesson 5 we used Timer0 interrupts to flash an LED at

exactly 1 Hz (given an accurate 500 kHz processor clock),
by adding an offset to TMR0 within the ISR.
We also saw, in lesson 12, that it’s messy to try to take the
same approach with Timer13.
A more elegant way to do this is to use compare mode to generate a periodic interrupt.
If we select CCP mode ‘1010’, the CCPxIF interrupt flag will be set when TMR1 matches CCPRx, but no
other action will occur. This means that, in CCP mode ‘1010’, a CCP interrupt will be triggered when
TMR1 matches CCPRx, if the corresponding CCP interrupt is are enabled.
This is also true in the other compare modes, such as those used in example 4, above. The difference with
mode ‘1010’ is that no other action occurs. A CCP interrupt will be triggered (if enabled), but the CCPx
output will not be affected.
We’ll flash the LED with a simple 50% duty cycle, as we did in the timer interrupt examples in lessons 5 and
12. Our code will be quite similar to those examples, except that we’re now using a CCP interrupt. That is,
the ISR will toggle the LED output every 500 ms, leaving the main loop with nothing to do.
And, to illustrate the point that the CCP modules are interchangeable, we’ll use CCP3 in this example.
The ISR will be triggered when TMR1 matches CCPR3, and we want this to occur every 500 ms. We’ve
seen that Timer1 can be configured to count for up to 524 ms without overflowing, given a 500 kHz
processor clock and no prescaler, so 500 ms is ok.
To make the code more maintainable, we’ll define this toggle period as a constant:
#define FlashMS 500 // LED flash toggle time in milliseconds
// (max 524 ms)
3
when adding an offset to a 16-bit timer that is actively counting, the timer may overflow during the 16-bit addition
because the PIC is an 8-bit device, and this possibility has to be handled carefully, leading to increased code complexity
Since TMR1 will be incrementing every 8 µs, we can generate each new 500 ms interval by adding
FlashMS*1000/8 to CCPR3, in much the same way as in example 4.
Instead of repeating this expression multiple times, we can make the code a little easier to read by defining it
as a constant4:
#define IncCCPR FlashMS*1000/8 // Amount to incr CCPRx by to generate
// FlashMS delay (assuming 8 us/tick)
Timer1 and the CCP module are configured as before, except that we will now use CCP mode ‘1010’:
// initialise CCP3 module

CCPR3 = IncCCPR; // load initial compare time
CCP3CONbits.CCP3M = 0b0010; // compare mode, interrupt only
We also need to enable the interrupt for the CCP3 module:

and the peripheral and global interrupts:

Note that, since we cleared TMR1 and loaded CCPR3 with the value that TMR1 will reach in 500 ms, the
first interrupt will occur in 500 ms.
Within the interrupt service routine, we begin by clearing the interrupt flag, as usual:
If we then add 500 ms to the value in CCPR3, the next interrupt will be triggered in another 500 ms:
// add offset to CCPR3 for next match
CCPR3 += IncCCPR;
It’s important to note that this timing will be exact. It doesn’t matter that TMR1 continues to increment
while we do this addition. By adding a value representing 500 ms to CCPR3, we can be sure that the next
interrupt will be triggered exactly 500 ms after this one.
We can then toggle the LED, as we’ve done before:

// toggle flashing LED
F_LED = ~F_LED;
4
whether this is really easier to read is, of course, a question of personal preference…
Finally, the main loop is left with nothing to do:

/*** Main loop ***/
for (;;)
{
; // (do nothing)
}
Complete program
Here is how all these fragments fit together, in a similar way to our earlier interrupt-based LED flashers:
/************************************************************************
* *
* Description: Lesson 14, example 5 *
* *
* Demonstrates use of CCP compare mode interrupts *
* *
* Flashes an LED at 1 Hz, with 50% duty cycle *
* Time base is internal RC oscillator at 500 kHz. *
* *
*************************************************************************
* *
* RC0 = flashing LED *
* *
************************************************************************/
#include <xc.h>
#include <stdint.h>

// Pin assignments
#define F_LED LATCbits.LATC0 // flashing LED on RC0
#define nF_LED 0 // (port bit 0)
/***** CONSTANTS *****/

// (max 524 ms)
#define IncCCPR FlashMS*1000/8 // Amount to incr CCPRx by to generate

void main()
{
// configure ports
LATC = 0; // start with all output pins low (LED off)
TRISC = ~(1<<nF_LED); // configure LED pin (only) as an output

CCPR3 = IncCCPR; // load initial compare time
CCP3CONbits.CCP3M = 0b0010; // compare mode, interrupt only
/*** Main loop ***/

for (;;)
{
; // (do nothing)
}
}

{
//
// Triggered when TMR1 matches CCPR3
// (every 500 ms)
//
// Flashes LED at 1 Hz by toggling on each interrupt
//
//
// add offset to CCPR3 for next match

CCPR3 += IncCCPR;

F_LED = ~F_LED;
}
Example 6: Using CCPRx as a period register for Timer1

If you’re not using the analog-to-digital converter (ADC), the CCP module’s “special event trigger” mode,
‘1011’, provides a simpler way generate periodic interrupts with precise, arbitrary timing.
This “special event trigger” mode is like the “interrupt only” mode used in the last example, in that it sets the
CCPxIF flag, and triggers an interrupt (if CCP interrupts are enabled), when TMR1 matches CCPRx.
However, in addition to triggering an interrupt, special event trigger mode also resets (clears) TMR1 and
starts an analog-to-digital conversion if ADC is enabled.
This means that, assuming that ADC is not enabled, the special event trigger mode has the useful property of
automatically clearing TMR1, as soon as TMR1 reaches the value specified in CCPRx.
Thus, CCPRx acts as a 16-bit period register for Timer1.
This is similar to the Timer2 period register, PR2, described in lesson 13. An important difference,
however, is that PR2 holds Timer2’s maximum count (equal to the period minus one), while, in special
event trigger mode, CCPRx holds Timer1’s period.
For example, if you wanted Timer2 to reset every 100 counts, you would load the value 99 into PR2. But if
you wanted Timer1 to reset every 1000 counts, in special event trigger mode, you would load the value 1000
into one of the CCPRx registers.
To illustrate this, we can re-implement the previous example, using special event trigger mode.
Most of the code is exactly the same, so won’t be repeated here.
We will continue to use the CCP3 interrupt, triggered every 500 ms, to toggle RC0.
And we will still define the toggle period as a constant:
// (max 524 ms)
Timer1 will increment every 8 µs, as before.

The period between interrupts is the same as the Timer1 period: we want Timer1 to be reset every 500 ms.
So, the number of times that TMR1 should increment, before being cleared, is given by:
Timer1 period = 500 ms × 1000 µs/ms ÷ 8 µs/tick = 62,500 ticks
Again, we can define this expression as a constant:
#define T1Period FlashMS*1000/8 // number of Timer1 counts to generate
This value, being the Timer1 period, is the value we need to load into CCPR3.
Initialising the CCP module, selecting mode ‘1011’ this time, then becomes:
CCPR3 = T1Period; // load compare vslue (= TMR1 period)
CCP3CONbits.CCP3M = 0b1011; // special trigger mode (reset TMR1 on match)
The rest of the initialisation, and the main loop, is the same as in the last example.
However, now that TMR1 is being automatically cleared whenever it matches CCPR3, we no longer have
to adjust CCPR3 in the interrupt service routine.
The CCP interrupt handler becomes simply:

//
// Triggered when TMR1 matches CCPR3
// (every 500 ms)
//
// Flashes LED at 1 Hz by toggling on each interrupt
//
//

F_LED = ~F_LED;
And that’s all.

Other than the above changes, the program is exactly the same as in the last example.
Example 7: Periodic analog-to-digital conversions

We saw in lesson 11 that timer interrupts can be used to periodically sample an analog input. The example
in that lesson used a Timer0 interrupt to perform 7-segment LED display multiplexing, and to initiate each
analog-to-digital conversion. The result was then processed by an ADC interrupt handler.
This approach makes sense when you already have a timer interrupt running for some other purpose (such as
display multiplexing) at some rate that is also appropriate for sampling your analog inputs. However, it
won’t always be appropriate to tie analog-to-digital conversions to a timer interrupt in this way.
An alternative, and convenient, way to periodically sample an analog input is to use one of the CCP modules
in “special event trigger” mode. As we saw in the last example, special event trigger mode resets Timer1
and starts an analog-to-digital conversion if ADC is enabled, whenever TMR1 matches CCPRx.
This means that, if the ADC module is enabled, the special event trigger mode has the useful property of
automatically triggering periodic AD conversions, with the period specified by the 16-bit value in CCPRx.
To demonstrate how to do this, we’ll use the 2-digit light meter circuit from lesson 11 , as shown below.
To implement it using the Gooligum training board, place shunts:

 across every position (all six of them) of jumper block JP4, connecting segments A-D, F and G to
pins RA0-1 and RC1-4
 in position 1 (‘RA/RB4’) of JP5, connecting segment E to pin RA4
 across pins 2 and 3 (‘RC5’) of JP6, connecting digit 1 to the transistor controlled by RC5
 in jumpers JP8 and JP9, connecting pins RC5 and RA5 to their respective transistors
 in position 1 (‘AN2’) of JP25, connecting photocell PH2 to AN2.
All other shunts should be removed.
If you are using Microchip’s Low Pin Count Demo Board, you will need to supply your own display
modules, resistors, transistors and photocell, and connect them to the PIC via the 14-pin header on that
board.
Having only two digits instead of three reduces the program complexity a little, making it easier to see how
the CCP module’s special event trigger mode is used to drive the ADC module.
We can adapt the code from the ADC interrupt example in lesson 11, with a Timer0 interrupt used to
multiplex the display.
The Timer0 interrupt handler runs every 2 ms, and displays the current contents of two variables, ‘dig1’ and
‘dig2’. Note that that is the only thing the Timer0 handler is responsible for – unlike in the ADC interrupt
example in lesson 11, it does not trigger any analog-to-digital conversions. Its only job is display the current
contents of those two digit variables.
Instead, we configure one of the CCP modules (we’ll use CCP4), through its special event trigger mode, to
automatically trigger the analog-to-digital conversions:
CCPR4 = ADCPeriod; // compare vslue = ADC sample period
CCP4CONbits.CCP4M = 0b1011; // special trigger mode
// -> sample ADC and reset TMR1 on match
Note that we’re loading CCPR4 with the sample period, which, for better maintainability, has been defined
as a constant:
#define ADCPeriod 10000 // ADC sample period in microseconds
// (max 65535)
This assumes that Timer1 has been configured to increment every 1 µs, which we can do by clocking the
processor at 1 MHz:
// -> Tosc = 1 us, 4 us / instruction cycle
and then configuring Timer1 to use the processor clock:

// configure Timer1
T1CONbits.TMR1CS = 0b01; // use processor clock
With TMR1 being incremented every 1 µs, the maximum sample period will be 65.5 ms.
Since we are only displaying two digits of the ADC result, it is easiest if we configure the ADC with the
result left-justified, with the upper 8 bits in ADRESH:
// configure ADC
ADCON1bits.ADCS = 0b000; // Tad = 2*Tosc = 2 us (with Fosc = 1 MHz)
ADCON1bits.ADFM = 0; // MSB of result in ADRESH<7>
ADCON1bits.ADNREF = 0; // Vref- is Vss
ADCON1bits.ADPREF = 0b00; // Vref+ is Vdd
ADCON0bits.CHS = 0b00010; // select channel AN2
ADCON0bits.ADON = 1; // turn ADC on
We also need to enable the ADC and Timer0 interrupts:

INTCONbits.TMR0IE = 1; // enable Timer0 interrupt
PIE1bits.ADIE = 1; // enable ADC interrupt
Note again that we do not have to enable the CCP or Timer1 interrupts.
The analog-to-digital conversions are triggered automatically when TMR1, after counting for the sample
period (10 ms in this example), matches CCPR4. TMR1 is then automatically reset and the count repeats.
No CCP or Timer1 interrupts are involved – it all “just happens” automatically, behind the scenes.
When the result of the analog-to-digital conversion is ready, the ADC interrupt will be triggered. The ADC
interrupt handler then has to extract the digits from the result, for the Timer0 interrupt handler to display:
// *** Service ADC interrupt
//
// Conversion is initiated by CCP special event trigger,
// every ADCPeriod microseconds
//
PIR1bits.ADIF = 0; // clear interrupt flag
// copy ADC result to display variables
// (to be displayed by Timer0 handler)
dig1 = ADRESH >> 4; // get digit 1 from high nybble of ADRESH
dig2 = ADRESH & 0x0F; // get digit 2 from low nybble of ADRESH
With the ADC interrupt handler extracting the ADC result, and the Timer0 interrupt handler displaying it,
there is nothing for the main loop to do:
/*** Main loop ***/
for (;;)
{
; // do nothing
}
Complete program
Here is how the program, based on the ADC interrupt example from lesson 11, comes together:
*************************************************************************
* *
* Description: Lesson 14, example 7 *
* *
* Demonstrates use of CCP compare mode special event trigger *
* to schedule periodic ADC measurements *
* *
* Displays ADC output in hexadecimal on 7-segment LED displays *
* *
* Regularly samples analog input, using CCP special event trigger, *
* displaying result as 2 x hex digits on multiplexed 7-seg displays *
* *
*************************************************************************
* *
* AN2 = voltage to be measured (e.g. pot or LDR) *
* RA0-1,RA4,RC1-4 = 7-segment display bus (common cathode) *
* RC5 = digit 1 ("tens") enable (active high) *
* RA5 = digit 2 (ones) enable *
* *
************************************************************************/
#include <xc.h>
#include <stdint.h>

// Pin assignments
#define DIG1_EN LATCbits.LATC5 // digit 1 ("tens") digit enable
#define DIG2_EN LATAbits.LATA5 // digit 2 (ones) digit enable
/***** CONSTANTS *****/

#define ADCPeriod 10000 // ADC sample period in microseconds
// (max 65535)


void main()
{
// configure ports
TRISC = 0; // configure PORTA and PORTC as all outputs
TRISA = 1<<2; // except RA2/AN2

ANSELAbits.ANSA2 = 1; // select analog mode for RA2
// -> RA2/AN2 is an analog input
// -> Tosc = 1 us, 4 us / instruction cycle
// configure Timer0
OPTION_REGbits.TMR0CS = 0; // select timer mode
OPTION_REGbits.PSA = 0; // assign prescaler to Timer0
OPTION_REGbits.PS = 0b000; // prescale = 2
// -> TMR0 overflows every 2.048 ms
INTCONbits.TMR0IE = 1; // enable Timer0 interrupt
// configure Timer1
T1CONbits.TMR1CS = 0b01; // use processor clock
// configure ADC
ADCON1bits.ADCS = 0b000; // Tad = 2*Tosc = 2 us (with Fosc = 1 MHz)
ADCON1bits.ADFM = 0; // MSB of result in ADRESH<7>
ADCON1bits.ADNREF = 0; // Vref- is Vss
ADCON1bits.ADPREF = 0b00; // Vref+ is Vdd
ADCON0bits.CHS = 0b00010; // select channel AN2
ADCON0bits.ADON = 1; // turn ADC on
PIE1bits.ADIE = 1; // enable ADC interrupt

CCPR4 = ADCPeriod; // compare vslue = ADC sample period
CCP4CONbits.CCP4M = 0b1011; // special trigger mode
// -> sample ADC and reset TMR1 on match
/*** Main loop ***/

for (;;)
{
; // do nothing
}
}

{
static uint8_t mpx_cnt = 0; // multiplex counter
// current ADC result (in hex):
static uint8_t dig1 = 0; // digit 1 ("tens" - most significant)
static uint8_t dig2 = 0; // digit 2 ("ones" - least significant)
// Service all triggered interrupt sources
if (INTCONbits.TMR0IF)
{
// *** Service Timer0 interrupt
//
// TMR0 overflows every 2.048 ms
//
// Displays current ADC result (in hex) on 7-segment displays
//
INTCONbits.TMR0IF = 0; // clear interrupt flag
// Display current ADC result (in hex) on 2 x 7-segment displays

// mpx_cnt determines current digit to diplay
//
switch (mpx_cnt)
{
case 0:
// display digit 1
set7seg(dig1); // output digit 1
DIG1_EN = 1; // enable digit 1 display
break;
case 1:
// display digit 2
set7seg(dig2); // output digit 2
DIG2_EN = 1; // enable digit 2 display
break;
}
// Increment mpx_cnt, to select next digit for next time
mpx_cnt++;
if (mpx_cnt == 2) // reset count if at end of digit sequence
mpx_cnt = 0;
}
if (PIR1bits.ADIF)
{
// *** Service ADC interrupt
//
// Conversion is initiated by CCP special event trigger,
// every ADCPeriod microseconds
//
PIR1bits.ADIF = 0; // clear interrupt flag
// copy ADC result to display variables
// (to be displayed by Timer0 handler)
dig1 = ADRESH >> 4; // get digit 1 from high nybble of ADRESH
dig2 = ADRESH & 0x0F; // get digit 2 from low nybble of ADRESH
}
}
/***** FUNCTIONS *****/

{
// RA4 = E, RA1:0 = FG
0b010010, // 0
0b000000, // 1
0b010001, // 2
0b000001, // 3
0b000011, // 4
0b000011, // 5
0b010011, // 6
0b000000, // 7
0b010011, // 8
0b000011, // 9
0b010011, // A
0b010011, // b
0b010010, // C
0b010001, // d
0b010011, // E
0b010011 // F
};

// RC4:1 = CDBA
0b011110, // 0
0b010100, // 1
0b001110, // 2
0b011110, // 3
0b010100, // 4
0b011010, // 5
0b011010, // 6
0b010110, // 7
0b011110, // 8
0b011110, // 9
0b010110, // A
0b011000, // b
0b001010, // C
0b011100, // d
0b001010, // E
0b000010 // F
};
// disable displays
LATA = 0; // clear all digit enable lines on PORTA
LATC = 0; // and PORTC
// lookup and output digit pattern

}
Conclusion
This has been a long lesson, but as we’ve seen, the CCP modules’ capture and compare modes are useful in a
number of situations where accurate timing is required, from measuring short input signal periods and pulse
widths, to driving precisely-timed output changes, and in generating regular interrupts and analog-to-digital
conversions with an arbitrary period.
You may not need to use these capabilities every day, but when you do, you’ll be glad to have the capture
and compare modes available.
However, the CCP module’s pulse-width modulation (PWM) modes, are arguably more commonly used,
providing (in conjunction with filtering) a form of analog output, especially useful for applications such as
light dimming and motor control, as we’ll see in the next lesson.

Osmeoisis 2022-09-06 15-33-19PIC - Enh - C - 14

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Osmeoisis 2022-09-06 15-33-19PIC - Enh - C - 14

Uploaded by

Copyright:

Available Formats

© Gooligum Electronics 2015 www.gooligum.com.

Introduction to PIC Programming

by David Meiklejohn, Gooligum Electronics

Lesson 14: CCP, part 1 - Capture and Compare

PIC16F1824 (E)CCP Modules

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0

The available capture events, and the

Example 1: Period measurement using capture mode

To measure time, we need a timer, incrementing at a steady, known rate.

So first, we configure the device to use the internal RC oscillator, as usual:

We then select the 16 MHz clock (see lesson 7):

Now we need to calculate and display the period.

the period calculation is simply:

(using the 7-segment display function developed in lesson 10)

Thus, to calculate the period, scale and display it, we have:

/***** CONFIGURATION *****/

/***** PROTOTYPES *****/

/***** MAIN PROGRAM *****/

/*** Initialisation ***/

// configure ECCP1 module

/*** Main loop ***/

// wait for capture event

// calculate and display scaled period

// save current capture time for next period

/***** FUNCTIONS *****/

/***** Display digit on 7-segment display *****/

// pattern table for 7 segment display on port C

Example 2: Pulse width measurement using capture mode

// wait for rising edge (pulse start)

// save capture value at pulse start

// wait for falling edge (pulse end)

// calculate and display scaled width

Example 3: Period measurement using capture mode interrupts

But of course, we want to implement this using interrupts!

and of course peripheral and global interrupts, as usual:

However, we do need to be careful here.

/***** CONFIGURATION *****/

/***** PROTOTYPES *****/

/***** GLOBAL VARIABLES *****/

/***** MAIN PROGRAM *****/

/*** Initialisation ***/

// configure ECCP1 module

/*** Main loop ***/

// display scaled period

/***** INTERRUPT SERVICE ROUTINE *****/

//*** Service CCP1 interrupt

// save current capture time for next period

/***** FUNCTIONS *****/

/***** Display digit on 7-segment display *****/

// pattern table for 7 segment display on port C

Example 4: Using compare mode to flash an LED

To make the CCP2 output visible, we can connect an LED to

If you have the Gooligum training board, close jumper JP19

Following a power-on reset, each CCPx output is initially low.

At this point, we know that the CCP2 output has toggled.

Our main loop is then simply:

// wait for CCP match

// add 0.5 sec to last compare time

// configure ECCP2 to set CCP2 when compare time reached

/* CONFIGURATION */

/* PROTOTYPES */

/* MAIN PROGRAM */

/* Initialisation */

/* Main loop */

/* FUNCTIONS */

/* Display digit on 7-segment display */

/* CONFIGURATION */

/* PROTOTYPES */

/* GLOBAL VARIABLES */

/* MAIN PROGRAM */

/* Initialisation */

/* Main loop */

/* INTERRUPT SERVICE ROUTINE */

/* FUNCTIONS */

/* Display digit on 7-segment display */

/* CONFIGURATION */

/* MAIN PROGRAM */

/* Main loop */

/* CONFIGURATION */

/* CONSTANTS */

/* MAIN PROGRAM */

/* Initialisation */

/* Main loop */

/* INTERRUPT SERVICE ROUTINE */

/* CONFIGURATION */

/* CONSTANTS */

/* PROTOTYPES */

/* MAIN PROGRAM */

/* Main loop */

/* INTERRUPT SERVICE ROUTINE */

/* FUNCTIONS */

/* Display digit on 7-segment display */