Stream::find(char *target) passes NULL as “terminator” to Stream::findUntil(char *target, char *terminator), which immediately dereferences it by passing it on to strlen() :
bool Stream::find(char *target)
{
return findUntil(target, NULL);
}
// as find but search ends if the terminator string is found
bool Stream::findUntil(char *target, char *terminator)
{
return findUntil(target, strlen(target), terminator, strlen(terminator));
}
Stream::find(char *target) passes NULL as “terminator” to Stream::findUntil(char *target, char *terminator), which immediately dereferences it by passing it on to strlen():
bool Stream::find(char *target)
{
return findUntil(target, NULL);
}
// as find but search ends if the terminator string is found
bool Stream::findUntil(char *target, char *terminator)
{
return findUntil(target, strlen(target), terminator, strlen(terminator));
}
If the Start of Frame interrupt triggers just after the call
to USB_SendSpace in USB_Send then we can get data loss.
When the first bank is full and the second partially full,
the SOF handler will release the second bank via USB_Flush.
Data is then lost due to overflow as USB_Send continues writing data
to the now-closed bank.
Fix this by re-checking the FIFO status inside LockEP, immediately before
doing the data write.
Signed-off-by: Paul Brook <paul@nowt.org>
Previously, when SoftwareSerial was initialized, it would always be set
to an idle level of HIGH, even when inverted logic was enabled. Once a
byte is transmitted, the idle level gets correctly set to LOW instead.
This commit makes sure that the idle level is correct directly after
initialization already.
This fixes#1361.
calling https URLs without checking for the validity of SSL
certificates.
While this makes it a little insecure, nothing else can be done
while keeping the HTTPClient API simple: openwrt does not have a
SSL certificates bundle
Advanced users concerned about security should call "curl" on
their own using Process, supplying parameters such as "--cacert"
Fixes#1860
Some devices, such as the atmega2560 or the atmega256rfr2 have a timer1c
output. It seems this output is not connected to anything on the Arduino
Mega, but this allows using it on third party hardware nonetheless.
When a path contains spaces (or other special characters, probably), gcc
escapes them with a \ in the generated .d files. This previously caused
problems when parsing these files, causing recompiles to happen even
when not needed.
This applies a rather simple approach to unescaping these strings, which
seems to be sufficient because the file format of the .d files is so
predictable (e.g., we don't actually split on colons or spaces when
parsing it).
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, preferences suffixed with .macos were treated specially,
but the default preferences.txt used .macosx.
I couldn't find when or how this was broken exactly - it seems
Processing used .macosx but this code was reimplemented for Arduino in
commit 33f5c53 (Implemented OS specific preferences) using .macos.
The effects of this have not been tested on OSX, but this might fix some
problems caused by wrong defaults on OSX.
In preferences files, platform-specific versions can be indicated by a
.linux, .windows or .macos suffix on the key name. Previously, these
keys were loaded as normal and then afterwards, all keys were scanned
after loading them and any platform-specific versions replaced the
regular ones.
However, this means that these platform-specific versions get an
unexpected form of priority. Normally, when a single key is set twice,
the latter overrides the first. However, the platform-specific values
could override the regular versions, even when the regular version
occurs later in the file.
This problem was particularly confusing when using the new
platform.local.txt: a regular preference in platform.local.txt did not
override a platform-specific preference in platform.txt.
This commit changes behaviour to process these suffixes directly as they
are read from the preference files. If a suffix for the current platform
is found, the line is processed as if the suffix was not present. If a
suffix for another platform is found, the line is ignored altogether.
This can slightly change the way preferences files are parsed, but as
long as platform-specific preferences are defined after the
corresponding regular preferences, the behaviour should be the same.
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.
