Using pico-sdk develop branch, add in support for CYW43-based
WiFi/BT/BLE boards on the RP2350 such as the
SparkFun Thing Plus RP2350 or the Pimoroni Pico Plus 2W.
Fixes#2608
Rolls in dynamic SPI divider #2600
* Support LED digitalWrite on RP2350+CYW
Also move "special GPIO" to 64 since the Pimoroni Pico 2W uses the
RP2350B with 48 GPIOs.
* Enable CYW43_PIN_WL_DYNAMIC in IDE and P.IO
Allows calling `cyw43_set_pins_wl(cyw43_pin_array);` to redefine the
CYW43 hookup in the variant initialization.
* Migrate RP2040-specific bits to separate dirs
* Add chip to boards.txt, isolate RP2040-specifics
* Add RP2350 boot2, bearssl, and libraries
* Platform.IO adjust to new paths
* Add RPIPICO2 JSON for P.IO
* Add RP2350 to Platform.io
* Update Picotool and OpenOCD for all hosts
* Use picotool to generate UF2s
* Build separate libpico blobs serially
Thanks for the review, @aarturo182 !
* Add RP2350 to CI
* Allow Ethernet/WiFi building for RP2350
* Update Adafruit TinyUSB to latest
* Test skip fix
* Make RP2350 Picotool work. update USB ID
* Fix EEPROM/FS flash locations
RP2350 adds a 4K header sector to the UF2, meaning we have 4K less total
flash to work with. Adjust all constants appropriately on the RP2350.
* Adds ilabs board and PSRAM support. (#2342)
* Adds iLabs boards and basic PSRAM support.
* Make PSRAM come up as part of chip init
Uses SparkFun psram.cpp to set timings on clocks which are defined in the
variant file. Prefix things with RP2350_PSRAM_xxx for sanity.
Users don't need to call anything, PSRAM "just appears". Still need to
add in malloc-type allocation.
* Add board SparkFun ProMicro RP2350
Same pinout as the SparkFun ProMicro RP2040 with 8MB PSRAM and RP2350
* Add TLSF library for use w/PSRAM
Fork of upstream to include add'l C++ warning fixes.
* Add pmalloc/pcalloc to use PSRAM memory
free() and realloc() all look at the pointer passed in and jump to the
appropriate handler. Also takes care of stopping IRQs and taking the
malloc mutex to support multicore and FreeRTOS (when that workd)
* Fix BOOTSEL for RP2350
* Add simple rp2040.idleOtherCore test
* Add Generic RP2350 and clean up PSRAM menus
Commercial boards now only have 1 size PSRAM, no need to have menu for them.
* Add Solder Party RP2350 Stamp boards (#2352)
* Add PSRAM heap info helpers, mutex lock mallinfo
* Add RP2350 docs
* FreeRTOS and OTA unsupported warnings for RP2350
As seen in debug of #2149, if the LwipIntfDev is already _started,
return false for a ::begin() call.
Also, protect netif_add/_remove on the very small possibilty of being
called by LwipIntfDev devices while the CYW43 driver is doing work.
No polling needed and massively reduces latency by using the GPIO interrupt to
signal the Pico to read a received packet. Also drops CPU load when no packets
are incoming.
Avoid issues with interrupts and priority inversions and other deadlocks
and use a SW based random generator for LWIP when under FreeRTOS.
This means removing any overrides for sleep_until and the two
get_rand_xx calls from the SDK, making things much saner.
Related to #1883, #1872, and other random FreeRTOS lockups.
Enable use of wired Ethernet modules as first-class LWIP citizens. All
networking classes like MDNS, WebServer, HTTPClient, WiFiClient, and OTA
can use a wired Ethernet adapter just like built-in WiFi.
Two examples updated to show proper use.
Uses the Async Context support built into the Pico SDK. When running on the
Pico it will use the CYW43 async instance.
Uses modified wired Ethernet drivers, thanks Nicholas Humfrey!
Note, the classic, non-LWIP integrated `Ethernet` and related libraries
should still work fine (but not be able to use WebServer/HTTPS/etc.)
Fixes#775
It seems possible now for TCP connection _pcbs to disappear while being
processed, due to the new async context configuration. This would cause
LWIP to panic when a NULL pcb was passed in.
Check for and avoid passing in null PCBs in the ClientContext.
Undo special-casing of sys_check_timeouts wrapper
AdvancedWebServer with heavy F5-refresh and #1274 test both pass.
Fixes#1274
* Update to Pico-SDK v1.5
* Hook in pico_rand, use ioctl to set ipv6 allmulti
* Move into PicoSDK LWIP mutex, hack timer sizes
* Utilize much of the PicoSDK infrastructure for WiFi
* Add WiFi::begin(ssid, pass, bssid)
* WiFiMulti to use BSSID, make more robust
WiFiMulti will now be more aggressive and try all matching SSIDs, in order
of RSSI, using the BSSID to identify individual APs in a mesh.
Before, if the highest RSSI AP didn't connect, it would fail immediately.
Now, it will go down the list, ordered by RSSI, to attempt to get a link.
* Add Bluetooth support from Pico-SDK
Able to build and run the HID Keyboard Demo from the Arduino IDE, almost
as-is.
Will probably need to make BT configurable. Enabling BT on a plain WiFi
sketch uses 50KB of flash and 16KB of RAM even if no BT is used.
* Separate picow libs, BT through menus, example
Build normal Pico.a and 4 different options for PicoW IP/BT configuration.
Use IP=>IP/Bluetooth menu to select between options.
* CMakefile rationalization
* Move BT TLV(pairing) out of last 2 flash sectors
The pairing keys for BT are stored at the end of flash by default, but
we use the last sector of flash for EPROM and the penultimate one for
the filesystem. Overwriting those in BT could cause some real exciting
crashes down the line.
Move the store to an app-build specific address using a dummy const
array to allocate space in the application image itself.
* PicoBluetoothHID with BT Mouse, Joystick, Keyboard
Add simple Bluetooth Classic HID helper function and port the existing
USB HID devices to it. Port their examples.
* Protect BT key storage from multicore
* Add short-n-sweet Bluetooth documents
* Add Bluetooth Serial port library
* Turn off BT when the BT libraries exit
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
