This may be be a silly question, but its baffling me. If I set up a receive interrupt, process the data and clear the flag. All works well. The problem is I need to use printf. I realize that this will of course also generate an interrupt, I handle this within the interrupt with if(TI)TI=0; hoping at worst it will just slow down printing. However this does not work, as soon as I try to print, all manner of strange erratic things happen. I had thought of disabling serial interrupt before a print statement, and re-enabling after, but at 300 baud (3-4 Secs) I could possibly miss a character. I cannot use full blown interrupt driven coms, due to lack of memory, rtos is also ruled out for the same reason. Any advice most gratefully received.

7 Years
Discussion Span
Last Post by grandalf62

That operating system and compiler are you using? In my MS-DOS 6.X days I had no conflicts between serial port interrups and printf(). I just wrote a serial port driver (supported 1 to 40 serial ports) that was TSR and the rest of the program ran normally, within the memory constraints of MS-DOS.


You're not trying to call printf() INSIDE the ISR are you?
Because that's a really bad idea.


Depends how printf is implemented in your compiler. In Keil, TI must
be set before printf is called. The is because of how putchar is implemented (which is called by printf.)

while (!TI);
  TI = 0;
  return (SBUF = c);

Thanks guys,

It is Keil, and I am not calling printf from within the isr. Colin Mac, is this what you mean I could try.


while (!TI);

And would I still need to clear TI in the isr?
Many thanks


What I posted is a segment of code from putchar.c which you can find in the lib folder.
printf won't work the way you posted because TI needs to be set before calling printf. You usually set TI once at the beginning of the program and then not worry about it again.

I'm pretty sure you won't be able to use a receive interrupt and call printf as is throughout the program because the ISR will execute over and over if TI or RI is not cleared in the ISR. You will have to come up with something yourself.


Again thank you for the advice. TI and RI are cleared in the interrupt, but it seems to make no difference. I have found that with software tidying up, I can poll RI reasonably quickly. Probably not ideal, but will see how it pans out in practice, may well be ok.

This article has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.