CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

PIC16F1769 Interrupt problem

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
MikeW



Joined: 15 Sep 2003
Posts: 184
Location: Warrington UK

View user's profile Send private message

PIC16F1769 Interrupt problem
PostPosted: Wed Jan 27, 2016 3:32 am     Reply with quote

I have been chasing an interrupt problem for a couple of days now.

issues :-

1. I believe the 1769 has IOC capability, but the compiler ( V5.053 ) wont accept the pre-processor directive #INT_IOC, and its not in the header file unlike the PIC16F1783.

2. I have the following in main
Code:

clear_interrupt(INT_RC); // just in case
enable_interrupts(INT_RC0_H2L);
enable_interrupts(INT_RC1_H2L);

enable_interrupts(GLOBAL);

I have discovered that when triggered, it goes to
Code:

#INT_RB   // should be #INT_RC surely
void RB_isr(void
{
int8 junk;
IOCCF &=0 //  otherwise it keeps happening, but its portC !!!
junk=input_C(); // read the port to clear the change
etc etc
}

any ideas ?
Ttelmah



Joined: 11 Mar 2010
Posts: 19505

View user's profile Send private message

PostPosted: Wed Jan 27, 2016 4:44 am     Reply with quote

This is a combination of history, and CCS doing their best to confuse....

Historically on most chips only PortB supported an interrupt on change. The interrupt handler for this was therefore called 'INT_RB'.
Then chips with this extended to other ports came along, and on the first few device files for these, the RB name was kept.
They added separate defines to enable the interrupt on the whole port.
Then CCS realised the name was silly, so they switched to the IOC nomenclature on later chips.

So the handler is called INT_RB in the header for this chip.
INT_RB approximately equals INT_IOC.

There is really no separate INT_RC
The define for this would take you to the RB handler. The extra bits are the mask bits for which bits will generate the interrupt. You can use this just the same as INT_RB or INT_RA. They are all the same!...

As a general comment, you cannot clear an 'interrupt on change', till the change condition is cleared. This is why on the old INT_RB interrupt, you had to read port B, before using a 'clear_interrupts' call.

So if you use #INT_RB or #INT_RC, they both will define the same handler.

Code:

#include <16F1769.h>
#device ADC=10
#use delay(internal=8000000)
#BYTE IOCCF=getenv("SFR:IOCCF") //Port C IOC register
#byte IOCBF=getenv("SFR:IOCBF") //Port B IOC register
#byte IOCAF=getenv("SFR:IOCAF") //Port A IOC register

#INT_RC //This actually generates the same handler as INT_RB
void  IOC_isr(void)
{
   int8 junk;
   junk=input_C();
   if (interrupt_active(INT_RC0_H2L))
   {
      //RC0 has triggered
      clear_interrupt(INT_RC0_H2L);
      //do what you want
   }
   if (interrupt_active(INT_RC1_H2L))
   {
      //RC1 has triggered
      clear_interrupt(INT_RC1_H2L);
      //do what you want
   } 
}

void main()
{
   int8 dummy;
   dummy=input_c(); //ensure change latches are cleared
   IOCCF&=0; //and the flags
   clear_interrupt(INT_RC); //This clears the INT_RBA/RB/RC...
   enable_interrupts(INT_RC0_H2L | INT_RC1_H2L); //enable the change interrupt on the two pins
   enable_interrupts(GLOBAL); //and global

   while(TRUE)
   {
      //Whatever you want
   }
}


Fun....

There is also a caveat. I've not bothered about it here.

The & on IOCCF, is meant to be used to avoid the possibility of an interrupt being missed if it happens in the same instruction. Unfortunately the optimiser 'knows' it can clear the register with CLR, so it doesn't actually use the &. If asked to clear the IOC bits, the compiler optimiser also decides to use bit_clear rather than &.
If this is a problem, separate code will be needed to and each bit in turn...
MikeW



Joined: 15 Sep 2003
Posts: 184
Location: Warrington UK

View user's profile Send private message

PostPosted: Wed Jan 27, 2016 5:02 am     Reply with quote

@Ttelmah

you are a diamond !!

thank you for the clarification.

So, if I also have interrupt on change on pins A and B also, I use this same handler, and just test for what caused it.

as an aside, I am still trying to find time to amend your brilliant SD1306 driver

Mike
Ttelmah



Joined: 11 Mar 2010
Posts: 19505

View user's profile Send private message

PostPosted: Wed Jan 27, 2016 5:15 am     Reply with quote

Did you see my note on that?.

I've posted the code change needed, and all that is required is a change to half a dozen characters in the font. Smile
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group