* 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
The Arduino WiFi normalization ended up calling the underlying LWIP
::config after the AP was begin, resulting in a failure to set the
IP configuration of the AP. Move the _wifi.begin() call to after
the IP configuration is set.
Fixes#1989
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
If another packet comes in between freeing `_rx_buf` and setting `_rx_buf` to 0, that new packet could get put into the same memory address and get concatenated to itself, which leads to an infinite loop.
New solution assigns a temp pointer, sets `rx_buf` to 0, then frees the memory, which guarantees `_rx_buf` always points to valid data.
Fixes#1408
The wl_* types are required in multiple libraries which in turn seem
to have a circular dependency that Platform.IO has issues with in certain
modes.
Avoid the issue by moving the common headers into the core directories
so they will be accessible by all libs.
Move StackThunk to core directory, too
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
Only 4K total stack, so allocating 400 bytes for a local C string
or 600 bytes for a DHCP response is dangerous. Use static allocations
instead on the heap.
Other parts of the core use temp 256 byte chunks to transmit/move/operate
on data, so do the same here. Will increase effective WebServer sendFile
speeds.
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
* Add HTTP-parser lib to support ESP32 WebServer
* Add WebServer from ESP32. Only supports HTTP
* Separate HTTP server from the network server
Instead of managing the WiFiServer/WiFiServerSecure in the same object
as the HTTP handling, split them into separate objects. This lets
HTTP and HTTPS servers work without templates or duplicating code.
The HTTP block just gets a `WiFiClient*` and works with that to only
do HTTP processing, while the upper object handles the appropriate
server and client types.
* Add HTTPS server
* Clean up some THandlerFunction refs
* Refactor into a template-ized WebServer/WebServerSecure
* Add DNSServer examples which need WebServer
* Fix CoreMutex infinite recursion crash
Core could crash while Serial debugging was going on and prints were
happening from LWIP/IRQ land and the main app.
* Add HTTPUpdateServer(Secure)
* Add MIME include, optimize WebServer::send(size,len)
When send()ing a large buffer, the WebServer::send() call would
actually convert that buffer into a String (i.e. duplicate it, and
potential issues with embedded \0s in binary data).
Make a simple override to send(size, len) to allow writing from the
source buffer instead.
* Fix WiFiClient::send(Stream), add FSBrowser example
* Add HTTPUpdate class to pull updates from HTTP(S)
* Increase GH runners for pulls
WiFi builds and examples are taking some serious time now
* HTTPUpdate tests build on Pico W
Remove the need to have a separate WiFiClient that's destroyed after
the HTTPClient. Let the object handle its own client, and pass through
any SSL requests.
Also supports the original ::begin methods which need a
WiFiClient(Secure) to be passed in and managed by the app.
