External interrupts and Serial.print(), are there any conflicts?

Hi,
I would like to ask you a question about how Serial.print() works.

I have to send about 300 characters long string every few seconds through HW serial port on UNO at 115200 baud rate. It takes rather long - tens of milliseconds.

At the same time I have to count pulses from both external interrupt pins (maximum frequency is about 300Hz).
The external interrupt routine is really short and fast as it contains ony "buffer++;". All calculations are done in the main loop when there is nothing else to do.

The question is will there be any conflicts when I have to send those 300 chars AND pulses keeps coming? Will I miss any external interrupts?

I know HW serial should work on its own with its buffer but I am not sure how it handles such a long string.

Thanks!

The interrupts (both external and UART) will continue to happen even while HardwareSerial is waiting space in the output buffer to free up.

At 115,200 bits per second you can send about 11,520 characters per second. Your entire 300 character message should take about 26 milliseconds.

johnwasser: thanks. I am surprised to hear that. Because I remember I had an issue with timer interrupts during I2C communication so I assumed HardwareSerial will block other interrupts as well.

bumerang123:
johnwasser: thanks. I am surprised to hear that. Because I remember I had an issue with timer interrupts during I2C communication so I assumed HardwareSerial will block other interrupts as well.

USART interrupts are very low priority and definitely lower than external interrupts, pin change interrupts and the counter interrupts which you will most likely to be using for your counting. Also, the USART interrupts are character by character and not line by line so there will be plenty of time to handle your counting.

stowite:
USART interrupts are very low priority and definitely lower than external interrupts,

I thought the interrupt priority only plays a role when multiple interrupts are triggered at the same clock cycle?
Because even when you are inside of low priority interrupt all other interrupts are blocked - is this true?

bumerang123:
I thought the interrupt priority only plays a role when multiple interrupts are triggered at the same clock cycle?
Because even when you are inside of low priority interrupt all other interrupts are blocked - is this true?

Not necessarily the same clock cycle. When an ISR is active all interrupts are disabled. In the microseconds that the ISR is running, several other interrupts may be signaled. Priority determines which pending interrupt is serviced when interrupts are again enabled.
Since interrupts are disabled for the full duration of the ISR, it is important that ISRs are kept short. The Serial send interrupt just has to see if there is any data in the output buffer and, if so, move one byte to the output register. That shouldn't take more than a microsecond or two. At 115200 baud there will be about 87 microseconds between interrupts so about 97% of the processor time is available for other interrupts and your sketch. And that is only during the 26 milliseconds of Serial output every few seconds.
Your ISRs probably take a microsecond each so that leaves well over 90% of processor cycles left for your sketch.

johnwasser: that is perfect, thanks.