View previous topic :: View next topic |
Author |
Message |
redicon
Joined: 26 Feb 2012 Posts: 8
|
lost int_rda interrupt |
Posted: Mon Mar 05, 2012 5:56 pm |
|
|
Can the int_rda be lost?
I mean:
My program has got 2 interrupts, rs232 and Timer1.
I've got a looping code that executes:
Code: |
disable_interrupts(INT_TIMER1);
output_a(row-1);
delay_us(1200);
output_a(EMPTY);
enable_interrupts(INT_TIMER1);
|
Is it possible that when I re-enable Timer1 interrupts if there is both Timer1 and rda interrupt flag, the Timer1 isr will be executed and the rda interrupt is lost?
Please tell me yes. |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
Re: lost int_rda interrupt |
Posted: Mon Mar 05, 2012 6:02 pm |
|
|
redicon wrote: | Can the int_rda be lost?
I mean:
My program has got 2 interrupts, rs232 and Timer1.
I've got a looping code that executes:
Code: | disable_interrupts(INT_TIMER1);
output_a(row-1);
delay_us(1200);
output_a(EMPTY);
enable_interrupts(INT_TIMER1);
|
Is it possible that when I re-enable Timer1 interrupts if there is both Timer1 and rda interrupt flag, the Timer1 isr will be executed and the rda interrupt is lost?
Please tell me yes.. |
Are you doing anything silly like using delays in your interrupt handler? If so then this will result in interrupts being disabled in the mainline calls to delay_us and therefore it would be reasonable to assume you can miss RDA interrupts at high baud rates.
delay_us() should generally NOT be used in interrupt handlers _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!
Last edited by asmallri on Mon Mar 05, 2012 6:59 pm; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9170 Location: Greensville,Ontario
|
|
Posted: Mon Mar 05, 2012 6:03 pm |
|
|
no, I won't say yes..
We need to see a complete but small program that we can compile. Also the PIC type and compiler version.
You can't 'lose' the interrupt, you have to read it first(done in the ISR).
Without seeing your whole program is is impossible to decide what is wrong. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Mar 05, 2012 10:56 pm |
|
|
You could "lose an int_rda interrupt" if you don't use a receive fifo buffer,
and if you fail to check for incoming characters often enough.
You can largely eliminate this problem by using a buffer, as shown in the
CCS Ex_sisr.c example file. When chars come in, the interrupt occurs
and the chars are put into a circular buffer. Then you don't have to
check so often. If the buffer is large (512 bytes), then depending on
your incoming character rate, maybe you only need to check the
buffer every few hundred milliseconds. Your program can be doing
something else for a long time and if you don't check the buffer it
doesn't matter, because the chars are saved in the buffer during that
time. You can read them when you finished doing other things in your
program. Here is the example file:
Quote: |
c:\program files\picc\examples\ex_sisr.c |
|
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19360
|
|
Posted: Tue Mar 06, 2012 2:30 am |
|
|
and, the key thing that nobody has said so far, there _must_ be 'ERRORS' in you #use RS232.
Key to understand, is that the hardware UART has just _under_ two characters of buffering. If at any time the code does not service INT_RDA, and data is arriving continuously, for a period that exceeds this, the UART _will_ flag an ERROR, and _will_ go into a hung state, if ERRORS is not set, _or_ you have your own error handling code in the interrupt. You _must_ have one or the other. If not, from this point on, the receive part of the UART will stop working.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Tue Mar 06, 2012 2:52 am |
|
|
Delays are going to mess with interrupts. Precisely how depends on a number of things.
Delays in critical sections, i.e. while interrrupts are turned off, are very bad news. If interrupts are going to work smoothly, critical sections must be as short as possible: no delays.
To avoid "missing" interrupts you must be able to service them as quickly as possible. So ciritcal sections must be short, and delays should be avoided, or at the very least made interruptable (but that implies buffering of incoming and probably out going data, which should probably be the norm anyway).
RF Developer |
|
![](templates/subSilver/images/spacer.gif) |
|