* Move to Arduino API 10501
Track upstream Arduino API headers
* IPAddress V4/V6 compatiblity restored
* Fix WiFiUDP includes
* String differences in example
* HardwareSerial using exported
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.
* Update to 2.0.0 SDK
* Board type needs to be set before earliest SDK setup
* Platform includes update
* Boot2 files
* Simple compilation issues
* Build and link
* PIO rebuild with version
* Newlib wrapper update
* Force inclusion of runtime_init_* fcns
The linker was dropping all references to the library's included
runtime_init_xxx functions and hence things like the IRQ vector
table and mutexes and alarms weren't properly set up leading to
instant crashes on start up..
Explicitly call out one function from the object file stored in
the .A to force the inclusion of all the functions. May be a better
way, heppy to hear any ideas.
* Fix SPI GPIO calls
* Fix Ethernet GPIO
* Remove SDK warnings
Remove the skipped error messages once the following PR merged:
https://github.com/raspberrypi/pico-sdk/pull/1786
* BTStack moved SBC encode/decode paths
* Platform.IO fixes
* BT No longer has special absolute mouse
* Rebuild and update OTA
* Rebuild BearSSL, too
* Update liker file to latest SDK
* Clean up libpicocmake
* Clean up LWIP/BT library names
* 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/
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
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.