Before, HardwareSerial1+.cpp were a copy of HardwareSerial1.cpp with all
0's replaced by the corresponding number. This would mean that e.g.
the Serial1 object would use the UBRRL register instead of UBRR1L when
it was defined, or the USART_RX_vect instead of USART1_RX_vect.
In practice, this would neve actually cause problems, since:
- No avr chip currently has both the non-numbered registers as well as
numbered registers.
- HardwareSerial.h would only define HAVE_HWSERIALx when the
corresponding numbered register is defined (except for
HAVE_HWSERIAL0, which is also defined when the unnumbered registers
are present).
Furthermore, before both the UARTx_xx_vect and USART_x_xx_vect was used.
Looking at the include files, only UART1_xx_vect is actually used (by
iom161.h), the others use USARTx_xx_vect. For this reason,
HardwareSerial1.cpp keeps the preprocessor conditional to select either
UART or USART and the other files use USART unconditionally.
While we're here, also fix the compiler error message when no valid ISR
name was found (it previously said "for the first UART" in all cases).
Previously, this relied on an (ugly, avr-specific) magic default for the
compiler.path variable, set by the IDE. This allowed the IDE to fall
back to a system-wide toolchain when no bundled toolchain was found (by
making compiler.path empty).
However,
- this only worked for avr, not sam,
- this worked only for gcc, a system-wide avrdude would break on the
avrdude.conf path in platform.txt, and
This would mean that automatic system-wide fallback didn't work in all
situations, so you'd still have to modify platform.txt (or create
platform.local.txt). Since doing that explictly is the most reliable
way, this commit removes the partial-working ability to do this
automatically.
Note that the code to automatically set compiler.path is still kept
around, in case third-party hardware still relies on this. At some
point, this code should be removed, but for now it just shows a warning
message.
Adds ability to set length, parity and stop bit configuration to
hardware serial ports using USART module (Serial1, Serial2, and Serial
3) on Due to allow compatibility with avr devices.
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.
Added support for buffer sizes bigger than 256 bytes.
Added possibility to overrule the default size.
Added support for different size of TX and RX buffer sizes.
The default values remain the same. You can however specify a different
value for TX and RX buffer
Added possibility to overrule the default size.
If you want to have different values
define SERIAL_TX_BUFFER_SIZE and SERIAL_RX_BUFFER_SIZE on the command
line
Added support for buffer sizes bigger than 256 bytes.
Because of the possibility to change the size of the buffer sizes longer
than 256 must be supported.
The type of the indexes is decided upon the size of the buffers. So
there is no increase in program/data size when the buffers are smaller
than 257
Added support for different size of TX and RX buffer sizes.
Added support for buffer sizes bigger than 256 bytes.
Added support for different size of TX and RX buffer sizes.
The default values remain the same. If you want to have different values
define SERIAL_TX_BUFFER_SIZE and SERIAL_RX_BUFFER_SIZE on the command
line
Added support for buffer sizes bigger than 256 bytes.
The type of the indexes is decided upon the size of the buffers. So
there is no increase in program/data size when the buffers are smaller
than 257
Members of this array are later passed to functions that accept
non-const pointers. These functions probably don't modify their
arguments, so a better solution would be to update those functions to
accept const pointers. However, they look like third-party code, so that
would require changing the code again on every update. Removing const
here fixes at least the compiler warning for now.
This helps towards #1792.
This makes the declaration of sprintf available, so the function is not
implicitely declared, which triggers two compiler warnings.
This helps towards #1792
A bunch of functions have parameters they do not use, but which cannot
be removed for API compatibility.
In syscalls_sam3.c, there are a lot of these, so this adds an "UNUSED"
macro which adds the "unused" variable attribute if supported (GCC
specific), or is just a noop on other compilers.
In CDC.cpp, there's only three of these variables, so this commit just
forces a dummy evaluation of them to suppress the warnings.
This helps towards #1792.
peekNextDigit() returns an int, so it can return -1 in addition to all
256 possible bytes. By putting the result in a signe char, all bytes
over 128 will be interpreted as "no bytes available". Furthermore, it
seems that on SAM "char" is unsigned by default, causing the
"if (c < 0)" line a bit further down to always be false.
Using an int is more appropriate.
A different fix for this issue was suggested in #1399. This fix helps
towards #1728.
In C++, true and false are language keywords, so there is no need to
define them as macros. Including stdbool.h in C++ effectively changes
nothing. In C, true, false and also the bool type are not available, but
including stdbool.h will make them available.
Using stdbool.h means that we get true, false and the bool type in
whatever way the compiler thinks is best, which seems like a good idea
to me.
This also fixes the following compiler warnings if a .c file includes
both stdbool.h and Arduino.h:
warning: "true" redefined [enabled by default]
#define true 0x1
warning: "false" redefined [enabled by default]
#define false 0x0
This fixes#1570 and helps toward fixing #1728.
This only changed the AVR core, the SAM core already doesn't define true
and false (but doesn't include stdbool.h either).
Previously, pointer casting was used, but this resulted in strict-aliasing warnings:
IPAddress.h: In member function ‘IPAddress::operator uint32_t() const’:
IPAddress.h:46:61: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
operator uint32_t() const { return *((uint32_t*)_address); };
^
IPAddress.h: In member function ‘bool IPAddress::operator==(const IPAddress&) const’:
IPAddress.h:47:81: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
bool operator==(const IPAddress& addr) const { return (*((uint32_t*)_address)) == (*((uint32_t*)addr._address)); };
^
IPAddress.h:47:114: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
bool operator==(const IPAddress& addr) const { return (*((uint32_t*)_address)) == (*((uint32_t*)addr._address)); };
Converting between unrelated types like this is commonly done using a union,
which do not break the strict-aliasing rules. Using that union, inside
IPAddress there is now an attribute _address.bytes for the raw byte
arra, or _address.dword for the uint32_t version.
Since we now have easy access to the uint32_t version, this also removes
two memcpy invocations that can just become assignments.
This patch does not change the generated code in any way, the compiler
already optimized away the memcpy calls and the previous casts mean
exactly the same.
This is a different implementation of a part of #1399 and it helps
toward fixing #1728.
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).
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).
