View previous topic :: View next topic |
Author |
Message |
Audi80
Joined: 07 Sep 2007 Posts: 41
|
Three interrupt only blocks INT_RDA |
Posted: Wed Sep 22, 2010 5:16 am |
|
|
Hi there i´ve developed a project using three interrupts:
1 - INT_RDA
2 - INT_EXT1 HIGH
3 - INT_EXT2 HIGH
My problem now is the following:
This project is an IO controller that is polled by a master every 100ms and sends the IO status. The INT_ETXs are used to increment an int like this:
Code: |
#INT_EXT1 HIGH
void pulseCounter1(){
++pulses;
} |
And the INT_RDA does the following:
Code: |
#INT_RDA
void communications(){
output_high(RX_STATUS);
buffer[ptr++]=getc();
if(ptr>=5){
if(buffer[ptr-5]==ENQ){
receiveMsg(buffer);
clearBuffer();
}
else if(buffer[ptr-2]==ETX){
receiveMsg(buffer);
clearBuffer();
}
else if(ptr==MAX_BUFFER_LEN) {
clearBuffer();
}
}
output_low(RX_STATUS);
} |
What happens is this, my controller can work 10h hours or just 10min and stops working because it seems that the INT_RDA without any explanation stops working because the led stops blinking.
The only answer i can find for this is if the INT_EXT and INT_RDA occurs exactly at the same time...
Does anyone know whats the result of it?
Thanks in advance |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Wed Sep 22, 2010 8:57 am |
|
|
Need a little more info.
What's the declared SIZE of buffer?
What speed is the RS232 running at?
What PIC, what version of CCS compiler?
It shouldn't be a problem that the IRQ's happen at the same time. The handler takes care of this and services them sequentially anyway. (you can control this with #priority pre-processor command)
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
Gabriel
Joined: 03 Aug 2009 Posts: 1067 Location: Panama
|
|
Posted: Wed Sep 22, 2010 9:12 am |
|
|
IMO, your ISR is waaaayy to long..
better to set a flag and then do all the stuff you got in there out of the ISR.
just my 2 cents...
Gabriel _________________ CCS PCM 5.078 & CCS PCH 5.093 |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Wed Sep 22, 2010 9:19 am |
|
|
Gabriel wrote: | IMO, your ISR is waaaayy to long..
better to set a flag and then do all the stuff you got in there out of the ISR.
|
I was going to ask that next.
What do
receiveMsg(buffer);
clearBuffer();
do?
I'm guessing it's too much and what's happening is the UART is overflowing.
You want to get in, get your char, get out.
Build a state machine that detects the ETX or end of buffer and then stop and wait for it to be processed (external flag of some sort).
That's what I do with my GPS routines and they work fine.
All the reception is done INSIDE the ISR.
All the "processing" is done outside the ISR.
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
Audi80
Joined: 07 Sep 2007 Posts: 41
|
|
Posted: Wed Sep 22, 2010 11:24 am |
|
|
It seems I found the problem. My receiveMsg(buffer) at some point was writing stuff to the eeprom. And when I removed it the problem seemed to stop. It could be that...
If the problems persists I will post more questions
Thanks for your help.... |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Wed Sep 22, 2010 1:35 pm |
|
|
You're taking too much time.
I'm guessing now your ISR isn't being serviced fast enough for incoming data and the result is a buffer overflow.
Like we said, keep your ISR to ONLY collecting chars to the buffer.
When the buffer is full or a packet is received, set a flag for the main loop to process it.
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Wed Sep 22, 2010 2:57 pm |
|
|
One byte to EEPROM, takes between 2*, and 4* the character time at 9600bps(depending on the chip), so 'yes', a killer for serial comms....
Also, hopefully, this code is not called at all frequently, or the EEPROM life limitations may need to be considered.....
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
|