A fix for issue 672: http://code.google.com/p/arduino/issues/detail?id=672 #43
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… decides whether to wait for the ISR to open up some space, or quits immediately to avoid hanging the processor. (If this situation was caused from within another ISR). Added HardwareSerial::waitForBufferSpace(uint8_t v) which takes TRUE or FALSE so the user can make that choice.
…iable to the .h file.
|
this bug is fixed now. |
|
Is this bug really fixed? I think you can still lock up the Arduino by printing more than 64 bytes from an ISR? The issue this pullreq belongs to has been converted to github under #672, btw. |
|
Fixed with #672. |
tbowmo
pushed a commit
to tbowmo/Arduino
that referenced
this pull request
Jul 14, 2016
fix a case where parent distance from repeater get stuck at 255
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I discovered this potential issue earlier today, see the above link for more information. To fix this, I added a function called waitForBufferSpace(uint8_t) so the user can decide whether HardwareSerial should wait for buffer space when Serial.write() is called. By default, nothing has changed, and no serial data is lost. However, by calling Serial.waitForBufferSpace(0), the user can disable this waiting. This means that there is the potential for serial data that was supposed to be printed to be lost, but on the other hand, if Serial.write is called on a full buffer from inside of an ISR (a common occurrence when trying to debug ISR triggering), the entire processor won't lock up and have to be reset. I also added the keyword for this function so it lights up.