rs232 to not interrupt timers

[cerr]

Hey There,

Any one an idea how I can have RS232 traffic not NOT interrupt my timer ISRs (as they're critical).
I could have a global CriticalSection variable that i would set of the beginning of each timer isr and reset at the end of the isr and instead of fprintf I would call Myprintf and in MyPrintf I could check if CriticalSection is reset before i'd send out char by char with putc in a while(CharsInQueue) loop. Any other ideas?
Suggestions are appreciated!

[Ttelmah]

It'd help if you said 'what chip'.
On the 18 series chips, you can just make the timer interrupts high priority, and leave the serial as normal, and then the timer interrupts won't be affected by the serial at all.
On the 16 chips 'more complex', but there is no reason at all, that the serial interrupt can't check the timer flags as well, and vector to the timer handlers.

Best Wishes

[John P]

I would say, use timer interrupts only. Have them occur rapidly enough that you get at least one in the time taken for a character to be received. Don't enable interrupts from received characters, but when the timer interrupt happens, poll the receive interrupt flag, and if necessary, grab the new character, and either process it (if that's fast) or buffer it for the main() routine to deal with later.

For transmission, similarly check whether the transmit buffer is empty on each timer interrupt, and drop a character into it if it's found to be free. That is, if there's anything waiting to transmit, obviously!

[ckielstra]

I get the feeling the original poster has a problem with the RS232 transmissions taking too much time, i.e. the original printf function can take a long time sending texts. I suggest he has a look at the example program ex_stisr.c where a ring buffer is used to printf data under interrupt control.

This under the assumption that he is using a real hardware UART and not one of the software emulated ones.

[Ttelmah]

Agreed.
Looking at it again, it sounds as if he may be printing from inside the ISR, in which case the old mantra of 'set a flag, and do anything that takes time in the main, not the ISR', applies.

Best Wishes

[cerr]

[cerr]

[Ttelmah]

Printing outside the ISR, should not affect the ISR at all. Assuming you are using a hardware UART to do the printing?. If you are using a software UART, then you _must_ disable interrupts during the transmission, or the transmission _will_ be corrupted. With the hardware UART, you don't want interrupts disabled.
Don't confuse the #priority statement, which sets the order the interrupts are _polled_, with the #device HIGH_INTS=TRUE, and #INT_xxx HIGH, which switches the interrupt to become a _hardware_ high priority interrupt. I suspect you may have been playing with the former, rather than the latter.

Best Wishes

[cerr]

no, i infact have played with HIGH_INTS=TRUE and #INT_XXX HIGH - I am using hardware interrupt but it seems like while an rs232 transfer is going on, the timers behave differently - i can't research this right now but will get back to that sooner or later...

[Douglas Kennedy]

Try using as suggested the TBE interrupt and a good sized circular buffer
fed from your printf's in main. Since timers still tick when ISR's are called the only issue should be near simultaneous interrupts and delays saving the stack when getting into your ISR's. The printf circular buffer allows you to give it a low priority if you choose.
In fact sometimes it is better whenever RS232 is needed to just go ahead and set up the receive and transmit circular buffers. The asynchronous nature of RS232 makes for a rough ride if you don't use a circular buffered interrupt .