RP2350 Support

[maxgerhardt]

Obligatory issue after today's announcement of Raspberry Pi for the release of the RP2350 core, the Raspberry Pi Pico 2 dev board, along with the Sparkfun RP2350 Pro Micro.

Pico-SDK 2.0.0 supports this chip.

The chip has two "core slots", in which one can arbitrarily select from 2 x Cortex-M33 or 2x Hazard3 (RISC-V, RV32IMAC) cores. (sadly not possible to run 3 or 4 cores simulatenously, it seems..). Alongside with 520 kB SRAM and 3 PIO blocks of 4 state machines each (instead of 2 blocks from the RP2040).

[earlephilhower]

Hopefully we'll get a big PR soon. #2226 (comment)

Boards are still not available from retailers, yet...

[Hedda]

Hopefully we'll get a big PR soon. #2226 (comment)

@PontusO do plan on submitting pull requests from your port repo to this as upstream or leave it as a fork?

https://github.com/PontusO/arduino-pico-rp2350

An arduino-pico port is on it's way (https://github.com/PontusO/arduino-pico-rp2350). Unfortunatly there were a ton of PR's on the pico-sdk the past few days so it is not ready for prime time yet. It works fairly well in its current state though but this is using a 2 month old version of the pico-sdk.

Originally posted by @PontusO in #2226 (comment)

[earlephilhower]

WIP at #2337

[znmeb]

I have boards if there's something to test: SparkFun Pro RP2350 and Pimoroni Pico Plus 2. I also have the iLabs Challenger Plus boards but I assume @PontusO can test those and knows the code a lot better than I do.

[earlephilhower]

@znmeb if you have some time then if you could run through whatever examples you can and report back their status? I have just received a bunch of boards but am looking at adding PSRAM support this weekend so probably won't do any more testing that just making sure blink works. You'd need to pull the PR from #2337 and update the tools and submodules, of course. If you're already using the git version of the repo then it's not a big deal and GH has a good page on how to try out a PR locally.

[arturo182]

I've been running an LCD with SPI interface and I2C touch together with LVGL on the draft code and it's been working great so far 👍

[jake653]

This BSP is a port of the Arduino Pico framework done by Earle F. Philhower, III to support the new RP2350 processors by Raspberry Pi. It uses the bare Raspberry Pi Pico SDK and a custom GCC 12.3/Newlib 4.0 toolchain.
https://github.com/PontusO/arduino-pico-rp2350

(I have seen the official raspberry pi example files where updated for the rp2350...somewhere)

[znmeb]

I'm setting up my development environment now. Will this work with the Arduino CLI or do I need the GUI? I'm doing everything in a Linux container. I can make the GUI run but it's a hassle.

[earlephilhower]

Yes, arduino-cli can build everything. You may need to manually copy UF2 files if you're using WSL2 or a VM, though. USB passthrough is a pain because the device changes depending on reboot state...

[znmeb]

Yes, arduino-cli can build everything. You may need to manually copy UF2 files if you're using WSL2 or a VM, though. USB passthrough is a pain because the device changes depending on reboot state...

I am sadly aware of the hassles of reliable connections to a host USB device inside a WSL container. The last time I tried it, however, it did appear to work using usbipd for /dev/tty..... Mounting the USB boot virtual disk appears to work now.

[earlephilhower]

@maxgerhardt: A general question about P.IO JSON files. Right now I've hardcoded in the bits needed to make RP2350 binaries using Platform.IO. There's lots of little bits of if (chip==2040) X; else if (chip==2350) Y; which works but is less than optimal.

Instead of hardcoding the differences in Python, can I add fields to the board JSON with the info? For example, the CPU options in the compiler where I switch between M0 and M33. I already dump the proper settings per-board in boards.txt and it'd be trivial to add it to the JSON file as a new field and it would remove one hardcoded logic bit.

[maxgerhardt]

New info can absolutely be added to the JSON board file. The informations which cores are used in the RP2350 could be encoded in many ways: First of all, "build" -> "mcu": "rp2350" is the first identification, after "cpu": "cortex-m33". To encode the possibility to select an arbitrary CPU core into the 2 available CPU slots, we could add a "cpu_0": "cortex-m33", "cpu_1":"cortex-m33", for example. The user can then overwrite that with

board_build.cpu_0 = cortex-m33
board_build.cpu_1 = riscv

for example. But, there's so many ways to do this, style wise. "cpu_0/1" sadly overlaps the regular "cpu" field here a bit.

Finally, the to-be-used compiler will have to detected in the platform code anyway (platform-raspberrypi/builder/main.py), which is my responsibility to adapt.

But for simplicity (not building two different firmware for two different CPU cores), we could also have just build.cpu being either cortex-m33 or riscv and build the whole firmware with that. More complicated builds where the firmware starts both a RISC-V as well as a ARM core can come later.

[earlephilhower]

Thanks! As I go and fix bugs I'll try and remove some of that technical debt w/new fields, then.

I may get to RV eventually, but it's a big push and requires a new pico-quick-toolchain build process (plus if I read correctly, only GCC 14.x has the new RV instructions...and we're on 12.x presently). Right now I'm all focused on ARM and getting that working...got my first board 3 days ago, after all. :)

[earlephilhower]

Fixed by #2337 . Any bugs found, please open a new issue so we can get it tracked and fixed.

[SunboX]

Did someone already test the native USB Host functionality? It's still USB 1.1, but does it have the same speed in reality like the RP2040 or did it get faster/slower?

[earlephilhower]

I think it's the same peripheral with errata fixes only, so I would expect similar performance. Check the datasheet: https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf