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.
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.
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.
These functions do not modify the IPAddress object, but were not marked
as const. This meant that you could not do:
void set_ip(const IPAddress& ip) {
uint32_t copy = ip;
}
Since calling operator uint32_t() on ip would discard the constness of
the reference.
On later versions of avr-libc, prog_char is deprecated. In 0acebeeff4
the one occurence of prog_char was replaced by "char PROGMEM", which is
not entirely correct (PROGMEM is supposed to be an attribute on a
variable, not on a type, even though this is how things work in older
libc versions). However, in 1130fede3a a few new occurences of
prog_char are introduced, which break compilation on newer libc versions
again.
This commit changes all these pointer types to use the PGM_P macro from
<avr/pgmspace.h>. This macro is just "const char *" in newer libc
versions and "const prog_char *" in older versions, so it should always
work.
References #795
The new function just calls Print::write(const uint8_t *, size_t), but
this allows writing out a buffer of chars (without having to learn about
casts).
