 |
 |
| View previous topic :: View next topic |
| Author |
Message |
RVR
Joined: 04 Jan 2012
Posts: 18
|
| I2C communication into an interrupt 18f2550 |
 Posted: Wed Jan 04, 2012 2:48 pm |
 |
|
Hi Everyone,
I'm trying to use the i2c communication into the portB interrupt on change, from 18f2550, following this code:
| Code: |
#INT_RB
void int_RB_isr(void)
{
enable_interrupts(int_ssp);
enable_interrupts(global);
ds1307_init(); //from lib
ds1307_get_time(hrs,min,sec); //from lib and use standard i2c func i2c_read,i2c_write,etc
}
...
void main (void)
{
enable_interrupts(int_ssp);
enable_interrupts(int_RB);
enable_interrupts(global);
....
}
|
results:
| Quote: |
>>> Warning 216 "I2C_MASTER_PRUEBAS_8.c" Line 373(0,1): Interrupts disabled during call to prevent re-entrancy: (@I2C_WRITEU_1)...
|
comments:
It's essential to call the i2c com into the interrupt (this mean don't use variable flags)
So i need to enable the com i2c into the int_RB, because the ccs complier disables all the interrupts when enter after have call an interrupt.
I think (wrong by the way) that should been to enable int-ssp but doesn't work because only has activity when the bus has activity.
Any idea? solution? will be appreciated.
thks |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9134
Location: Greensville,Ontario
|
|
| Posted: Thu Jan 05, 2012 7:58 am |
|
|
You should post your PIC type, compiler version and a complete but small program that fails. As well the I2C peripheral you're using.
Within the ISR you do NOT want to run the ds1307 init or read it !
ISRs must be short and fast. Typically you read the portB, set aflag or two, then exit.
Also you do NOT enable other ISRs fromt within an ISR. Bad coding and not allowed in CCS C ,I think.
Also be sure to have the correct pullup resistors on all the I2C lines you use. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19260
|
|
| Posted: Thu Jan 05, 2012 9:04 am |
|
|
First _absolutely essential_ thing that _must_ always occur in INT_RB, is that you _MUST_ read portB. Otherwise the chip will be hung forever.
Now seriously, there is nothing shown in your code, that can't be done 'better' by simply setting a flag, and calling the I2C code outside the ISR.
Then it is not CCS that prevents you using an interrupt inside an interrupt, but the hardware. You could perfectly well set another interrupt to use 'high', and have this executed from inside the ISR. Otherwise there is only one interrupt level, so 'of course' you cannot use an interrupt inside an interrupt.
However what you are trying to do does not want to use INT_SSP. INT_SSP, is basically for a _slave_ device where another chip is controlling the I2C. You are the master device in what you show, so all INT_SSP would do is make the code more complex, and less likely to work...
You can perfectly well enable interrupts inside an ISR, and when you exit the ISR, if the hardware conditions occur that trigger the interrupt, the handler will be called.
The error message, is because you have the I2C_WRITE routine being called both inside an ISR, and outside. Since the PIC does not have a variable stack, you cannot call a function inside itself, so interrupts _must_ be disabled when this happens. In fact doubly essential here, since there is only one set of I2C hardware, and trying to use it from two places, makes pulling yourself up by your bootstraps look positively simple.
Best Wishes |
|
|
RVR
Joined: 04 Jan 2012
Posts: 18
|
|
| Posted: Thu Jan 05, 2012 12:10 pm |
|
|
| temtronic wrote: | You should post your PIC type, compiler version and a complete but small program that fails. As well the I2C peripheral you're using.
Within the ISR you do NOT want to run the ds1307 init or read it !
ISRs must be short and fast. Typically you read the portB, set aflag or two, then exit.
Also you do NOT enable other ISRs fromt within an ISR. Bad coding and not allowed in CCS C ,I think.
Also be sure to have the correct pullup resistors on all the I2C lines you use. |
Thanks for your answer temtronic,
following your comments, i think that the flag method for an interrupts is the only way to use correctly and efficiently the interrupts sources, but calling from the main function isn't the efficiently way because force constantly at looking a flag variable, set priority and hierarchy from it... If i use the flag method will be necessary find a best method than looking the flag in every "end" a function in the main program, especially if the main program contains a lot of sub-routines
best regards |
|
|
RVR
Joined: 04 Jan 2012
Posts: 18
|
|
| Posted: Thu Jan 05, 2012 12:38 pm |
|
|
| Ttelmah wrote: | First _absolutely essential_ thing that _must_ always occur in INT_RB, is that you _MUST_ read portB. Otherwise the chip will be hung forever.
Now seriously, there is nothing shown in your code, that can't be done 'better' by simply setting a flag, and calling the I2C code outside the ISR.
Then it is not CCS that prevents you using an interrupt inside an interrupt, but the hardware. You could perfectly well set another interrupt to use 'high', and have this executed from inside the ISR. Otherwise there is only one interrupt level, so 'of course' you cannot use an interrupt inside an interrupt.
However what you are trying to do does not want to use INT_SSP. INT_SSP, is basically for a _slave_ device where another chip is controlling the I2C. You are the master device in what you show, so all INT_SSP would do is make the code more complex, and less likely to work...
You can perfectly well enable interrupts inside an ISR, and when you exit the ISR, if the hardware conditions occur that trigger the interrupt, the handler will be called.
The error message, is because you have the I2C_WRITE routine being called both inside an ISR, and outside. Since the PIC does not have a variable stack, you cannot call a function inside itself, so interrupts _must_ be disabled when this happens. In fact doubly essential here, since there is only one set of I2C hardware, and trying to use it from two places, makes pulling yourself up by your bootstraps look positively simple.
Best Wishes |
Thanks for your answer Ttelmah,
the interrupt source is an alarm int_RB from the RTC, That Occurs When the alarm = real time, and Then the device (DS1305) set to report in line Which is the port B, so the condition of Does not Matter Just That port B WAS Called the interruption ...
Concerning the reason for calling the interruption, I will explain Broadly speaking the project.
PIC18F2550 (master slave +2 by DS1305 RTC i2c + + EEPROM)
Master main program
| Code: |
while {
calculations arithmetic routines (3);
get data from ADC;
genetic algorithms (high complexity and time)
send data to slaves
slaves waiting for an answer
update data
}
}
|
Interrupt sources are used to receive data from the slaves, receive alarm clock with the user interface (USB), set safety limits.
So this is a simplified main program for this project so I'm trying to explain why it isn't a good business call every time the flag interrupt... This is a "real time task" (or i hope to be closest as possible).
Best regards |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9134
Location: Greensville,Ontario
|
|
| Posted: Thu Jan 05, 2012 12:58 pm |
|
|
CCS gives an example program(may be in the FAQ section) that 'decodes' the portB interrupts which I use everyday. That might be of interest to you.
Looks like you're using the DS1305(last post) not the DS1307(1st post) which kinda confused me.Either way be sure to use pullup, else you won't get the ISR from the RTC ! |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
