Fixes#1021
The UART hardware will push characters into the receive FIFO even if there
are parity, framing, or other errors. These are invalid and shouldn't be
returned to the application, so drop them if errors detected.
This will also avoid the glitch-induced initial garbage character.
Previously, File::readString used a C-style string as an intermediate
buffer via the String += operator. This treats a NUL byte as a
terminator, making this function work incorrectly if the File contains
binary data.
This commit switches the function to use String::concat, which doesn't
treat NUL bytes any differently (and is a bit faster, because it doesn't
need to use strlen).
When receiving a `QUIT` message, the main thread was trying to tell
the scanner thread to quit - however, what it was actually doing was
creating a local variable that shadowed the global flag used by the
scanner thread. Fix that by ensuring that the main thread uses the
global variable instead.
Fixes#1028
The memcpy to unallocated memory was done in two cases:
1) The 'size' parameter was not multiple of 256.
2) The begin() was called two times and the 2nd call 'size' was greater than 1st time 'size'. (e.g. 1st size=256, 2nd size=512)
Fixes#979
Make sure to read the last byte of I2C data in the case where the IRQ happens
and the STOP signal is also asserted.
Also ensure all branches of the IRQ handler look at the same point in time
value for the IRQ status.
* add rough for scorpio
* Add SCORPIO items from ladyada
* Change PID in makeboards.py instead of boards.txt
* Fix PID in scorpio JSON
* README: Add Feather SCORPIO to supported boards
* Fix PIDs using values from MBAdafruitBoards
Still unsure about pid.[1-7] but let's see what happens
* boards.txt fixed by running makeboards.py
Co-authored-by: lady ada <limor@ladyada.net>
The PWM internals on the RP2040 are based on 8 slices with independent
clocking. Make sure that we init the PWM slice being used only once per
change of frequency/range.
Only init the scaling values one time, because we also adjust the input
scale/frequency values when calculating them. If we ran this twice (i.e.
writing to two slices), it would overwrite the pseudo scale/slow scale
values with 1 causing the wrong PWM values to be set.
Fixes#955
There's a memory leak around the corner: creating the mutex means
that we allocate memory for it, but if we cannot find any free slot in the
FMMap array, we're simply returning a nullptr without ever freeing the
previously allocated memory.
Instead of allocating it out of the free-slot check, do it inside.
While at it, also check if the mutex creation succeeded before assigning
it to a FMMap slot.
A new flexible and powerful "pluggable discovery" system was added to the Arduino boards platform framework. This system
makes it easy for Arduino boards platform authors to use any arbitrary communication channel between the board and
development tools.
Boards platform configurations that use the old property syntax are automatically translated to the new syntax by
Arduino CLI:
https://arduino.github.io/arduino-cli/latest/platform-specification/#sketch-upload-configuration
> For backward compatibility with IDE 1.8.15 and older the previous syntax is still supported
This translation is only done in platforms that use the old syntax exclusively. If `pluggable_discovery` properties are
defined for the platform then the new pluggable discovery-style `upload.tool.<protocol_name>` properties must be defined
for each board as well.
This platform includes a "UF2 Devices" discovery tool for `uf2conv` protocol ports. This tool now uses the modern
Arduino pluggable discovery system. `pluggable_discovery` properties were added to `platform.txt` in order to configure
the Arduino development tools to use this pluggable discovery tool. The `upload.tool.<protocol_name>` properties in
`boards.txt` were not updated at that time.
Global properties of that name were added to platform.txt, but this approach is not provided for by the Arduino Platform
specification:
https://arduino.github.io/arduino-cli/latest/platform-specification/#sketch-upload-configuration
> A specific upload.tool.<protocol_name> property should be defined for every board in boards.txt:
Those missing properties caused uploads to fail for users of the recent versions of Arduino IDE and Arduino CLI with an
error of the form:
Error during Upload: Property 'upload.tool.<protocol_name>' is undefined
(where `<protocol_name>` is the protocol of the selected port, if any)
It is also important to provide compatibility with versions of Arduino development tools from before the introduction of
the modern pluggable discovery system. For this reason, the old style `<board ID>.upload.tool` properties are retained.
Old versions of the development tools will treat the `<board ID>.upload.tool.<protocol_name>` properties as an unused
arbitrary user defined property with no special significance and the new versions of the development tools will do the
same for the `upload.tool` properties.
* analogWrite: fix overflow and wrap value (#917)
-avoid overflow when calculating analogScale * analogFreq, perform
the multiplication in floating point.
-use analogScale - 1 to set the PWM wrap value. Wrap is the highest
value the counter reaches, not the counter period.
* analogWrite: increase frequency range (#917)
- increase frequency range to 10 MHz
- decrease the lowest allowed resolution to 2 bits, and the
minimal analogRange value to 3. This makes 10 MHz output possible
with system clock frequencies down to 50 MHz.
- allow clkdiv values >= 1.0, was 2.0. This makes it possible to
manually set frequency and analogRange so that
frequency * analogRange = system clock frequency.
This gives the best possible frequency accuracy and
resolution.
Random crashes, infinite loops, and other lockups were happening to the PicoW
while under high load from multiple clients.
This seems to have been due to two issues:
* The periodic sys_check_timeouts() call from an alarm/IRQ was happening while
the core was in LWIP code. LWIP is not re-entrant or multi-core/thread safe
so this is a bad thing. Some calls may not have been locked with a manual
addition of the LWIPMutex object to hit this.
* The WiFi driver supplies packet data during an interrupt. PBUF work is
legal in an interrupt, but actually calling netif->input() from an IRQ to
queue up the Ethernet packet for processing is illegal if LWIP is already
in progress.
Rearchitect the LWIP interface to fix these problems:
* Disable interrupts during malloc/etc. to avoid the possibility of the
periodic LWIP timeout check interrupting and potentially calling user
code which did a memory operation
* Wrap all used LWIP calls to note LWIP code will be executing, instead of
manually eyeballing and adding in protection in user code.
* Remove all user code LWIPMutex blocking, the wrapping takes care of it.
* When an Ethernet packet is received by interrupt and we're in LWIP code,
just throw the packet away for now. The upper layers can handle retransmit.
(A possible optimization would be to set the packet aside and add a
housekeeping portion to the LWIP wrappers to netif->input() them when safe).
* Ignore callbacks during TCP connection teardown when the ClientContext
passed from LWIP == nullptr
noInterrupts/interrupts use a stack to allow multiple calls to work
properly. The original code was using a std::stack which will use
malloc() to allocate entry space. This seems like a bad idea, and
makes it so it's impossible to disable interrupts for malloc/free,
etc.
Define a fixed stack size and use straight C code to manage the IRQ
stacks. Slightly more fixed memory requirements, but significantly
lower total RAM requirements and no malloc() dependency.
When moving between different modes or even WiFi.begin/ends, any setting
of the IPs will fail because the internal flag _started was not cleared.
Clear _started on a ::end call.
Fixes#884
