p16F88x CCP+1 perif

Hello,
Quick question : is it normal to have CCP+1 in p16F88x_perif.xml :

 ccpunit name="CCP+1" type="00" configregsA="CCP1CON"
                       ccpreg="CCPR1L,CCPR1H"
                       pin="PORTC2"
                       interrupt="CCP1"

ccpunit name="CCP2"  type="00" configregsA="CCP2CON"
                       ccpreg="CCPR2L,CCPR2H"
                       pin="PORTC1"
                       interrupt="CCP2"

 

Not sure why it is not simply CCP1 (and if it matters anyway - I don't think so  :-)

CCP+ is enhanced CCP, it has some extra functionalities.

Ah ok - thanks for the precision with this pic.
Regarding the 12F683 :
I am not too confident here, but it seems to me that when enabling compare mode in CCP1CON : for example with CCP1M<3:0> 1010
=> Compare mode, generate software interrupt on match (CCP1IF bit is set, CCP1 pin is unaffected)

then in SimulIDE:
1) GP2 is still controlled by CCP1 and not GPIO (can't toggle the output)
2) We are not able to clear the CCP1IF flag...

Datasheet for 12F683 says :
- All Compare modes can generate an interrupt.
- When Generate Software Interrupt mode is chosen (CCP1M<3:0> = 1010), the CCP1 module does not assert control of the CCP1 pin (see the CCP1CON register) [which is GP2 for 12F683].

See files attached.

The code works in real life ; so maybe there is a typo somewhere in the pic xml files, but I triple checked and could not spot the fault.
Probably need new ---> indeed - see below post...

Hum... cheecky...

void PicOcUnit::configure( uint8_t CCPxM )  // CCPxM0,CCPxM1,CCPxM2,CCPxM3
{
   m_specEvent = false;

   if( m_enhanced && CCPxM == 2 ) setOcActs( ocTOG, ocNON ); // Toggle OC Pin
   else{
       switch( CCPxM ) {
           case 8: setOcActs( ocSET, ocCLR ); break; // Set OC Pin
           case 9: setOcActs( ocCLR, ocSET ); break; // Clear OC Pin
           //case 10:                                  // Only interrupt <--- what should happen to GP2 then ? controlled by GPIO or CCP ?
           case 11: m_specEvent = true;                // Special event
       }
   }

Also note you can also toggle OC pin on PIC12F683 - though the datasheet of this PIC is ambivalous :
https://microchipdeveloper.com/8bit:ccpcompare
But the 12F683 says the bits (0010) are reserved - but if you set them anyway, it works

Eventually spot the interrupt issue : Error in PIR1 bitmask of p12F683_regs.xml :

register name="PIR1" addr="0x0C" mask=mask="11001001" -> should be "11101111" obviously !!
bits="TMR1IF,TMR2IF,OSFIF,CMIF,0,CCP1IF,ADIF,EEIF"

void PicOcUnit::configure( uint8_t CCPxM ) // CCPxM0,CCPxM1,CCPxM2,CCPxM3
{
m_specEvent = false;

if( m_enhanced && CCPxM == 2 ) setOcActs( ocTOG, ocNON ); // Toggle OC Pin
else{
switch( CCPxM ) {
case 8: setOcActs( ocSET, ocCLR ); break; // Set OC Pin
case 9: setOcActs( ocCLR, ocSET ); break; // Clear OC Pin
//case 10: // Only interrupt <--- what should happen to GP2 then ? controlled by GPIO of CCP ?
case 11: m_specEvent = true; // Special event
}
}

I'm checking this issue right now, and the errror is right there:
Note that m_ocPin control is not released for case 10.

Also note you can also toggle OC pin on PIC12F683 - though the datasheet of this PIC is ambivalous :
https://microchipdeveloper.com/8bit:ccpcompare
But the 12F683 says the bits (0010) are reserved Mad - but if you set them anyway, it works albino

The datasheet is clear to me in this case: Mode 2 is unused.
It is used in "Enhanced CCP" but not in "normal" CCP.


12F683 CCP:




16F88x enhanced CCP:

Eventually spot the interrupt issue : Error in PIR1 bitmask of p12F683_regs.xml :

register name="PIR1" addr="0x0C" mask=mask="11001001" -> should be "11101111" obviously !!
bits="TMR1IF,TMR2IF,OSFIF,CMIF,0,CCP1IF,ADIF,EEIF"

Yes,you are right.
I will correct it in my files as well.

Yes right about this part of the datasheet : but check this one on p77 :

11.2 Compare Mode
In Compare mode, the 16-bit CCPR1 register value is constantly compared against the TMR1 register pair value. When a match occurs, the CCP1 module may:
• Toggle the CCP1 output. <------------- ah ! (fact is it can, i tested this morning)
• Set the CCP1 output.
• Clear the CCP1 output.
• Generate a Special Event Trigger.
• Generate a Software Interrupt.
The action on the pin is based on the value of the CCP1M<3:0> control bits of the CCP1CON register.
All Compare modes can generate an interrupt.

I guess it is preferable to take a safe path and stick to the "reserved" ?

"Note that m_ocPin control is not released for case 10."

It should be no ?

11.2.3 SOFTWARE INTERRUPT MODE
When Generate Software Interrupt mode is chosen (CCP1M<3:0> = 1010), the CCP1 module does not
assert control of the CCP1 pin (see the CCP1CON register).

Yes right about this part of the datasheet : but check this one on p77 :

11.2 Compare Mode
In Compare mode, the 16-bit CCPR1 register value is constantly compared against the TMR1 register pair value. When a match occurs, the CCP1 module may:
• Toggle the CCP1 output. <------------- ah ! (fact is it can, i tested this morning)
• Set the CCP1 output.
• Clear the CCP1 output.
• Generate a Special Event Trigger.
• Generate a Software Interrupt.
The action on the pin is based on the value of the CCP1M<3:0> control bits of the CCP1CON register.
All Compare modes can generate an interrupt.

I guess it is preferable to take a safe path is and stick to the reserved.

Well... Microchip datasheets are known to contain many errors and contradictions. The last thing you can do is trusting their datasheets.
The only thing we can trust is what happens is the real device.

"Note that m_ocPin control is not released for case 10."

It should be no ?

Yes, that is the error, I'm working on it right now.

I noticed that the "Special Event" also does not assert control of the CCP1 pin.

Btw: I see you are watching the source code, can you compile Simulide?

I fixed the control pin issue.
Understanding what exactly your program should do can take me some time.
But this is what I get, is it correct?

Yes exactly that indeed (for a 16MHz mcu I guess) ! Thanks a lot for all you are doing here ; amazing job actually.
Having the possibility to "proof of concept" on a simulator before going to the real world saves a lot of time.

"Btw: I see you are watching the source code, can you compile Simulide?"

Hum - I don't think so right now ; I'll have to look at the tools needed - I am not too familiar in compiling in a Windows environnement, but I can try to find some time to sort this out.

Yes exactly that indeed (for a 16MHz mcu I guess)

Yes, 16 MHz.
So, this is solved at Rev 1344.

"Btw: I see you are watching the source code, can you compile Simulide?"

Hum - I don't think so right now ; I'll have to look at the tools needed - I am not too familiar in compiling in a Windows environnement, but I can try to find some time to sort this out.

Don't worrry, I just was wondering if you already could compile it.
Compiling in Windows is a bit more complicated.

In any case I will upload executables in a few days.