In commit 0e97bcb (Put each HardwareSerial instance in its own .cpp
file), the serial event handling was changed. This was probably a
copy-paste typo.
The effect of this bug was that SerialEvent3 would not run, unless
SerialEvent2 was defined, but also that if SerialEvent2 is defined but
SerialEvent3 is not, this could cause a reset (call to NULL pointer).
This closes#1967, thanks to Peter Olson for finding the bug and fix.
Fixes#1203.
The original patch was introduced to workaround a problem with ArduinoISP reported
in #995. After some debugging it seems caused by a glitch in RXTX library,
more discussion here: https://github.com/arduino/Arduino/issues/1203
JSSC, on unix based systems like linux and MacOSX, when listing serial ports
tries to open each port to ensure its existence. While this check works well for
linux ports /dev/ttyS0..31, it leads to unexpected behaviuors on MacOSX in
particular with USB-CDC virtual serial ports.
This patch disable the check and keep it enabled only for linux ttySxx ports.
This adds also tty.* and cu.* to the list of available serial ports on MacOSX.
The code used to say:
while (EFC0->EEFC_FSR & EEFC_FSR_FRDY == 0);
This triggered a compiler warning, which is why I looked at this line
more closely:
warning: suggest parentheses around comparison in operand of '&'
As the warning indicates, because the == operator has higher precedence
than the & operator, the compiler is interpreting this line as:
while (EFC0->EEFC_FSR & (EEFC_FSR_FRDY == 0));
Since EEFC_FSR_FRDY is defined as 1, (EEFC_FSR_FRDY == 0) is always
false (== 0) and this reduces to:
while (EFC0->EEFC_FSR & 0);
Which reduces to:
while (0);
So effectively this line is a no-op.
This commit adds parenthesis to restore the intended behaviour.
This was already fixed for HardwareSerial.cpp in #1863, but there was
one more case hidden in HardwareSerial_private.h.
The index attributes have been uint8_t for a while, so there is no point
in using int for local variables. This should allow the compiler to
generate slightly more efficient code, but (at least on gcc 4.8.2) it
also confuses the register allocator, causing this change to increase
code size by 2 bytes instead due to extra push/pop instructions (but
this will probably change in the future if the compiler improves).
