Support Pimoroni Pico Plus 2W

[eightycc]

Implement support for Pimoroni Pico Plus 2W board vid=0x2E8A pid=0x10bd. Resolves #9808.

Tested with code from "Quick-Start the Pico W WiFi with CircuitPython".

[dhalbert]

@bablokb would you like to review and test? I don't have the actual board.

[bablokb]

I can test this PR tomorrow. Only difference (besides a number of additional comments which is of course good) to my version is the PIO clock divider as noted by @eightycc . I copied the clock-divider from Jeff's implementation for the Pico2-W.

@jepler: was there a reason to set the clock-divider to 3?

A note on the directory name: this PR uses pimoroni_pico_plus2w. I used pimoroni_pico_plus2_w to be consistent with raspberry_pi_pico2_w. This is non-functional and personally I don't care, but maybe you have a different opinion on this.

Another note: I had to upgrade cmake to make it compile. The current version of cmake available from the Github-codespaces is too low. I will create a PR for that too.

[eightycc]

@bablokb Some of the third party boards elided the _ separating separating the final w. Personally, I have no preference.

The CYW43439 interface is set as a power-on reset strapping option to gSPI. This is a subset of SPI defined by Cypress (now Infineon) in the CYW43439 datasheet. The datasheet also specifies a maximum SCLK of 50 MHz.

The Pico SDK implements gSPI using a PIO. See src/rp2_common/pico_cyw43_driver/cyw43_bus_pio_spi.c.

The PIO clock divider is set in 2 parts, an integer part by CYW43_PIO_CLOCK_DIV_INT and a fractional part by CYW43_PIO_CLOCK_DIV_FRAC. The fractional part is an 8 bit value representing a fraction in the range 0/256 to 255/256. The PIO program uses sideset to toggle the SCLK pin, so SCLK is effectively the PIO frequency divided by 2 (it takes two PIO program steps for each generated SCLK clock). Given a PIO clock divider default of 2, the generated SCLK frequency will be the processor clock divided by 4.

For an RP2350 running at 150 MHz, the SCLK at the default settings runs at 37.5 MHz while using a divider of 3 reduces it to 25 MHz.

For an RP2350 SCLK at the default settings is within spec for CYW43439. The limiting factor here is not the CYW43439 but rather the placement and routing of gSPI signals on the board itself. This becomes a more critical issue for implementations that use an RM2 breakout where the transmission lines between the board and the module come into play.

What is an optimal setting for the PIO clock divider? Clearly it must be set to produce a frequency low enough to provide for reliable operation of the gSPI bus. Simultaneously, it must also be set high enough so that the receive buffers in the CYW43439 are not overrun. Given that 802.11b has a theoretical maximum throughput of 1-11 Mbps, a conservatively safe minimum SCLK frequency should be around 15 MHz.

[dhalbert]

A note on the directory name: this PR uses pimoroni_pico_plus2w. I used pimoroni_pico_plus2_w to be consistent with raspberry_pi_pico2_w. This is non-functional and personally I don't care, but maybe you have a different opinion on this.

It's consistent with pimoroni_pico_plus2. I'd try to be consistent with other boards by the same manufacturer.

Another source of possibly canonical names is https://github.com/raspberrypi/pico-sdk/tree/master/src/boards/include/boards. For instance, there, it's pico2.h, not pico_2.h, so that's a guideline. I'd prefer raspberry_pi_pico2.h, but it's Raspberry Pi's repo. That's a case where we would deviate, to be consistent about always putting the manufacturer name in the board name.

[bablokb]

I tested the artifact and it works without problems. Tested as STA and as AP+webserver serving multiple streams in parallel. Network performance seems to be limited by the Infineon-chip - I see the same throughput as with the Pico-W.
But as soon as it comes to processing the requested data, you can see the difference.

So from my side, you can go ahead and merge.

[eightycc]

@bablokb I'd like to know more about the network performance limitations you're seeing using the CYW43 part.

[tannewt]

Merging since it works! Thank you!

[bablokb]

@bablokb I'd like to know more about the network performance limitations you're seeing using the CYW43 part.

I have a small "benchmark" webpage that loads a few js-libs (including jquery) and stylesheets. Total size is about 138KB (jquery alone is about 89KB, and that is the minified version). The browser opens 5 parallel streams to download the page plus all linked files. This is a test that the implementation can handle parallel requests and also kind of measures throughput.

WLAN is a shared medium so the results vary, but I consistently see about 11s load time for the whole page (caching in the browser disabled). And this is the same I see with the Pico-W.

[eightycc]

@bablokb The network performance issue you're experiencing seems to be severe. I'd expect the time to load to be in milliseconds. Would you open an issue so that we can track it? I suspect there's something broken in the way that IRQs from the CYW43 are handled.

[bablokb]

I will do that as soon as I uploaded the test-case. I tested with the Adafruit Feather ESP32-S3 (4MB/2MB version), and using this device I am in the range of 1s (I think milliseconds are a bit over-optimistic).