• AVR Freaks

AnsweredDifference between capture and compare modes with examples

Page: << < ..678910.. > >> Showing page 6 of 13
Author
DougRice
Super Member
  • Total Posts : 533
  • Reward points : 0
  • Joined: 2008/10/08 23:44:59
  • Location: 0
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/20 14:55:18 (permalink)
+1 (1)
The capture mode captures TMR1, which is clocked.
 
( It must be synchronised to Fosc to prevent race conditions in the values sampled. )
I was using the 16F683, which only has 8 pins.
 
The count in TMR1 is the integral of the frequency of its clock. Frequency is Cycles per second. 
TMR can be clocked from Fosc or from Pin2. 
 
You could count pulse by doing a capture. You could clock TMR with just 10 pulses, then doing a capture again.
By subtracting the current capture with the last capture you can work out how may pulses clocked TMR1. 
 
You could measure the frequency of the external clock on Pin2 , by clocking the CCP input on Pin5 with a constant frequency.
You can measure the period of the frequency clocking CCP on Pin5 by subtracting the previous capture from latest capture.
 
In compare mode, you could get accurate timings by incrementing CCPR by the time required. The output pulses would be separated by the increment divided by the frequency clocking  TMR1. Worth a try sometime.
JorgeF
Super Member
  • Total Posts : 3340
  • Reward points : 0
  • Joined: 2011/07/09 11:56:58
  • Location: PT/EU @ Third rock from the Sun
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/20 15:00:40 (permalink)
0
Hi
 
Several posts ago the OP mentioned that he is only using the simulator and looked like he has some doubts if the real hardware performed exactly the same.
Attached is an example of what happens in the real hardware.
I used a PIC18F8722, is not the same the OP is using, but the CCP and Timer modules are.
The program code is the example 1and0 posted.
 
The configuration of the timer, CCP and oscillator are

// Use CCP5 pin is RG4 set timer3 for all (E)CCP peripherals
// Timer 3 config
// = T3CON =
// 1--- ---- Timer 3 read/write in 16 bits mode
// -1-- 1--- Timers 3/4 for all (E)CCP modules
// --00 ---- T3 clock pre-scaller ratio 1:1
// ---- -x-- T3 clock synch don't care - clock is Fosc/4
// ---- --0- T3 clock is instruction clock (Fosc/4)
// ---- ---0 T3 is Off
#define T3CON_INIT 0xc8
 
// CCP 5 config - compare mode for Low to High and High to Low transitions on CCP5 output pin
// = CCP5CON =
// xx-- ----- not implemented (don't care))
// --xx ----- duty cycle low bits only for PWM (don't care))
// ---- 1000 Compare mode CCP5 pin transition low to high on match
// ---- 1001 Compare mode CCP5 pin transition high to low on match
#define CCP5CON_COMPARE_LH 0x08
#define CCP5CON_COMPARE_HL 0x09
#define CCPR5_INIT 0x0100
#define CCPR5H_INIT 0x01
#define CCPR5L_INIT 0x00
 
// Oscillator config
// = OSCCON =
// 0--- ---- IDLEN - Not sleeping
// -110 ---- Fosc internal 4MHZ
// ---- xx-- Read only (don't care)
// ---- --1x Fosc is from internal oscillator block
#define OSCCON_INIT 0x62

 
EDIT: Typos
post edited by JorgeF - 2018/07/20 15:43:08

Attached Image(s)


Best regards
Jorge
 
I'm here http://picforum.ric323.com too!
And it works better....
eagle1
Super Member
  • Total Posts : 341
  • Reward points : 0
  • Joined: 2014/11/02 03:04:06
  • Location: Saudi Arabia
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/20 15:53:14 (permalink)
0
JorgeF
The first line "CCP1CON = 0x08" sets the start mode, its necessary because the CCP must be configured before you start the Timer.
Inside the while(1) loop the mode alternates between 0x08 and 0x09 in order to generate a correct square wave, that is why upon program start you see a duplicate "CCP1CON = 0x08. If you look at the "while(1)" loop there are no duplicates. 

Yes, I know it's logically not a duplicate, since entering the "while" loop there are only the two necessary CCP1CON configurations. But the one before the "while" I thought about it in terms of the sequencing of the program.
 
You say "CCP must be configured before you start the Timer", this could be a an important point, but I removed the first "CCP1CON = 0x08" before entering the while loop, and as I mentioned the result didn't changed.
 
I think that when I first start the timer before configuring the CCP to compare mode, that the timer starts counting, and then when the code enters the while loop and execute the first line which is "CCP1CON = 0x08", what I guess happens is that the timer continue to count until it catches the value in the CCPR1.
 
But you're right, because if the value in the CCPR1 is very small; e.g. CCPR1=0x0001, then the timer should miss the event! Yes MR 1and0 & JorgeF, you're all right it's just take me time to understand the little details.
 
Yes, the CCP must be configured before entering the loop, the last thing before the loop is turning on the timer.
 
OK, now I understand this part very good and now I have a very good background about how important the timing of the code.
 

What is intended is to generate a match event every 256 clocks.
In order to let the Timer run free so there are no lost clocks, we advance the match count to the next 256 interval.
This way we have match events at every 256 counts (256, 512, 768, .....) without interfering with the timer count.
 
The high byte (CCPR1H) its because 256 = 0x0100, so we skip adding 0x00 to the low byte and just add 0x01 to the high byte.
 



Hmmm ok, yes. I was thinking of that way I was doing in my inefficient code earlier, I kept loading the CCPR1 with 0x0ff which is in assembly at least two instruction cycles, oh wait! it's 4 instruction cycles.
 

movlw 0xff
mowf CCPR1L, F
movlw 0x00
movwf CCPR1H, F

Oh yeah that's a degrading in the code efficiency. 
 
Incrementing the CCPR1H is only 1 instruction:

incf CCPR1H, F

post edited by eagle1 - 2018/07/20 16:15:33
JorgeF
Super Member
  • Total Posts : 3340
  • Reward points : 0
  • Joined: 2011/07/09 11:56:58
  • Location: PT/EU @ Third rock from the Sun
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/20 16:19:13 (permalink)
0
Hi
eagle1
You say "CCP must be configured before you start the Timer", this could be a an important point, but I removed the first "CCP1CON = 0x08" before entering the while loop, and as I mentioned the result didn't changed.
I think that when I first start the timer before configuring the CCP to compare mode, that the timer starts counting, and then when the code enters the while loop and execute the first line which is "CCP1CON = 0x08", what I guess happens is that the timer continue to count until it catches the value in the CCPR1.

Yes, in this specific example it makes no difference. But the CCP module only gets control of the CCP pin after beeing configured, so if you want to make sure things start as they should its better to configure before starting.
Its also a question of good practices, allways have things (peripherals, variables, ...) fully configured before start using them.
eagle1
But you're right, because if the value in the CCPR1 is very small; e.g. CCPR1=0x0001, then the timer should miss the event! Yes MR 1and0 & JorgeF, you're all right it's just take me time to understand the little details.

A value of "1" in the CCPR will only work if the timer was clocked from a very slow external source. Very slow when compared to the instruction clock (Fosc/4) of the PIC.
Bear in mind that this examples are not use cases of a real world application.
In a real application the PIC needs to handle a number of different tasks so a compare count must be large enought to give time for the PIC to run a lot more code than in this usage examples.
In this example, you might be able to have things working with a CCPR value as low as 30, but if in a real world application your maths result in such a small CCPR value with the Timer clocked internally, its time to use a faster clock.
eagle1
Incrementing the CCPR1H is only 1 instruction:

incf CCPR1H, F 


For this kind of examples we get to choose nice round values like 256, but its not the case in a real world application, with a different interval we would need a full 16 bit add that takes a few more instructions.
 
 
 
 
post edited by JorgeF - 2018/07/20 16:26:18

Best regards
Jorge
 
I'm here http://picforum.ric323.com too!
And it works better....
eagle1
Super Member
  • Total Posts : 341
  • Reward points : 0
  • Joined: 2014/11/02 03:04:06
  • Location: Saudi Arabia
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/20 21:36:48 (permalink)
0
JorgeF
Yes, in this specific example it makes no difference. But the CCP module only gets control of the CCP pin after beeing configured, so if you want to make sure things start as they should its better to configure before starting.
Its also a question of good practices, allways have things (peripherals, variables, ...) fully configured before start using them.

Yes, absolutely!
 

A value of "1" in the CCPR will only work if the timer was clocked from a very slow external source. Very slow when compared to the instruction clock (Fosc/4) of the PIC.
That's interesting to know that the PIC MCU won't catch a compare value if the registered value is 0x0001 with oscillator clocks of, e.g. 4 MHz and timer prescaler even with 1:8, so that is:
Timer input = Fosc/4*1/8 = 1MHz/8 = 125KHz, so does this still a high speed for the timer to catch the 1st count of the CCPR1 value? How to know these limits of knowing that a timer could catch something?
 

Bear in mind that this examples are not use cases of a real world application.
In a real application the PIC needs to handle a number of different tasks so a compare count must be large enough to give time for the PIC to run a lot more code than in this usage examples.

Yes, but what about interrupts because I learned that interrupts work in the background, so if the compare match is set then the program stops to process the ISR. Of course this when the MCU has a big program to process, but interrupts work on peripherals without CPU processing operations. 
 
Also, I'm thinking this morning about the application in real world, what could be for example?
I thought of a specific principle application, in two situations:
1. When the timer is driven from internal or external synchronous clock, in this situation, the timer constantly continues to count up until it get the specified value in CCPR1 register.
>> just looked into google for information but there's no information about projects or websites explaining different applications for compare mode. But I would say; for example, home appliances like a washing machine when specific time pass of the program the MCU forces to stop the washing motor. Or the microwave, when the time pass the process of heating finishes and the MCU forces the microwave generator to stop. Another example, timing of movable parts like robots, in industry, when robots move in specific distances so that movement is determined by specific time to reach certain distance. Or when the robot must activate a specific part when it's in certain status and that status activates the timer and if nothing interrupts the timer and the time passes, then compare mode triggers and force certain action >> as the robot battles on YouTube :) This is what I could think of.
 
Also I think it's similar to Watchdog timer, the difference is that the Watchdog timer resets the MCU, and the compare mode forces a pin to go high or low. I'm thinking also if the compare mode could be applied in emergency applications? But couldn't  think of some examples.
 
2. When the timer is driven from external asynchronous clock, examples I could think about; like, when certain triggers counts on the timer input reach the value in the CCPR1 register, it forces a pin to go high or low.
 

In this example, you might be able to have things working with a CCPR value as low as 30, but if in a real world application your maths result in such a small CCPR value with the Timer clocked internally, its time to use a faster clock.
I didn't understand this completely. Do you mean that low internal clock speeds aren't fast enough to catch a value of 0x0001 in CCPR1? 
 

For this kind of examples we get to choose nice round values like 256, but its not the case in a real world application, with a different interval we would need a full 16 bit add that takes a few more instructions.
Yes this example has easy value to manipulate.


So with different values, the CCPR1 in case of variable values exceed 8-bit. There should be the process I posted in #103, that 16-bits value should take at least 4 instruction cycles.
post edited by eagle1 - 2018/07/20 21:47:12
qɥb
Monolothic Member
  • Total Posts : 3332
  • Reward points : 0
  • Joined: 2017/09/09 05:07:30
  • Location: Jupiter
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/20 21:48:59 (permalink) ☄ Helpfulby eagle1 2018/07/20 22:26:40
+1 (1)
eagle1
...

A value of "1" in the CCPR will only work if the timer was clocked from a very slow external source. Very slow when compared to the instruction clock (Fosc/4) of the PIC.
That's interesting to know that the PIC MCU won't catch a compare value if the registered value is 0x0001 with oscillator clocks of, e.g. 4 MHz and timer prescaler even with 1:8, so that is:
Timer input = Fosc/4*1/8 = 1MHz/8 = 125KHz, so does this still a high speed for the timer to catch the 1st count of the CCPR1 value? How to know these limits of knowing that a timer could catch something?

The hardware WILL catch the compare, so long as the compare register has been written with the new value before the timer gets there.
e.g. if you start the timer, then initialise the CCP peripheral, the timer will have counted past "1" before you have finished initialising the CCP, so it will have to count all the way up to 0xFFFF and back to zero before it gets to 1 again.
Similarly, if you are using the technique of just adding an offset to the CCPR value to get the next count, the amount you add must be more than the number of cycles it takes for your code to run to do it, otherwise again the timer will wrap all the way around again before a match occurs.
 


Bear in mind that this examples are not use cases of a real world application.
In a real application the PIC needs to handle a number of different tasks so a compare count must be large enough to give time for the PIC to run a lot more code than in this usage examples.

Yes, but what about interrupts because I learned that interrupts work in the background, so if the compare match is set then the program stops to process the ISR. Of course this when the MCU has a big program to process, but interrupts work on peripherals without CPU processing operations.

Interrupts only "run in the background" in the sense that they stop your main code running while they run, then let the main code continue when they are done.
You do NOT get extra processing power using interrupts. Code takes just as long to run on main code as it does in an interrupt.
 

 

Also, I'm thinking this morning about the application in real world, what could be for example?
I thought of a specific principle application, in two situations:
1. When the timer is driven from internal or external synchronous clock, in this situation, the timer constantly continues to count up until it get the specified value in CCPR1 register.
>> just looked into google for information but there's no information about projects or websites explaining different applications for compare mode. But I would say; for example, home appliances like a washing machine when specific time pass of the program the MCU forces to stop the washing motor. Or the microwave, when the time pass the process of heating finishes and the MCU forces the microwave generator to stop. Another example, timing of movable parts like robots, in industry, when robots move in specific distances so that movement is determined by specific time to reach certain distance. Or when the robot must activate a specific part when it's in certain status and that status activates the timer and if nothing interrupts the timer and the time passes, then compare mode triggers and force certain action >> as the robot battles on YouTube :) This is what I could think of.

None of those applications require timing as precise as you can get with compare mode.
Something higher speed, like generating a precise waveform for controlling a spinning motor would be more applicable.
 
 


In this example, you might be able to have things working with a CCPR value as low as 30, but if in a real world application your maths result in such a small CCPR value with the Timer clocked internally, its time to use a faster clock.
I didn't understand this completely. Do you mean that low internal clock speeds aren't fast enough to catch a value of 0x0001 in CCPR1?

The Hardware will always catch the match IF IT OCCURS.
Refer back to my previous answer about how long your code takes to reload the CCPR1 etc.
 


For this kind of examples we get to choose nice round values like 256, but its not the case in a real world application, with a different interval we would need a full 16 bit add that takes a few more instructions.
Yes this example has easy value to manipulate.


So with different values, the CCPR1 in case of variable values exceed 8-bit. There should be the process I posted in #103, that 16-bits value should take at least 4 instruction cycles.

You would normally always be loading 16 bits into CCPR1.
It's tricks like just setting the top bit to add 0x8000 that you can't do with real world numbers.

This forum is mis-configured so it only works correctly if you access it via https protocol.
The Microchip website links to it using http protocol. Will they ever catch on?
PicForum "it just works"
eagle1
Super Member
  • Total Posts : 341
  • Reward points : 0
  • Joined: 2014/11/02 03:04:06
  • Location: Saudi Arabia
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/20 22:26:12 (permalink)
0
qɥb
The hardware WILL catch the compare, so long as the compare register has been written with the new value before the timer gets there.
No matter the speed of the timer? I think maybe I'm not sure, that the speed won't affect the counting of the timer as long as I configured the CCP and loaded the value before turning on the timer.
 
e.g. if you start the timer, then initialise the CCP peripheral, the timer will have counted past "1" before you have finished initialising the CCP, so it will have to count all the way up to 0xFFFF and back to zero before it gets to 1 again.

Absolutely, I learned this arrangement when dealing with the timer the CCP modules, and also for other peripherals. But the timing here in the compare is very important.
 
Similarly, if you are using the technique of just adding an offset to the CCPR value to get the next count, the amount you add must be more than the number of cycles it takes for your code to run to do it, otherwise again the timer will wrap all the way around again before a match occurs.
I tried something like this, I wanted the timer to wrap around with this code, but didn't work:
 

while (1) { 
    while(PIR1bits.CCP1IF==0); // when the flag is set, this line breaks!
    PIR1bits.CCP1IF=0;
    CCP1CONbits.CCP1M0^=1;
}

 

Interrupts only "run in the background" in the sense that they stop your main code running while they run, then let the main code continue when they are done.
You do NOT get extra processing power using interrupts. Code takes just as long to run on main code as it does in an interrupt.
Yes, main program and ISR work in the same speed of the CPU, I learned that ISRs should be so fast not too long functions and should have no delays.
 


None of those applications require timing as precise as you can get with compare mode.
Something higher speed, like generating a precise waveform for controlling a spinning motor would be more applicable.
OK, but shouldn't the PWM is the best to drive motors? I don't know what is the precision level between PWM and compare modes? Which one is the most precise?
 
Another example I thought of is should that be like controlling quadcopter motors with compare mode? But doesn't the PIC18 have enhanced PWM which has the full-bridge feature which can handle 4 outputs?
 
 

The Hardware will always catch the match IF IT OCCURS.
Refer back to my previous answer about how long your code takes to reload the CCPR1 etc.
 
 Do you mean the answer in post #84?

You then never stop or clear the timer register.
You just add the number of timer clocks delays you need to the existing value in CCPR1,
and toggle bit 0 of the CCPM value in CCP1CON.
 
But doesn't adding numbers of 16-bit to the CCPR1 register would take like 4 instruction cycles? This is the same point I'm concerning of in the last part of this reply.
 

You would normally always be loading 16 bits into CCPR1.
It's tricks like just setting the top bit to add 0x8000 that you can't do with real world numbers.
OK, you got to an important point here, in case of real world numbers, how you should be able to get precise outputs like the one you did earlier?
qɥb
Monolothic Member
  • Total Posts : 3332
  • Reward points : 0
  • Joined: 2017/09/09 05:07:30
  • Location: Jupiter
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/20 22:44:53 (permalink)
+2 (2)
eagle1
qɥb
The hardware WILL catch the compare, so long as the compare register has been written with the new value before the timer gets there.
No matter the speed of the timer? I think maybe I'm not sure, that the speed won't affect the counting of the timer as long as I configured the CCP and loaded the value before turning on the timer.

The CCP will always catch the compare match.
The question is if your software is quick enough to react the the match having happened.
 
I tried something like this, I wanted the timer to wrap around with this code, but didn't work:

while (1) {
    while(PIR1bits.CCP1IF==0); // when the flag is set, this line breaks!
    PIR1bits.CCP1IF=0;
    CCP1CONbits.CCP1M0^=1;
}

What does "didn't work" mean?
Because it is not updating the CCPR1 value, this code will only generate a match one per timer rollover.
I would expect the CCP output pin to be toggling with a period of double the time it takes the timer to roll over.
 


Interrupts only "run in the background" in the sense that they stop your main code running while they run, then let the main code continue when they are done.
You do NOT get extra processing power using interrupts. Code takes just as long to run on main code as it does in an interrupt.
Yes, main program and ISR work in the same speed of the CPU, I learned that ISRs should be so fast not too long functions and should have no delays.

 Agreed.


None of those applications require timing as precise as you can get with compare mode.
Something higher speed, like generating a precise waveform for controlling a spinning motor would be more applicable.
OK, but shouldn't the PWM is the best to drive motors? I don't know what is the precision level between PWM and compare modes? Which one is the most precise?

PWM is precise, but limited in that you only have eight bit resolution, or even less if the period is not an exact fraction of the timer frequency. i.e. if you have ot set PR2 to a value less than 0xFF to get the required period, then you reduce the resolution of the PWM.
 
I really think you are "jumping the gun" by trying to thjink of a use for a peripheral.
It's much more natural to have an existing requirement, then evaluate which peripheral can satisfy that requirement the best.
 


The Hardware will always catch the match IF IT OCCURS.
Refer back to my previous answer about how long your code takes to reload the CCPR1 etc.
 
 Do you mean the answer in post #84?

No, I was just referring back to earlier in my same post.
 


You then never stop or clear the timer register.
You just add the number of timer clocks delays you need to the existing value in CCPR1,
and toggle bit 0 of the CCPM value in CCP1CON.
 
But doesn't adding numbers of 16-bit to the CCPR1 register would take like 4 instruction cycles? This is the same point I'm concerning of in the last part of this reply.

Yes. We're all trying to tell you that you shouldn't be trying to get pulse widths so narrow that four instruction cycles is too many.
 


You would normally always be loading 16 bits into CCPR1.
It's tricks like just setting the top bit to add 0x8000 that you can't do with real world numbers.
OK, you got to an important point here, in case of real world numbers, how you should be able to get precise outputs like the one you did earlier?

You would add the required offset to the CCPR1 register.
That can be done in four instruction cycles.

This forum is mis-configured so it only works correctly if you access it via https protocol.
The Microchip website links to it using http protocol. Will they ever catch on?
PicForum "it just works"
eagle1
Super Member
  • Total Posts : 341
  • Reward points : 0
  • Joined: 2014/11/02 03:04:06
  • Location: Saudi Arabia
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/20 23:04:05 (permalink)
0
qɥb
What does "didn't work" mean?

Sorry didn't explain my goal, I expected it to:
1. Count to 256, then the pin is high.
2. The flag is set, then the next line resets it.
3. After that it toggles the compare mode for driving the pin from high to low.
4. The timer continues to count until it wrap around and start counting again from 0, until it reaches 256.
5. Where it's now in the high to low mode, the flag is set, so the pin should go from high to low.
 
Because it is not updating the CCPR1 value, this code will only generate a match one per timer rollover.
I would expect the CCP output pin to be toggling with a period of double the time it takes the timer to roll over.
Yes I just wanted to get this result, I wanted to get the pin toggling every timer rollover.
 

PWM is precise, but limited in that you only have eight bit resolution, or even less if the period is not an exact fraction of the timer frequency. i.e. if you have ot set PR2 to a value less than 0xFF to get the required period, then you reduce the resolution of the PWM.

 
I really think you are "jumping the gun" by trying to thjink of a use for a peripheral.
It's much more natural to have an existing requirement, then evaluate which peripheral can satisfy that requirement the best.
I think that too, I'm not working on a serious application where I want to get trigger events or precise timings, I'm investigating the CCP modules :) My projects now are working with modules; like, gyroscope, HMC5883L module ... etc. Beside, developing my libraries of UART and I2C from polling version to applying interrupts ISRs.
qɥb
Monolothic Member
  • Total Posts : 3332
  • Reward points : 0
  • Joined: 2017/09/09 05:07:30
  • Location: Jupiter
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/20 23:30:04 (permalink)
0
eagle1
qɥb
What does "didn't work" mean?

Sorry didn't explain my goal, I expected it to:
1. Count to 256, then the pin is high.
2. The flag is set, then the next line resets it.
3. After that it toggles the compare mode for driving the pin from high to low.
4. The timer continues to count until it wrap around and start counting again from 0, until it reaches 256.
5. Where it's now in the high to low mode, the flag is set, so the pin should go from high to low.
 

Yes, that's also what I expected it to do.
What did it do?
 

This forum is mis-configured so it only works correctly if you access it via https protocol.
The Microchip website links to it using http protocol. Will they ever catch on?
PicForum "it just works"
PStechPaul
Super Member
  • Total Posts : 2381
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/21 00:31:21 (permalink) ☄ Helpfulby eagle1 2018/07/21 01:53:32
+1 (1)
I've been trying to conceive of an application that would need to make use of the CCP compare mode, that would not be better done with PWM. So here is a possibility. Imagine something like a laser that needs to produce a very accurate short duration pulse when a manual trigger is actuated. The delay from the trigger to the pulse is not critical, as long as it is quick enough not to cause a noticeable delay (perhaps 100 mSec max), but the duration of the pulse must be adjustable from, say, 50-250 uSec, to within 1 uSec.
 
Assume that the PIC is running at 4 MHz so the instruction clock is 1 MHz, and that is used for TMR1. It will roll over every 65.536 mSec. So, you could use CCP1 to start the laser output, and CCP2 to stop it, by using appropriate logic on the CCP pins. For 100 uSec, you can set CCP1CON to 10,000 and CCP2CON to 10,100. Have the CCP pins configured so that the laser is energized when CCP1 is high and CCP2 is low, and they are initialized to low. When the trigger is actuated, it causes the TMR1 to start running from zero. When its value reaches CCP1CON, the CCP1 pin goes high, and the laser turns on. When it reaches CCP2CON, after exactly 100 uSec, CCP2 pin goes high, turning off the laser. This also disables TMR1 as well as the CCP modules, allowing the user to adjust the time duration for the next pulse, which will not happen until the trigger is released and pressed again.
 
For most purposes, the CCP compare module may not be needed, but it's a bit like porn in the sense that you may not easily define it, but you will know (when you need) it when you see it.

 
eagle1
Super Member
  • Total Posts : 341
  • Reward points : 0
  • Joined: 2014/11/02 03:04:06
  • Location: Saudi Arabia
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/21 02:16:32 (permalink)
0
qɥb
Yes, that's also what I expected it to do.
What did it do?

When the pin goes high, it doesn't go low again.
The simulator hangs in the while loop.
I have to force the simulator cursor to pass the while loop.
 
PStechPaul
I've been trying to conceive of an application that would need to make use of the CCP compare mode, that would not be better done with PWM. So here is a possibility. Imagine something like a laser that needs to produce a very accurate short duration pulse when a manual trigger is actuated. The delay from the trigger to the pulse is not critical, as long as it is quick enough not to cause a noticeable delay (perhaps 100 mSec max), but the duration of the pulse must be adjustable from, say, 50-250 uSec, to within 1 uSec.
 
Assume that the PIC is running at 4 MHz so the instruction clock is 1 MHz, and that is used for TMR1. It will roll over every 65.536 mSec. So, you could use CCP1 to start the laser output, and CCP2 to stop it, by using appropriate logic on the CCP pins. For 100 uSec, you can set CCP1CON to 10,000 and CCP2CON to 10,100. Have the CCP pins configured so that the laser is energized when CCP1 is high and CCP2 is low, and they are initialized to low. When the trigger is actuated, it causes the TMR1 to start running from zero. When its value reaches CCP1CON, the CCP1 pin goes high, and the laser turns on. When it reaches CCP2CON, after exactly 100 uSec, CCP2 pin goes high, turning off the laser. This also disables TMR1 as well as the CCP modules, allowing the user to adjust the time duration for the next pulse, which will not happen until the trigger is released and pressed again.
 
For most purposes, the CCP compare module may not be needed, but it's a bit like porn in the sense that you may not easily define it, but you will know (when you need) it when you see it.

You're right, I think the point of the example is not like PWM for constant wave output, but it's like controlling the timing of a specific output to force the pin high or low depending on the trigger for internal or external timer clock input.
 
It's like driving a pin high or low when something triggers an event and a delay has to pass until the timer reaches the compare value and then force the pin high or low.
 
But you're right I don't think of an application to use the compare mode right now, the project which now I can think of the use the CCP module is the capture mode to decode the remote control codes.
qɥb
Monolothic Member
  • Total Posts : 3332
  • Reward points : 0
  • Joined: 2017/09/09 05:07:30
  • Location: Jupiter
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/21 02:56:10 (permalink) ☄ Helpfulby eagle1 2018/07/22 04:36:25
+2 (2)
eagle1
qɥb
Yes, that's also what I expected it to do.
What did it do?

When the pin goes high, it doesn't go low again.
The simulator hangs in the while loop.
I have to force the simulator cursor to pass the while loop.
 ...

Don't put 100% faith in the simulator.
I'd be trying this on real hardware before assuming it didn't work.

This forum is mis-configured so it only works correctly if you access it via https protocol.
The Microchip website links to it using http protocol. Will they ever catch on?
PicForum "it just works"
JorgeF
Super Member
  • Total Posts : 3340
  • Reward points : 0
  • Joined: 2011/07/09 11:56:58
  • Location: PT/EU @ Third rock from the Sun
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/21 05:25:04 (permalink)
+1 (1)
Hi
qɥb
eagle1
qɥb
What does "didn't work" mean?

Sorry didn't explain my goal, I expected it to:
1. Count to 256, then the pin is high.
2. The flag is set, then the next line resets it.
3. After that it toggles the compare mode for driving the pin from high to low.
4. The timer continues to count until it wrap around and start counting again from 0, until it reaches 256.
5. Where it's now in the high to low mode, the flag is set, so the pin should go from high to low.
 

Yes, that's also what I expected it to do.
What did it do?

Guys, the compare mode works with a 16bit counter.
Rollover will take 65536 clocks.
 
 
Sorry, silly point.
This time was my turn to pay less attention while reading.
post edited by JorgeF - 2018/07/21 05:28:27

Best regards
Jorge
 
I'm here http://picforum.ric323.com too!
And it works better....
1and0
Access is Denied
  • Total Posts : 9631
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/21 06:25:39 (permalink) ☄ Helpfulby eagle1 2018/07/22 04:37:50
+1 (1)
Some more uses of the Compare Mode:
  • 16-bit timer and 16-bit period registers (TMRx and CCPRx, respectively)
  • generate slow PWM waveforms
  • transmit pulse train such as RC5/SIRC protocol *
and I've read it can be used for phase detect, measurement, triac control, etc.
 
* Since remote control codes have been discussed in this thread, the Compare Mode can also be used to encode and transmit RC5 and SIRC codes, while the Capture Mode can be used to receive and decode them.
post edited by 1and0 - 2018/07/21 06:31:41
JorgeF
Super Member
  • Total Posts : 3340
  • Reward points : 0
  • Joined: 2011/07/09 11:56:58
  • Location: PT/EU @ Third rock from the Sun
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/21 06:31:08 (permalink) ☄ Helpfulby eagle1 2018/07/22 04:38:40
+1 (1)
Hi
 
Maybe my previous post wasn't that silly.
The OP is using the simulator logic analyzer, so the question is if the trace buffer is big enought to show him the level at the output pin for the 64K+ instruction cycles needed for the timer rollover.
 
As for use cases of the CCP in compare mode.
A few years ago, I saw in some PIC related forum, a guy claiming to having been able to generate the signals to control up to 8 R/C servos using a single CCP module in compare mode.
 

Best regards
Jorge
 
I'm here http://picforum.ric323.com too!
And it works better....
1and0
Access is Denied
  • Total Posts : 9631
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/21 06:36:14 (permalink)
+1 (1)
JorgeF
Maybe my previous post wasn't that silly.
The OP is using the simulator logic analyzer, so the question is if the trace buffer is big enought to show him the level at the output pin for the 64K+ instruction cycles needed for the timer rollover.

Probably not, but I'd expect the trace line to toggle high and low if a breakpoint is placed on the CCPIF=0 line.
 
 
As for use cases of the CCP in compare mode.
A few years ago, I saw in some PIC related forum, a guy claiming to having been able to generate the signals to control up to 8 R/C servos using a single CCP module in compare mode.

I also seems to recall something like that. ;)
 
post edited by 1and0 - 2018/07/21 06:38:45
JorgeF
Super Member
  • Total Posts : 3340
  • Reward points : 0
  • Joined: 2011/07/09 11:56:58
  • Location: PT/EU @ Third rock from the Sun
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/21 06:47:04 (permalink)
0
Hi
eagle1

A value of "1" in the CCPR will only work if the timer was clocked from a very slow external source. Very slow when compared to the instruction clock (Fosc/4) of the PIC.
That's interesting to know that the PIC MCU won't catch a compare value if the registered value is 0x0001 with oscillator clocks of, e.g. 4 MHz and timer prescaler even with 1:8, so that is:
Timer input = Fosc/4*1/8 = 1MHz/8 = 125KHz, so does this still a high speed for the timer to catch the 1st count of the CCPR1 value? How to know these limits of knowing that a timer could catch something?

This is a widder question.
The events generated by the PIC peripherals, CCP and others, can't be so frequent that they chocke the mcu.
Either using interrupts or poling in the main loop, this events must leave time for the processor to execute all the code it needs to handle them plus the the main program flow.
 
Using interrupts adds something more than the simple handling of the event, it also involves branching to a subroutine and back, plus context saving and restoring.
post edited by JorgeF - 2018/07/21 11:06:06

Best regards
Jorge
 
I'm here http://picforum.ric323.com too!
And it works better....
JorgeF
Super Member
  • Total Posts : 3340
  • Reward points : 0
  • Joined: 2011/07/09 11:56:58
  • Location: PT/EU @ Third rock from the Sun
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/21 11:11:11 (permalink)
+1 (1)
Hi
1and0
JorgeF
Maybe my previous post wasn't that silly.
The OP is using the simulator logic analyzer, so the question is if the trace buffer is big enought to show him the level at the output pin for the 64K+ instruction cycles needed for the timer rollover.

Probably not, but I'd expect the trace line to toggle high and low if a breakpoint is placed on the CCPIF=0 line.
 



I'm quite sure it wouldn't.
The logic analyzer on MPLAB just draws a graphic line of the data in the trace buffer.
It may or may show the state at the time of a brekpoint if that data is in the trace buffer.
The trace buffer stops recording when full, but the program keeps running.
 

Best regards
Jorge
 
I'm here http://picforum.ric323.com too!
And it works better....
1and0
Access is Denied
  • Total Posts : 9631
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: I want to know the difference between capture and compare modes with examples 2018/07/21 23:03:08 (permalink)
+1 (1)
JorgeF
The logic analyzer on MPLAB just draws a graphic line of the data in the trace buffer.
It may or may show the state at the time of a brekpoint if that data is in the trace buffer.
The trace buffer stops recording when full, but the program keeps running.

Tested with the MPLAB 8.92 Simulator just now and the CCP graphic line does toggle at the breakpoint.
 
Page: << < ..678910.. > >> Showing page 6 of 13
Jump to:
© 2019 APG vNext Commercial Version 4.5