Add support for the WiFi chip on the Pico W board.
Works well enough for experimental use
To Do: [X] Update LWIP options (now it is the default example one [X] Add WiFi class [X] Add WiFi client class [X] Add support classes (DNS, etc.) [X] Add WiFi server class [X] Add AP mode [X] Examples [X] Docs (such as they are...)
USB interrupt now no longer hard coded (conflicted with the WiFi IRQ).
Add in Pico W board to makeboards.py
Add in GPIO and variant support
Initialize WiFi in the Variant
Use manual LWIP, fix size accounting
Remove the SDK WiFi overrides
Pulling in work done in the ESP8266 core.
Make IPAddress support IPv6
Build LWIP with IPv4 and IPv6 support
Use proper MAC
Avoid cyw_warn crash. Make macro to a comment while building
Add support for the WiFi chip on the Pico W board.
Works well enough for experimental use
To Do:
`[X]` Update LWIP options (now it is the default example one
`[X]` Add WiFi class
`[X]` Add WiFi client class
`[X]` Add support classes (DNS, etc.)
`[X]` Add WiFi server class
`[X]` Add AP mode
`[X]` Examples
`[X]` Docs (such as they are...)
* USB interrupt now no longer hard coded (conflicted with the WiFi IRQ).
* Add in Pico W board to makeboards.py
* Add in GPIO and variant support
* Initialize WiFi in the Variant
* Use manual LWIP, fix size accounting
* Remove the SDK WiFi overrides
* Pulling in work done in the ESP8266 core.
* Make IPAddress support IPv6
* Build LWIP with IPv4 and IPv6 support
* Use proper MAC
* Avoid cyw_warn crash. Make macro to a comment while building
* Add WiFiServer
* Add WiFiUdp
* Move LWIP-specific support files to LWIP_Ethernet
* Add WiFi::ping (ICMP ping)
* Move ICMP echo (ping) to LWIPIntfDev
* Move hostByName to LwipIntfDev
* Add AP Mode
Eventually...
Fixes #666
Fixed #665
Fantastic!
I was just thinking how it would be nice to have support for Pico W. I'm
looking forward to working with this project.
Gavin
On Wed, Jul 6, 2022, 11:42 PM Earle F. Philhower, III < @.***> wrote:
Add support for the WiFi chip on the Pico W board.
Presently the libpico.a builds and runs the simple picow_blink and
wifi_scan
examples as sketches.
To Do:
[ ] Update LWIP options (now it is the default example one
[ ] Add WiFi class
[ ] Add WiFi client class
[ ] Add support classes (DNS, etc.)
[ ] Add WiFi server class
[ ] Add AP mode
USB interrupt now no longer hard coded (conflicted with the WiFi IRQ).
Remove obsolete pico_audio depends in libpico build
Fantastic!
I was just thinking how it would be nice to have support for Pico W. I'm
looking forward to working with this project.
Gavin
On Wed, Jul 6, 2022, 11:42 PM Earle F. Philhower, III <
***@***.***> wrote:
> Add support for the WiFi chip on the Pico W board.
>
> Presently the libpico.a builds and runs the simple picow_blink and
> wifi_scan
> examples as sketches.
>
> To Do:
> [ ] Update LWIP options (now it is the default example one
> [ ] Add WiFi class
> [ ] Add WiFi client class
> [ ] Add support classes (DNS, etc.)
> [ ] Add WiFi server class
> [ ] Add AP mode
>
> USB interrupt now no longer hard coded (conflicted with the WiFi IRQ).
>
> Remove obsolete pico_audio depends in libpico build
>
> Eventually...
> Fixes #666 <https://github.com/earlephilhower/arduino-pico/issues/666>
> Fixed #665
> <https://github.com/earlephilhower/arduino-pico/discussions/665>
> ------------------------------
> You can view, comment on, or merge this pull request online at:
>
> https://github.com/earlephilhower/arduino-pico/pull/670
> Commit Summary
>
> - 4651ee0
> <https://github.com/earlephilhower/arduino-pico/pull/670/commits/4651ee0ca03873b9bfc3fa79f25dcebdf4d2a98f>
> WIP - Add Pico W support
>
> File Changes
>
> (7 files <https://github.com/earlephilhower/arduino-pico/pull/670/files>)
>
> - *M* cores/rp2040/RP2040USB.cpp
> <https://github.com/earlephilhower/arduino-pico/pull/670/files#diff-895d5d64a79f1971416120f92c7b4a3fe2b79cf5aa6c8de8a67373fbcae2a671>
> (9)
> - *M* lib/libpico.a
> <https://github.com/earlephilhower/arduino-pico/pull/670/files#diff-e1b4283e55150c8bade35c9a89635b636b0abfccdd57a06ab8451fe073586c4c>
> (0)
> - *M* lib/pico_base/pico/version.h
> <https://github.com/earlephilhower/arduino-pico/pull/670/files#diff-4de765c6f9a416836cae01cd650bb384b4589dfc72b2fc4154b0f980a182d276>
> (6)
> - *M* lib/platform_inc.txt
> <https://github.com/earlephilhower/arduino-pico/pull/670/files#diff-874a1bc0293c43c245112de6f8f7d39be7e2723704244521a4e933bcf66c9e64>
> (5)
> - *M* pico-sdk
> <https://github.com/earlephilhower/arduino-pico/pull/670/files#diff-edd81cb855eab43039e7f24a557786391c6032b6adf2139e446b703ecbc0d60d>
> (2)
> - *M* tools/libpico/CMakeLists.txt
> <https://github.com/earlephilhower/arduino-pico/pull/670/files#diff-d0d48a8d47fd5d31e3bc70b12159bdcb23a5ab82460bb5972cf61776f4d6768a>
> (6)
> - *A* tools/libpico/lwipopts.h
> <https://github.com/earlephilhower/arduino-pico/pull/670/files#diff-e11daee00d725cd98b2550458803489a8851c68d849e273105eca846e8d5a51e>
> (90)
>
> Patch Links:
>
> - https://github.com/earlephilhower/arduino-pico/pull/670.patch
> - https://github.com/earlephilhower/arduino-pico/pull/670.diff
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/earlephilhower/arduino-pico/pull/670>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AVR4PP4JDZHSXXFF4DRWEL3VSZN35ANCNFSM5236XPIQ>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
@earlephilhower
I am looking so damn forward to the Wifi and helper classes, this will be a game changer for my project to finally get away from the expensive Arduino Nano RP2040 Connect.
Pretty please do not forget about a UDP helper class.
Thank you! <3
@earlephilhower
I am looking so damn forward to the Wifi and helper classes, this will be a game changer for my project to finally get away from the expensive Arduino Nano RP2040 Connect.
Pretty please do not forget about a UDP helper class.
Thank you! <3
Eventually, yes. WiFi needs to be stable first, of course. A 2nd stage bootloader w/either FS access or a special OTA region could then either copy a new image or execute the existing code. Probably lose 16K of code space if I go for LittleFS "firmware.bin" or 8K if I stick w/a dumb OTA set-aside.
Pretty please do not forget about a UDP helper class.
It will be there, for sure. Once LWIP is up and good, UDP is pretty straightforward.
> Are there plans for pico W ota support?
Eventually, yes. WiFi needs to be stable first, of course. A 2nd stage bootloader w/either FS access or a special OTA region could then either copy a new image or execute the existing code. Probably lose 16K of code space if I go for LittleFS "firmware.bin" or 8K if I stick w/a dumb OTA set-aside.
> Pretty please do not forget about a UDP helper class.
It will be there, for sure. Once LWIP is up and good, UDP is pretty straightforward.
That sounds great. With OTA I'll finally be able to streamline a few of my projects. Specifically the waveshare pico clock green. Im looking to eventually have it running esphome, and integrated into my automations as a notification sink
That sounds great. With OTA I'll finally be able to streamline a few of my projects. Specifically the [waveshare pico clock green](https://www.waveshare.com/wiki/Pico-Clock-Green). Im looking to eventually have it running esphome, and integrated into my automations as a notification sink
It will be there, for sure. Once LWIP is up and good, UDP is pretty straightforward.
You, sir, are a real magican, tipping my virtual hat.
Would you have a "buy me a coffee"-link?
>> It will be there, for sure. Once LWIP is up and good, UDP is pretty straightforward.
You, sir, are a real magican, tipping my virtual hat.
Would you have a "buy me a coffee"-link?
At this point WiFi, WiFiClient, WiFiUdp are stable enough to try out. AP mode is not yet in, of course. WiFiServer runs and connect when pinged, but I am having issues w/multiple connections so consider that unstable for now.
At this point `WiFi`, `WiFiClient`, `WiFiUdp` are stable enough to try out. AP mode is not yet in, of course.
`WiFiServer` runs and connect when pinged, but I am having issues w/multiple connections so consider that unstable for now.
@earlephilhower
I've downloaded the "wifi" branch and replaced all files of my existing 2.2.2 stable install with those files,
after that I downloaded the pico-sdk you are using in your wifi-branch and overwrote the files in the pico-sdk
folder with the newer ones.
I don't see what I am missing here as I cannot get it to work, when trying to compile I'm getting: In file included from C:\Users\Stefan\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\2.2.2\cores\rp2040/api/ArduinoAPI.h:30, from C:\Users\Stefan\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\2.2.2\cores\rp2040/Arduino.h:28, from sketch\SRGBmods_Wifi_LED_Controller_TX_1657348902.ino.cpp:1: C:\Users\Stefan\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\2.2.2\cores\rp2040/api/IPAddress.h:26:10: fatal error: lwip/init.h: No such file or directory 26 | #include <lwip/init.h> | ^~~~~~~~~~~~~ compilation terminated. exit status 1 Error compiling for board Raspberry Pi Pico W.
Any ideas what I am missing? Thanks!
@earlephilhower
I've downloaded the "wifi" branch and replaced all files of my existing 2.2.2 stable install with those files,
after that I downloaded the pico-sdk you are using in your wifi-branch and overwrote the files in the pico-sdk
folder with the newer ones.
I don't see what I am missing here as I cannot get it to work, when trying to compile I'm getting:
`In file included from C:\Users\Stefan\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\2.2.2\cores\rp2040/api/ArduinoAPI.h:30,
from C:\Users\Stefan\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\2.2.2\cores\rp2040/Arduino.h:28,
from sketch\SRGBmods_Wifi_LED_Controller_TX_1657348902.ino.cpp:1:
C:\Users\Stefan\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\2.2.2\cores\rp2040/api/IPAddress.h:26:10: fatal error: lwip/init.h: No such file or directory
26 | #include <lwip/init.h>
| ^~~~~~~~~~~~~
compilation terminated.
exit status 1
Error compiling for board Raspberry Pi Pico W.
`
Any ideas what I am missing? Thanks!
You need to use a git install, not a downloaded .ZIP. They never seem to work because they are missing many dependencies.
You can use the guide in the README, it's still valid, and then check out the wifi branch.
You need to use a `git` install, not a downloaded .ZIP. They never seem to work because they are missing many dependencies.
You can use the guide in the README, it's still valid, and then check out the `wifi` branch.
You need to use a git install, not a downloaded .ZIP. They never seem to work because they are missing many dependencies.
You can use the guide in the README, it's still valid, and then check out the wifi branch.
Ah, I see, will try that when I get home from work, thank you sir!
> You need to use a `git` install, not a downloaded .ZIP. They never seem to work because they are missing many dependencies.
>
> You can use the guide in the README, it's still valid, and then check out the `wifi` branch.
Ah, I see, will try that when I get home from work, thank you sir!
@earlephilhower Are you planning to add WiFiClientSecure? I don't see it in the TODOs and it's essential for most IoT projects and platforms in 2022.
@earlephilhower Are you planning to add `WiFiClientSecure`? I don't see it in the TODOs and it's essential for most IoT projects and platforms in 2022.
@brentru Absolutely! I need to get a baseline out there first and not try to boil the ocean for now. When I did the BEarSSL port for the ESP8266 I didn't have to worry about the wifi chip or LWIP, but now I'm have to figure out the whole stack from radio to socket, so it's a bit of a trudge. Once the Client is stable, adding SSL should be "easy" if I use our BEarSSL client from the ESP8266.
@brentru Absolutely! I need to get a baseline out there first and not try to boil the ocean for now. When I did the BEarSSL port for the ESP8266 I didn't have to worry about the wifi chip or LWIP, but now I'm have to figure out the whole stack from radio to socket, so it's a bit of a trudge. Once the Client is stable, adding SSL should be "easy" if I use our BEarSSL client from the ESP8266.
@earlephilhower
I tried with your short git instructions from the readme and it indeed compiled, so one step forward.
BUT Windows immediately says that the device isn't working after flashing the Pico W.
I'm using TinyUSB to use the Pico as a USB HID device, same sketch with Arduino Nano RP2040 Connect and WiFiNINA instead works fine. Not sure what I did wrong, but I will take a closer look later.
@earlephilhower
I tried with your short git instructions from the readme and it indeed compiled, so one step forward.
BUT Windows immediately says that the device isn't working after flashing the Pico W.
I'm using TinyUSB to use the Pico as a USB HID device, same sketch with Arduino Nano RP2040 Connect and WiFiNINA instead works fine. Not sure what I did wrong, but I will take a closer look later.
Try the basic Blink.ino from the examples (making sure the chip is set to PicoW). That verifies basic WiFi chip integration since it requires a 220KB blob and 5k lines of code to drive the onboard LED. :)
Try the basic Blink.ino from the examples (making sure the chip is set to PicoW). That verifies basic WiFi chip integration since it requires a 220KB blob and 5k lines of code to drive the onboard LED. :)
@FeuerSturm I've just included some UDP, WiFiClient, and network scan tests I'm running here. Give those a try,,,
@earlephilhower will do right now, thanks!
> @FeuerSturm I've just included some UDP, WiFiClient, and network scan tests I'm running here. Give those a try,,,
@earlephilhower will do right now, thanks!
@earlephilhower
Tried the ScanNetworks example, works perfect when using Pico-SDK usb stack, as soon as I try to use any sketch with TinyUSB usb stack, windows says the device isn't working...
@earlephilhower
Tried the ScanNetworks example, works perfect when using Pico-SDK usb stack, as soon as I try to use
**any** sketch with TinyUSB usb stack, windows says the device isn't working...
I don't run the Adafruit stack, so thanks for pointing that out.
I think they have the same "bug" that I did WRT the USB Irq. They picked a fixed IRQ # and it conflicts with the PICO SDK's choice for the WiFi chip. I'll send a PR their way after work. Just need to let the SDK give it an IRQ # via a simple call instead of using a #define. (The #define was fine before, of course, since the SDK didn't use that IRQ until 1.4.0)
I don't run the Adafruit stack, so thanks for pointing that out.
*I think* they have the same "bug" that I did WRT the USB Irq. They picked a fixed IRQ # and it conflicts with the PICO SDK's choice for the WiFi chip. I'll send a PR their way after work. Just need to let the SDK give it an IRQ # via a simple call instead of using a `#define`. (The `#define` was fine before, of course, since the SDK didn't use that IRQ until 1.4.0)
I don't run the Adafruit stack, so thanks for pointing that out.
They have the same "bug" that I did WRT the USB Irq. They picked a fixed IRQ # and it conflicts with the PICO SDK's choice for the WiFi chip. I'll send a PR their way after work. Just need to let the SDK give it an IRQ # via a simple call instead of using a #define. (The #define was fine before, of course, since the SDK didn't use that IRQ until 1.4.0)
Ah, great, already thought I am too stupid to set this up :)
> I don't run the Adafruit stack, so thanks for pointing that out.
>
> They have the same "bug" that I did WRT the USB Irq. They picked a fixed IRQ # and it conflicts with the PICO SDK's choice for the WiFi chip. I'll send a PR their way after work. Just need to let the SDK give it an IRQ # via a simple call instead of using a `#define`. (The `#define` was fine before, of course, since the SDK didn't use that IRQ until 1.4.0)
Ah, great, already thought I am too stupid to set this up :)
@FeuerSturm if you pull the latest patch and git submodule update it will pull in the fixed TinyUSB libs
@earlephilhower
That indeed brought it to life!
It connects to my network fine, but I noticed 2 things that don't work:
setHostname - it is not using the hostname I told it to use const char TXHostname[] = "SRGBmods-WLC-Nanoleaf"; WiFi.setHostname(TXHostname); WiFiStatus = WiFi.begin(ssid, pass);
second thing I noticed, is that "hooking" into the WifiClient doesn't seem to work:
I'm using this HTTPClient lib for easy use of some GET and PUT requests: https://github.com/arduino-libraries/ArduinoHttpClient
"Requires a networking hardware and a library that provides transport specific Client instance"
That works fine with WiFiNINA and the Nano RP2040 Connect as well.
I know it's still early development, just thought I'd mention it.
Great job so far, once again tipping my virtual hat.
> @FeuerSturm if you pull the latest patch and `git submodule update` it will pull in the fixed TinyUSB libs
@earlephilhower
That indeed brought it to life!
It connects to my network fine, but I noticed 2 things that don't work:
- setHostname - it is **not** using the hostname I told it to use
` const char TXHostname[] = "SRGBmods-WLC-Nanoleaf";
WiFi.setHostname(TXHostname);
WiFiStatus = WiFi.begin(ssid, pass);`
- second thing I noticed, is that "hooking" into the WifiClient doesn't seem to work:
I'm using this HTTPClient lib for easy use of some GET and PUT requests:
https://github.com/arduino-libraries/ArduinoHttpClient
"Requires a networking hardware and a library that provides transport specific Client instance"
That works fine with WiFiNINA and the Nano RP2040 Connect as well.
I know it's still early development, just thought I'd mention it.
Great job so far, once again tipping my virtual hat.
second thing I noticed, is that "hooking" into the WifiClient doesn't seem to work: (AtdhionHTTPClient example)
Actually, that works fine but it seems the Arduino WIFI and the ESP8266 WIFI disagree about Wifi.begin().
On the ESP8266 where I come from, Wifi.begin() returns immediately once the network link is up. To check for IP yopu need top wait for WiFi.state() == WL_CONNECTED.
Looks likt other WIFIs wait for network AND IP before returning.
For now, just add
while ( WiFi.status() != WL_CONNECTED) {
Serial.printf(".");
delay(100);
}
after the while (!WiFi.begin()) loop and everything works fine.
The SimpleHttpExample from ArduinoHttpClient was modded:
void setup()
{
//Initialize serial and wait for port to open:
Serial.begin(9600);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}
// attempt to connect to WiFi network:
Serial.print("Attempting to connect to WPA SSID: ");
Serial.println(ssid);
while (WiFi.begin(ssid, pass) != WL_CONNECTED) {
// unsuccessful, retry in 4 seconds
Serial.print("failed ... ");
delay(4000);
Serial.print("retrying ... ");
}
while ( WiFi.status() != WL_CONNECTED) {
Serial.printf(".");
delay(100);
}
Serial.println("connected");
}
And the output is:
Attempting to connect to WPA SSID: NOBABIES
........................................................connected
startedRequest ok
Got status code: 301
Content length is: 184
Body returned follows:
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.4.2</center>
</body>
</html>
> second thing I noticed, is that "hooking" into the WifiClient doesn't seem to work: (AtdhionHTTPClient example)
Actually, *that* works fine but it seems the Arduino WIFI and the ESP8266 WIFI disagree about `Wifi.begin()`.
On the ESP8266 where I come from, `Wifi.begin()` returns immediately once the network link is up. To check for IP yopu need top wait for `WiFi.state() == WL_CONNECTED`.
Looks likt other WIFIs wait for network AND IP before returning.
For now, just add
```
while ( WiFi.status() != WL_CONNECTED) {
Serial.printf(".");
delay(100);
}
````
after the `while (!WiFi.begin())` loop and everything works fine.
The SimpleHttpExample from ArduinoHttpClient was modded:
````
void setup()
{
//Initialize serial and wait for port to open:
Serial.begin(9600);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}
// attempt to connect to WiFi network:
Serial.print("Attempting to connect to WPA SSID: ");
Serial.println(ssid);
while (WiFi.begin(ssid, pass) != WL_CONNECTED) {
// unsuccessful, retry in 4 seconds
Serial.print("failed ... ");
delay(4000);
Serial.print("retrying ... ");
}
while ( WiFi.status() != WL_CONNECTED) {
Serial.printf(".");
delay(100);
}
Serial.println("connected");
}
````
And the output is:
````
Attempting to connect to WPA SSID: NOBABIES
........................................................connected
startedRequest ok
Got status code: 301
Content length is: 184
Body returned follows:
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.4.2</center>
</body>
</html>
````
@earlephilhower
I do have checks in place if the wifi connection is established and I'm not trying to do anything before this is the case.
I will revise my code and try again once I get home from work. Thanks!
@earlephilhower
I do have checks in place if the wifi connection is established and I'm not trying to do anything before this is the case.
I will revise my code and try again once I get home from work. Thanks!
@earlephilhower
setHostname now works perfect, thanks for that!
I still cannot get the HTTP PUT / GET to work without any code changes when migrating from Nano RP2040 Connect / WiFiNINA though, I'll have to investigate what's wrong as it works fine as it is when I plug in the Nano and recompile...
@earlephilhower
setHostname now works perfect, thanks for that!
I still cannot get the HTTP PUT / GET to work without any code changes when migrating from Nano RP2040 Connect / WiFiNINA though, I'll have to investigate what's wrong as it works fine as it is when I plug in the Nano and recompile...
@earlephilhower
I've been running some example and it seems that the Arduino HTTP Client lib is not the problem,
all the examples worked fine.
I'm using ArduinoJSON in conjunction with the HTTP Client lib to extract some required information from an API,
that seems to be the problem as the Pico W is hanging as soon as the code hits that part.
I've tried with both of the Ethernet MCUs (WIZnet W5100S-EVB-Pico + WIZnet W5500-EVB-Pico) that I own, it's
exactly the same problem, MCUs get unresponsive, so it's for sure not a problem with your Wifi lib.
This is where it hangs, no idea why the Nano RP2040 Connect works fine with this but every other MCU I tried doesn't: loop_codepart.txt
I guess I will have to do some extensive trial and error.
Thanks for your help and sorry for the confusion!
@earlephilhower
I've been running some example and it seems that the Arduino HTTP Client lib is not the problem,
all the examples worked fine.
I'm using ArduinoJSON in conjunction with the HTTP Client lib to extract some required information from an API,
that seems to be the problem as the Pico W is hanging as soon as the code hits that part.
I've tried with both of the Ethernet MCUs (WIZnet W5100S-EVB-Pico + WIZnet W5500-EVB-Pico) that I own, it's
exactly the same problem, MCUs get unresponsive, so it's for sure not a problem with your Wifi lib.
This is where it hangs, no idea why the Nano RP2040 Connect works fine with this but every other MCU I tried doesn't:
[loop_codepart.txt](https://github.com/earlephilhower/arduino-pico/files/9098940/loop_codepart.txt)
I guess I will have to do some extensive trial and error.
Thanks for your help and sorry for the confusion!
@FeuerSturm your problem is simple: You're overflowing the stack. The Pico has 4K per core and you're allocating 30KB+ of JSON and overflowing it.
Look at either globals or using heap allocated (i.e. new ArduinoJSON<xxxx> x; ......; .delete x
@FeuerSturm your problem is simple: You're overflowing the stack. The Pico has 4K per core and you're allocating 30KB+ of JSON and overflowing it.
Look at either globals or using heap allocated (i.e. `new ArduinoJSON<xxxx> x; ......; .delete x `
@FeuerSturm your problem is simple: You're overflowing the stack. The Pico has 4K per core and you're allocating 30KB+ of JSON and overflowing it.
Look at either globals or using heap allocated (i.e. new ArduinoJSON<xxxx> x; ......; .delete x
@earlephilhower
Yes, you are absolutely right, I am an idiot, will revise and try again.
Thank you <3
> @FeuerSturm your problem is simple: You're overflowing the stack. The Pico has 4K per core and you're allocating 30KB+ of JSON and overflowing it.
>
> Look at either globals or using heap allocated (i.e. `new ArduinoJSON<xxxx> x; ......; .delete x `
@earlephilhower
Yes, you are absolutely right, I am an idiot, will revise and try again.
Thank you <3
@earlephilhower
I'm seriously out of ideas now, I've changed the JSON doc to be dynamic so it uses the heap instead of the stack and reduced it's size ALOT. I still cannot get it to work, so I added some debug messages and this is strange:
Same sketch compiled for Nano RP2040 Connect and WiFiNINA still works flawless and takes around 6sec to GET/PUT several settings and deserialize the JSON received by the Nanoleaf API.
The Pico W needs twice the time to get/put the settings and immediately disables UDP mode (should only happen if not receiving USB HID packets for more than 5sec) and resets to the previously acquired settings and goes unresponsive: serialmonitor_debug.txt
This is my "optimized" loop code, would you have anymore ideas? loop_codev2.txt
Thanks in advance!
@earlephilhower
I'm seriously out of ideas now, I've changed the JSON doc to be dynamic so it uses the heap instead of the stack and reduced it's size ALOT. I still cannot get it to work, so I added some debug messages and this is strange:
Same sketch compiled for Nano RP2040 Connect and WiFiNINA still works flawless and takes around 6sec to GET/PUT several settings and deserialize the JSON received by the Nanoleaf API.
The Pico W needs twice the time to get/put the settings and immediately disables UDP mode (should only happen if not receiving USB HID packets for more than 5sec) and resets to the previously acquired settings **and goes unresponsive**:
[serialmonitor_debug.txt](https://github.com/earlephilhower/arduino-pico/files/9105284/serialmonitor_debug.txt)
This is my "optimized" loop code, would you have anymore ideas?
[loop_codev2.txt](https://github.com/earlephilhower/arduino-pico/files/9105288/loop_codev2.txt)
Thanks in advance!
Sorry, but there's nothing in the snippet that stands out. I suggest hooking up GDB and a PicoProbe which will help pinpoint any crashes and let you dig deeper into the problem.
Sorry, but there's nothing in the snippet that stands out. I suggest hooking up GDB and a PicoProbe which will help pinpoint any crashes and let you dig deeper into the problem.
Sorry, but there's nothing in the snippet that stands out. I suggest hooking up GDB and a PicoProbe which will help pinpoint any crashes and let you dig deeper into the problem.
I will further optimize the code and will move acquiring the config and settings to setup instead of loop, I suspect that I am overloading it somehow with all the http get/put requests while it already receives USB HID packets and works with them. Will see if that helps.
Thanks!
> Sorry, but there's nothing in the snippet that stands out. I suggest hooking up GDB and a PicoProbe which will help pinpoint any crashes and let you dig deeper into the problem.
I will further optimize the code and will move acquiring the config and settings to setup instead of loop, I suspect that I am overloading it somehow with all the http get/put requests while it already receives USB HID packets and works with them. Will see if that helps.
Thanks!
@earlephilhower
Almost forgot that:
I tried my other project that doesn't use ArduinoJSON and Arduino HTTPClient and that worked perfect.
Tested and working flawless:
connect to existing WiFi
set DHCP hostname
resolve hostnames to IPs
send UDP packets
Awesome job, thanks a lot!
@earlephilhower
Almost forgot that:
I tried my other project that doesn't use ArduinoJSON and Arduino HTTPClient and that worked perfect.
Tested and working flawless:
- connect to existing WiFi
- set DHCP hostname
- resolve hostnames to IPs
- send UDP packets
Awesome job, thanks a lot!
@FeuerSturm thanks for the feedback! You should pull down the latest patch. UDP wouldn't care, but for TCP there was a problem where it would retransmit packets and get out of sequence because of a silly error in the device driver. Not saying it will fix your other problem, only that it will help remove some potential faults. :)
@FeuerSturm thanks for the feedback! You should pull down the latest patch. UDP wouldn't care, but for TCP there was a problem where it would retransmit packets and get out of sequence because of a silly error in the device driver. Not saying it will fix your other problem, only that it will help remove some potential faults. :)
@earlephilhower
Those latest changes indeed fixed the "Pico W needs twice the time" problem and I found the other problem that caused it to become unresponsive.
It was once again me being an idiot, I tried to toggle on/off the onboard led way to frequently which caused it to hang.
All in all, everything is working right now!
Thanks a lot for your help! <3
@earlephilhower
Those latest changes indeed fixed the "Pico W needs twice the time" problem and I found the other problem that caused it to become unresponsive.
It was once again me being an idiot, I tried to toggle on/off the onboard led way to frequently which caused it to hang.
**All in all, everything is working right now!**
Thanks a lot for your help! <3
@earlephilhower
I'm excited for this to go live!
You've done an outstanding job with this, thanks a lot, seriously appreciated!
P.S.:
Tested AP mode as well, works perfect as well from what I could test (connected to it with my phone without a problem).
@earlephilhower
I'm excited for this to go live!
You've done an outstanding job with this, thanks a lot, seriously appreciated!
P.S.:
Tested AP mode as well, works perfect as well from what I could test (connected to it with my phone without a problem).
I think I will do a merge and release, and then work on the secure TLS/https stuff over the weekend. It's already a 7,500+ line PR!
Thx again for the updates, @FeuerSturm .
I think I will do a merge and release, and then work on the secure TLS/https stuff over the weekend. It's already a 7,500+ line PR!
I think I will do a merge and release, and then work on the secure TLS/https stuff over the weekend. It's already a 7,500+ line PR!
@earlephilhower
If that helps, I tested all of your examples, they all worked flawless.
Additionally I tested all the stuff that I need for my projects, since the latest changes you did, that all works perfect as well.
I currently have my Pico W running for almost 7 hours without the slightest problem, connection is stable, no disconnects.
> Thx again for the updates, @FeuerSturm .
>
> I think I will do a merge and release, and then work on the secure TLS/https stuff over the weekend. It's already a 7,500+ line PR!
@earlephilhower
If that helps, I tested all of your examples, they all worked flawless.
Additionally I tested all the stuff that I need for my projects, since the latest changes you did, that all works perfect as well.
I currently have my Pico W running for almost 7 hours without the slightest problem, connection is stable, no disconnects.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Add support for the WiFi chip on the Pico W board.
Works well enough for experimental use
To Do:
[X]Update LWIP options (now it is the default example one[X]Add WiFi class[X]Add WiFi client class[X]Add support classes (DNS, etc.)[X]Add WiFi server class[X]Add AP mode[X]Examples[X]Docs (such as they are...)Eventually...
Fixes #666
Fixed #665
From the
wifi_scanexample:congratulations on your project.
https://mekatronik.org/forum/
Fantastic!
I was just thinking how it would be nice to have support for Pico W. I'm
looking forward to working with this project.
Gavin
On Wed, Jul 6, 2022, 11:42 PM Earle F. Philhower, III <
@.***> wrote:
Sweet!
Are there plans for pico W ota support?
@earlephilhower
I am looking so damn forward to the Wifi and helper classes, this will be a game changer for my project to finally get away from the expensive Arduino Nano RP2040 Connect.
Pretty please do not forget about a UDP helper class.
Thank you! <3
Eventually, yes. WiFi needs to be stable first, of course. A 2nd stage bootloader w/either FS access or a special OTA region could then either copy a new image or execute the existing code. Probably lose 16K of code space if I go for LittleFS "firmware.bin" or 8K if I stick w/a dumb OTA set-aside.
It will be there, for sure. Once LWIP is up and good, UDP is pretty straightforward.
That sounds great. With OTA I'll finally be able to streamline a few of my projects. Specifically the waveshare pico clock green. Im looking to eventually have it running esphome, and integrated into my automations as a notification sink
You, sir, are a real magican, tipping my virtual hat.
Would you have a "buy me a coffee"-link?
At this point
WiFi,WiFiClient,WiFiUdpare stable enough to try out. AP mode is not yet in, of course.WiFiServerruns and connect when pinged, but I am having issues w/multiple connections so consider that unstable for now.@earlephilhower
I've downloaded the "wifi" branch and replaced all files of my existing 2.2.2 stable install with those files,
after that I downloaded the pico-sdk you are using in your wifi-branch and overwrote the files in the pico-sdk
folder with the newer ones.
I don't see what I am missing here as I cannot get it to work, when trying to compile I'm getting:
In file included from C:\Users\Stefan\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\2.2.2\cores\rp2040/api/ArduinoAPI.h:30, from C:\Users\Stefan\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\2.2.2\cores\rp2040/Arduino.h:28, from sketch\SRGBmods_Wifi_LED_Controller_TX_1657348902.ino.cpp:1: C:\Users\Stefan\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\2.2.2\cores\rp2040/api/IPAddress.h:26:10: fatal error: lwip/init.h: No such file or directory 26 | #include <lwip/init.h> | ^~~~~~~~~~~~~ compilation terminated. exit status 1 Error compiling for board Raspberry Pi Pico W.Any ideas what I am missing? Thanks!
You need to use a
gitinstall, not a downloaded .ZIP. They never seem to work because they are missing many dependencies.You can use the guide in the README, it's still valid, and then check out the
wifibranch.Ah, I see, will try that when I get home from work, thank you sir!
@earlephilhower Are you planning to add
WiFiClientSecure? I don't see it in the TODOs and it's essential for most IoT projects and platforms in 2022.@brentru Absolutely! I need to get a baseline out there first and not try to boil the ocean for now. When I did the BEarSSL port for the ESP8266 I didn't have to worry about the wifi chip or LWIP, but now I'm have to figure out the whole stack from radio to socket, so it's a bit of a trudge. Once the Client is stable, adding SSL should be "easy" if I use our BEarSSL client from the ESP8266.
@earlephilhower
I tried with your short git instructions from the readme and it indeed compiled, so one step forward.
BUT Windows immediately says that the device isn't working after flashing the Pico W.
I'm using TinyUSB to use the Pico as a USB HID device, same sketch with Arduino Nano RP2040 Connect and WiFiNINA instead works fine. Not sure what I did wrong, but I will take a closer look later.
Try the basic Blink.ino from the examples (making sure the chip is set to PicoW). That verifies basic WiFi chip integration since it requires a 220KB blob and 5k lines of code to drive the onboard LED. :)
@FeuerSturm I've just included some UDP, WiFiClient, and network scan tests I'm running here. Give those a try,,,
@earlephilhower will do right now, thanks!
@earlephilhower
Tried the ScanNetworks example, works perfect when using Pico-SDK usb stack, as soon as I try to use
any sketch with TinyUSB usb stack, windows says the device isn't working...
I don't run the Adafruit stack, so thanks for pointing that out.
I think they have the same "bug" that I did WRT the USB Irq. They picked a fixed IRQ # and it conflicts with the PICO SDK's choice for the WiFi chip. I'll send a PR their way after work. Just need to let the SDK give it an IRQ # via a simple call instead of using a
#define. (The#definewas fine before, of course, since the SDK didn't use that IRQ until 1.4.0)Ah, great, already thought I am too stupid to set this up :)
@FeuerSturm if you pull the latest patch and
git submodule updateit will pull in the fixed TinyUSB libs@earlephilhower
That indeed brought it to life!
It connects to my network fine, but I noticed 2 things that don't work:
setHostname - it is not using the hostname I told it to use
const char TXHostname[] = "SRGBmods-WLC-Nanoleaf"; WiFi.setHostname(TXHostname); WiFiStatus = WiFi.begin(ssid, pass);second thing I noticed, is that "hooking" into the WifiClient doesn't seem to work:
I'm using this HTTPClient lib for easy use of some GET and PUT requests:
https://github.com/arduino-libraries/ArduinoHttpClient
"Requires a networking hardware and a library that provides transport specific Client instance"
That works fine with WiFiNINA and the Nano RP2040 Connect as well.
I know it's still early development, just thought I'd mention it.
Great job so far, once again tipping my virtual hat.
Actually, that works fine but it seems the Arduino WIFI and the ESP8266 WIFI disagree about
Wifi.begin().On the ESP8266 where I come from,
Wifi.begin()returns immediately once the network link is up. To check for IP yopu need top wait forWiFi.state() == WL_CONNECTED.Looks likt other WIFIs wait for network AND IP before returning.
For now, just add
after the
while (!WiFi.begin())loop and everything works fine.The SimpleHttpExample from ArduinoHttpClient was modded:
And the output is:
@earlephilhower
I do have checks in place if the wifi connection is established and I'm not trying to do anything before this is the case.
I will revise my code and try again once I get home from work. Thanks!
@FeuerSturm don't change your code, just pull the latest changes. Wifi.begin now waits for IP, and the DHCP hostname setting does now work.
@earlephilhower
setHostname now works perfect, thanks for that!
I still cannot get the HTTP PUT / GET to work without any code changes when migrating from Nano RP2040 Connect / WiFiNINA though, I'll have to investigate what's wrong as it works fine as it is when I plug in the Nano and recompile...
If you can post a small test that fails, that would help much @FeuerSturm .
@earlephilhower
I've been running some example and it seems that the Arduino HTTP Client lib is not the problem,
all the examples worked fine.
I'm using ArduinoJSON in conjunction with the HTTP Client lib to extract some required information from an API,
that seems to be the problem as the Pico W is hanging as soon as the code hits that part.
I've tried with both of the Ethernet MCUs (WIZnet W5100S-EVB-Pico + WIZnet W5500-EVB-Pico) that I own, it's
exactly the same problem, MCUs get unresponsive, so it's for sure not a problem with your Wifi lib.
This is where it hangs, no idea why the Nano RP2040 Connect works fine with this but every other MCU I tried doesn't:
loop_codepart.txt
I guess I will have to do some extensive trial and error.
Thanks for your help and sorry for the confusion!
@FeuerSturm your problem is simple: You're overflowing the stack. The Pico has 4K per core and you're allocating 30KB+ of JSON and overflowing it.
Look at either globals or using heap allocated (i.e.
new ArduinoJSON<xxxx> x; ......; .delete x@earlephilhower
Yes, you are absolutely right, I am an idiot, will revise and try again.
Thank you <3
@earlephilhower
I'm seriously out of ideas now, I've changed the JSON doc to be dynamic so it uses the heap instead of the stack and reduced it's size ALOT. I still cannot get it to work, so I added some debug messages and this is strange:
Same sketch compiled for Nano RP2040 Connect and WiFiNINA still works flawless and takes around 6sec to GET/PUT several settings and deserialize the JSON received by the Nanoleaf API.
The Pico W needs twice the time to get/put the settings and immediately disables UDP mode (should only happen if not receiving USB HID packets for more than 5sec) and resets to the previously acquired settings and goes unresponsive:
serialmonitor_debug.txt
This is my "optimized" loop code, would you have anymore ideas?
loop_codev2.txt
Thanks in advance!
Sorry, but there's nothing in the snippet that stands out. I suggest hooking up GDB and a PicoProbe which will help pinpoint any crashes and let you dig deeper into the problem.
I will further optimize the code and will move acquiring the config and settings to setup instead of loop, I suspect that I am overloading it somehow with all the http get/put requests while it already receives USB HID packets and works with them. Will see if that helps.
Thanks!
@earlephilhower
Almost forgot that:
I tried my other project that doesn't use ArduinoJSON and Arduino HTTPClient and that worked perfect.
Tested and working flawless:
Awesome job, thanks a lot!
@FeuerSturm thanks for the feedback! You should pull down the latest patch. UDP wouldn't care, but for TCP there was a problem where it would retransmit packets and get out of sequence because of a silly error in the device driver. Not saying it will fix your other problem, only that it will help remove some potential faults. :)
@earlephilhower
Those latest changes indeed fixed the "Pico W needs twice the time" problem and I found the other problem that caused it to become unresponsive.
It was once again me being an idiot, I tried to toggle on/off the onboard led way to frequently which caused it to hang.
All in all, everything is working right now!
Thanks a lot for your help! <3
@earlephilhower
I'm excited for this to go live!
You've done an outstanding job with this, thanks a lot, seriously appreciated!
P.S.:
Tested AP mode as well, works perfect as well from what I could test (connected to it with my phone without a problem).
Thx again for the updates, @FeuerSturm .
I think I will do a merge and release, and then work on the secure TLS/https stuff over the weekend. It's already a 7,500+ line PR!
@earlephilhower
If that helps, I tested all of your examples, they all worked flawless.
Additionally I tested all the stuff that I need for my projects, since the latest changes you did, that all works perfect as well.
I currently have my Pico W running for almost 7 hours without the slightest problem, connection is stable, no disconnects.