* Convert to SDK RP2350A/B determination
Fixes#2878
The SDK uses `defined(PICO_RP2350) && !PICO_RP2350A` to indicate an RP2350B
chip, not the define PICO_RP2350B.
Match the SDK's usage by converting from `defined(PICO_RP2350B)` to
`defined(PICO_RP2350) && !PICO_RP2350A` and update the chip variants
accordingly.
* Need to explicitly override PICO_RP2350A for all
The *SDK*'s board definition file hardcodes a PICO_RP2350A value for
all boards, but we use the same board file for both A and B variants.
Override the SDK board definition in the variant definition file.
* Generic RP2350 needs 2-stage PICO_RP2350A setting
Also ensure SDK board definition included before pins_arduino.h for
clearing up redefinition errors.
* Factor out undef PICO_RP2350A
* Update Arduino.h
* Add support for the extra 16 GPIO pins in the menus and core.
* Clean up Generic RP2350 PSRAM ("none" is valid) and flash (other than 16MB) options.
* Add extra GPIO<->peripheral connections
* Add Pimoroni PGA2350 RP2350B-based board
* Pins 32-47 can be used for PIOPrograms
* Avoid hang when PSRAM fails to initialize
* Move libpico to an RP2350B board for SDK (otherwise the SDK drops all GPIOHI support)
Use real GPIO pad inversion to allow inverted RX, TX, and controls for
the hardware UART and software PIO-emulated serial ports.
Adds ``setInvertTX(bool)`` and ``setInvertRX(bool)`` calls to both ports,
with ``setInvertControl(bool)`` for the HW UARTS.
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.
Add plumbing to allow `Wire`, `Serial1`, `SPI1` to map to the 2nd
hardware unit for devices where the PCB layout only brings out the
2nd port.
Fix the Seeedstudio XAIO pins
Fixes#594
* Avoid "chunkiness" of UART FIFO availability
The UART FIFO will generate an IRQ to transfer data into the SerialUART
FIFOs either every 4 received bytes, or every 4 idle byte times. This
causes the ::available count to report "0" until either of those two
cases happen, causing a potentially delay in data becoming available to
the app.
Change the code to pull data from the HW FIFO on a read/available/peek.
Use a non-blocking mutex and IRQ disabling to safely empty the FIFO from
user space. The mutex added to the IRQ is non-blocking and will be
a single CAS the vast majority of the time, so it should not impact the
Serial performance.
Fixes#464 and others where `setPollingMode()` was needed as a workaround.
Make sure we have all mutexes locked before we disable the port and free
the queue to avoid evil cases.
Only init the mutexes once, on object creation.
In polled mode, don't bother acquiring/releasing the fifo mutex.
When begin() is called on an already running port, call end() to clean
up the old data/etc. before making a new queue/config. This avoids a
memory leak and potential write-after-free case.
Fixes#472
Instead of using interrupts, explicitly call the IRQ handler dueing Serial
read/peek/available calls.
Add to keywords.txt for syntax hilighting.
Add poll calls in the SerialUART::write-like calls (write,
flush, etc.)
Really remove division from IRQ routines/
Fixes#468
The FIFO limit was set to 1/2, or 16 bytes on POR and not set by the core,
so for low baud this could result in a LONG time without data moving from
hardware FIFO to the SW ring buffer and timeouts/etc.
Now use the API call which sets it to 1/8, or 4 bytes of data to speed up
the transfer 4x.
Also avoid using the divider in the IRQ routine because it is not clear
from the docs of the Pico SDK IRQ callback routine preserves divider
state or not. If not, doing division in an IRQ could result in random
data corruption in the main app.
Add memory barriers to ensure the order of data into RAM is preserved
and that GCC doesn't reorder writes.
When the Serial software FIFOs overeflowed, the IRQ handler would not
read any more data from the hardware FIFOs. This would cause the
IRQ handler to be continually called as soon as it exited since the
HW FIFOS were not empty.
Now always read every available HW FIFO entry and throw out any that
don't fit in the SW FIFO.
Also fix a too long by half stop bit timing in the PIOSerial receiver.
PR #379 was an ugly hack which works only if you poll the Serial port more
frequently than ~8 byte times.
This PR replaces the polling with an IRQ based lockless writer/reader queue
so that even if you only read every 32 byte times, the Serial1/2 port should
not lose data. It also should use less CPU and allow for somewhat higher
throughput.
Because the hardware FIFO is quite small and doesn't report the actual number
of bytes available, implement a software FIFO that will pull all available
bytes out of the HW FIFO on any Serial call. It's not as efficient or as
bulletproof as an IRQ based method, but it is simpler to implement and can
help with issues like #378
Fixes a hang when reading from the Serial UART ports because before the
core would pause indefinitely for the next character.
Now, wait up to Serial.setTimeout() milliseconds and if it times out
return -1 to the app.
Fixes#210
Fixes#169
Trying to change pinout while running, or to an illegal configuration,
will now immediately panic() with an error message. Such an attempt
is a pretty big problem since pinouts are hardware related/static.
Prior code would fail silently and return false, but nobody checked
the setXXX return values, anyway.
Add a CoreMutex class which implements a deadlock-safe mutex and reqork
the SerialUSB and SerialUART classes to use it to synchronize output
when in a multicore sketch.
Use a constexpr template to calculate the valid pins for different IO
hardware. This lets us have an easily readable list of pin numbers that
we can adjust/check.
