The current check is still always false when the old check was, but
additionally it will not disable the interrupts when they were never
enabled (which shouldn't matter much, but this is more consistent).
In this case, SoftwareSerial::begin will not have enabled the
interrupts, so better not allow the SoftwareSerial instance to enter the
listening state either.
Before enabling interupts, begin would see if the given receive pin
actually has an associated PCINT register. If not, the interrupts would
not be enabled.
Now, the same check is done, but when no register is available, the rx
parameters are not loaded at all (which in turn prevents the interrupt
from being enabled). This allows all code to use the same "is rx
enabled" (which will be added next).
Previously, it could happen that SPI::beginTransaction was
interrupted by an ISR, while it is changing the SPI_AVR_EIMSK
register or interruptSave variable (it seems that there is
a small window after changing SPI_AVR_EIMSK where an interrupt
might still occur). If this happens, interruptSave is overwritten
with an invalid value, permanently disabling the pin interrupts.
To prevent this, disable interrupts globally while changing
these values.
From https://github.com/arduino/Arduino/pull/2376#issuecomment-59671152
Quoting Andrew Kroll:
[..this commit..] introduces a small delay that can prevent the wait
loop form iterating when running at the maximum speed. This gives
you a little more speed, even if it seems counter-intuitive. At
lower speeds, it is unnoticed. Watch the output on an oscilloscope
when running full SPI speed, and you should see closer back-to-back
writes.
Quoting Paul Stoffregen:
I did quite a bit of experimenting with the NOP addition. The one
that's in my copy gives about a 10% speedup on AVR.
Previously, when verbose uploads were enabled, avrdude was run with four
-v options, causing it to dump all raw bytes exchanged with the
bootloader. This floods the console so much that meaningful output
mostly disappears.
Most users probably want to enable verbose mode just to see what avrdude
command is ran. Furthermore, users that benefit from the raw bytes
dumped are perfectly capable of either running avrdude manually, or
modifying platform.txt. Given that, running avrdude with just one -v
should be plenty.
This fixes#891.
When checking the `left` argument, it previously allowed having
left == len. However, this means the substring starts one past the last
character in the string and should return the empty string. In practice,
this already worked correctly, because buffer[len] contains the trailing
nul, so it would (re)assign the empty string to `out`.
However, fixing this check makes it a bit more logical, and prevents a
fairly unlikely out-of-buffer write (to address 0x0) when calling
substring on an invalidated String:
String bar = (char*)NULL;
bar.substring(0, 0);
Previously, this method calculated the length of the string from the
given index onwards. However, the other remove() method called already
contains code for this calculation, which is used when the count passed
in is too big. This means we can just pass in a very big count that is
guaranteed to point past the end of the string, shrinking the remove
method by a few bytes.
Previously, if you passed in a very big index and/or count, the
`index + count` could overflow, making the count be used as-is instead
of being truncated (causing the string to be updated wrongly and
potentially writing to arbitrary memory locations).
We can rewrite the comparison to use `len - index` instead. Since we
know that index < len, we are sure this subtraction does not overflow,
regardless of what values of index and count we pass in.
As an added bonus, the `len - index` value already needed be calculated
inside the if, so this saves a few instructions in the generated code.
To illustrate this problem, consider this code:
String foo = "foo";
Serial.println(foo.length()); // Prints 3
foo.remove(1, 65535); // Should remove all but first character
Serial.println(foo.length()); // Prints 4 without this patch
Not shown in this is example is that some arbitrary memory is written
as well.
The following empty stubs has been replaced by the gcc
flag -fno-threadsafe-static:
int __cxa_guard_acquire(__guard *);
void __cxa_guard_release (__guard *);
void __cxa_guard_abort (__guard *);
The following empty stubs has been moved into their specific
module abi.cpp:
void __cxa_pure_virtual(void) __attribute ((noreturn));
void __cxa_deleted_virtual(void) __attribute ((noreturn));
Fix#107
Stream::find(char *target) passes an empty terminator string to
Stream::findUntil(char *target, char *terminator) which caused a compiler
warning with the updated toolchain, so cast it to a char*.
These chips were previously supported, but since parity error checking
was added, this support has broken. Most chips define UPE0 (etc.) for
the parity error bit. Some chips don't have numbered UARTS so only
define UPE and even fewer define PE instead of UPE. This adds support
for those chips again.
Closes: #2137
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>
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.
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.
