Way to check if Serial.write() will block or way to have it fail instead of block. [imported]

[cmaglie]

This is Issue 672 moved from a Google Code project.
Added by 2011-10-08T16:59:01.000Z by hjohnson...@ric.edu.
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium, Component-Core

Original description

What steps will reproduce the problem?

1. Use Arduino RC1.
2. Download the code attached, and upload it to an Arduino board. (Uno or older, it doesn't matter)
3. Trigger the interrupt by grounding pin 2, sometimes this takes a few tries.

What is the expected output? What do you see instead?

The interrupt should trigger, but the serial shouldn't print out until the ISR is done under the new scheme of non-blocking serial writes. This happens most of the time.

However, sometimes, when the ISR is triggered, the serial still starts printing a few characters, doesn't finish, and hangs the processor. Even when the pin 2 grounding is removed, and the ISR should finish, it stays stuck there, and I have to use the hardware reset button to get it to work again.

The ISR does not hang the processor when the serial print is removed, so I'm pretty sure the problem is in there somewhere. This all seems to happen more often when the interrupt is rapidly triggered back and forth, though I'm not absolutely sure of this.

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?
I'm using Arduino RC1, downloaded on 10/8/11, on MAC OSX 10.6.8. This problem occurs on both the Arduino Uno and the Bare Bones Board clone running the non-optiboot Duemilanove firmware.

[matthijskooijman]

What I think that happens here is that the the serial buffer fills up when printing from inside an ISR. While the ISR is running, no other interrupts can be triggered, meaning the "byte sent" interrupt from the serial is never triggered, and thus HardwareSerial::write hangs forever waiting for some space in the buffer.

Your proposed fix works, but still requires manual action to make things work. Since this case should be detectable (before entering the wait loop inside HardwareSerial::write you can simply check if interrupts are disabled), I think we can fix this automatically (Automatically discarding data without the user asking for it is of course bad, but it would only happen where it now does a hard lockup, compared to which discarding data is of course perfectly fine). A second alternative that I could imagine is to actually start polling the serial hardware inside the while loop (if we know the interrupt won't fire). Not sure how well that would work, but it would cause the least surprise for anyone debugging an ISR (it would cause additional delays, but people will expect delays, not discarded data and lockups).

[matthijskooijman]

#1147 points out that calling flush() from an ISR will cause an automatic lockup in the same way, so flush() should probably receive the same treatment.

[cmaglie]

Merged the fix, to be released in 1.5.6.
C