RP2350 Platform - new Raspberry Pi Pico 2 with RP2350 microcontroller support?

[Hedda]

Describe the problem you have/What new integration you would like

Please consider adding platform support for the new RP2350 MCU and their official Raspberry Pi Pico 2 development board.

• https://www.raspberrypi.com/products/rp2350/

• https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf

RP2350 is the successor and next-generation of RPi RP2040 so guess ESPHome would need to update the RP2040 Platform for it or add another platform?

Raspberry Pi Pico 2 and other developer board from Raspberry Pi's partners will be available now or soon, but the RP2350 SoC itself for those wanting t build their own board or product will be generally available in volume before the end of 2024. To register your interest, and to participate in the Raspberry Pi samples program, head over to the product page.

FYI, a "W" version of the Pico 2 with wireless support expected 'by the end of the year' according the people in the know 😛

Raspberry Pi team writes that the new RP2350 is vastly more sophisticated design than RP2040, however I understand it is supposedly backwards-compatible, though this new model now also offers faster resources, more IO/PIO, support for Arm TrustZone (security architecture), new HSTX peripheral for high-speed data transmission, and support for external QSPI PSRAM.

RP2350 microcontroller also adds an HSTX (High-Speed Serial Transmit) interface adding the PIOs (Programmable IOs) that was introduced on the original Raspberry Pi RP2040 MCU three years ago. The RP2350 MCU now has three PIOs and one HSTX interface going over 8x GPIOs.

However, I believe that the most interesting difference is otherwise probably the fact that the new Raspberry Pi RP2350 MCU features two-modes with dual-core RISC-V or dual-core ARM Cortex-M33 on the chip, meaning that you can either choose to run it in either RISC-V mode or in ARM Cortex-M3 mode, (but not more than two cores active at the same time, meaning that you can actually run in mixed mode with one RISC-V core and one ARM Cortex-M33 core which is probably something that is both unique and a first for a such SoC, so "They're selectable at boot time: Each port into the bus fabric can be connected either to an M33 or a Hazard3 via a mux. You can even, if you're feeling obtuse, run with one of each." Arm/RISC-V switching is explained in the official datasheet:

• https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new-5-microcontroller-board-on-sale-now/
• https://www.raspberrypi.com/products/raspberry-pi-pico-2/
• https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html#pinout-and-design-files
• https://www.raspberrypi.com/products/rp2350/
• https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf
• https://github.com/raspberrypi/pico-sdk-rp2350
• https://github.com/raspberrypi/pico-examples-rp2350
• https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf
• https://github.com/raspberrypi/pico-vscode

Many RP2350-based development baords and products are already apparently already in the pipeline:

https://www.raspberrypi.com/for-industry/powered-by/product-catalogue/?category=RP2350

If official Pico2 is hard to find then be ware that SparkFun Pro Micro RP2350 (and DEV-24870) and Adafruit Feather RP2350 (Product ID: 6000) are supposedly among the first of third-parties scheduled to become available to the first third-party boards available with RP2350:

• https://www.sparkfun.com/products/24870

• https://www.adafruit.com/product/6000

This article from CNX software offers a little more insight into the RP2350 as compared to the RP2040:

• https://www.cnx-software.com/2024/08/08/raspberry-pi-pico-2-raspberry-pi-rp2350-dual-core-risc-v-or-arm-cortex-m33-microcontroller/

"The RP2350 embeds both an open-source Hazard3 RISC-V dual-core CPU and a dual-core Cortex-M33, but only one cluster can be used at a given time. Apart from the faster MCU cores and higher SRAM capacity, the RP2350 is about the same as the RP2040, albeit it also adds one extra PIO block bringing the total to three. One important new feature is built-in security when using Arm Cortex-M33 cores with Trustzone and other security features."

As I understand it, the RP2350A package offers also the same pinout as the RP2040 microcontroller, but the company now also adding a larger RP2350B package with additional GPIOs and analog inputs.

Raspberry Pi used the same method as for the RP2040 to derive the RP2350 name. RP stands for “Raspberry Pi”, “2” is the number of cores, “3” refers to the MCU core used (e.g. Cortex-M33), and the last two numbers “4” and “0” use floor(log2(x/16k)) formula to calculate a number representing the SRAM and non-volatile storage capacity inside the chip.

• https://www.raspberrypi.com/documentation/microcontrollers/silicon.html#architecture-switching

Please describe your use case for this integration and alternatives you've tried:

Alternative is to use ESPHome with other HW and RP2040 Platform, ESP32 platform, ESP8266 Platform, or ESP8266 Platform:

• https://esphome.io/components/rp2040.html
• https://esphome.io/components/esp32
• https://esphome.io/components/esp8266
• https://esphome.io/components/libretiny

Ustream forum discussions from before when they leaked the news about this "Forthcoming RP235x" microcontroller:

• https://forums.raspberrypi.com/viewtopic.php?t=371165

There is by the way also someone working on an nRF platform for Nordic Semicondiuctor nRF52 and nRF53 familily of MCUs:

• basic support for nrf52840 esphome#6075

• https://community.home-assistant.io/t/fyi-a-developer-has-begun-porting-esphome-to-a-nrf5-platform-for-nrf52840/683997

PS: Raspberry Pi is offering a $10,000 bounty for the first confirmed break of their new signed boot process on RP2350.:

https://github.com/raspberrypi/rp2350_hacking_challenge

"To get RP2350 hardware into the hands of the engineers most likely to find these flaws, we’ve partnered with the DEF CON hacking convention, which starts today in Las Vegas. This year’s badge is powered by RP2350, and makes a great platform for experimenting with our security architecture."

[Hedda]

Pico-SDK 2.0.0 supports this new RP2350 microcontroller chip:

https://github.com/raspberrypi/pico-sdk/releases

For reference, here are a few related feature requests to upstream dependencies that are needed to be implement first before they can be used by ESPHome for all Raspberry Pi Picos:

• [REQUEST] Raspberry Pi RP2350 and Raspberry Pi Pico 2 support? platformio/platform-raspberrypi#67

• [REQUEST] Raspberry Pi RP2350 and Raspberry Pi Pico 2 support? maxgerhardt/platform-raspberrypi#69

• RP2350 Support earlephilhower/arduino-pico#2325

  • New RP microcontroller coming earlephilhower/arduino-pico#2226

FYI, PontusO has forked earlephilhower’s arduino-pico repo to a new arduino-pico-rp2350 repo where he got RP2340 working with an older version of the pico-sdk:

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 earlephilhower/arduino-pico#2226 (comment)

We do not know yet if he will leave that new arduino-pico-rp2350 repo as a a separate fork dedicated only to the RP2350 or if he or others will submit pull requests with changes from it to earlephilhower’s arduino-pico repo and use that as upstream for all picos, including both RP2040 and RP2350 in the same repository.

https://github.com/PontusO) in earlephilhower/arduino-pico#2226

[chaudis]

The W version is now released
https://www.raspberrypi.com/news/raspberry-pi-pico-2-w-on-sale-now/

[Hedda]

The W version is now released https://www.raspberrypi.com/news/raspberry-pi-pico-2-w-on-sale-now/

Nice specifications, and those specs with the same Wi-Fi and Bluetooth/BLE chip will of couse also soon be used to create RP2350 clones and other boards based on RP2350 using this Pico 2 W as reference hardware design:

• https://www.cnx-software.com/2024/11/25/7-raspberry-pi-pico-2-w-board-2-4-ghz-wifi-4-bluetooth-5-2-wireless-module/

[danielkent-net]

I got some Pico 2Ws today and I started looking at the esphome code a bit. I didn't get very far but I found a few things that might be helpful for anyone else that wants to try advancing this at all:

• arduino_pico version 4.3 adds support for the 2W, and the 4.3.1 release fixes a few bugs. There needs to be a corresponding version bump in version in a few places.
• Similarly, git commit 39b9039 on maxgerhardt's PlatformIO fork is needed for compatibility with the above version of arduino_pico.

These changes aren't the only things needed to build RP2350 compatible binaries; with the changes I made (danielkent-net/esphome@6370f11) I think it's still outputting an RP2040 uf2. It does compile something, for what it's worth. Granted, I'm only testing with a very minimal example that just blinks the LED.

I also don't know if anyone's considered whether RP2350 support should live in its own platform, or be part of the rp2040 platform (and subsequently keep rp2040_pwm and other related platforms as-is). My fork keeps it in the same repository since I saw a lot of code that would otherwise need to be duplicated in the new platform (or put in some sort of common platform that both reference). I'm not too familiar with this part of esphome code, so if anyone has a better idea and wants to chime in that would be helpful.

[Hedda]

I also don't know if anyone's considered whether RP2350 support should live in its own platform, or be part of the rp2040 platform (and subsequently keep rp2040_pwm and other related platforms as-is).

Might also be simpler to add new platforms like this in the future if all these new pull requests by @tomaszduda23 are merged?

• [core] add support for custom platform esphome#7616

It requires also:

• let make new platform implementation in external components esphome#7615
• unified way how all platforms handle copy_files esphome#7614
• unified way how all platforms handle get_download_types esphome#7617

Optional:

• unified way how all platforms handle SplitDefault esphome#7715
• python lint for platform components esphome#7864
• [gpio] add tests for old style platform esphome#7865

[danielkent-net]

Might also be simpler to add new platforms like this in the future if all these new pull requests by @tomaszduda23 are merged?

I'm not sure it's strictly necessary, but it might help down the line with further Pico releases.

---

Doing some more experimentation, my changes do in fact produce RP2350-compatible binaries, but GPIOs don't seem to work. The output looks like this:

[I][app:100]: ESPHome version 2024.12.0-dev compiled on Dec  7 2024, 13:45:29
[C][logger:185]: Logger:
[C][logger:186]:   Level: DEBUG
[C][logger:188]:   Log Baud Rate: 115200
[C][logger:189]:   Hardware UART: USB_CDC
[C][gpio.output:010]: GPIO Binary Output:
[C][gpio.output:011]:   Pin: GPIO32

If I compile with VERY_VERBOSE debug, I see that it looks like it's trying to toggle the GPIO:

[I][app:100]: ESPHome version 2024.12.0-dev compiled on Dec  7 2024, 14:04:46
[C][logger:185]: Logger:
[C][logger:186]:   Level: VERY_VERBOSE
[C][logger:188]:   Log Baud Rate: 115200
[C][logger:189]:   Hardware UART: USB_CDC
[C][gpio.output:010]: GPIO Binary Output:
[C][gpio.output:011]:   Pin: GPIO32
[VV][scheduler:225]: Running timeout '' with interval=250 last_execution=1966 (now=2216)
[VV][scheduler:225]: Running interval 'update' with interval=500 last_execution=1962 (now=2462)
[VV][scheduler:032]: set_timeout(name='', timeout=250)
[VV][scheduler:225]: Running timeout '' with interval=250 last_execution=2462 (now=2712)
[VV][scheduler:225]: Running interval 'update' with interval=500 last_execution=2462 (now=2963)
[VV][scheduler:032]: set_timeout(name='', timeout=250)
[VV][scheduler:225]: Running timeout '' with interval=250 last_execution=2963 (now=3213)
[VV][scheduler:225]: Running interval 'update' with interval=500 last_execution=2962 (now=3465)
[VV][scheduler:032]: set_timeout(name='', timeout=250)
[VV][scheduler:225]: Running timeout '' with interval=250 last_execution=3466 (now=3716)

The same behavior is also exhibited when compiling for RP2040 (switching board to pipicow in the example yaml), so this issue isn't specific to the RP2350.

I know the LED pin on the Pico W/2W is tied to the wireless chipset and isn't a true GPIO; my next attempt might be to toggle a different GPIO and check the output on an oscilloscope, in case that's part of the problem.

[JanPetterMG]

Wasn't able to lit the internal LED me either, but connecting an external one via GPIO and getting it blinking was hassle free. I've also got Wi-Fi (with OTA), SPI and the internal temperature sensor working.

Haven't experimented too much yet, but it was quite easy to get started, just put this in the YAML:

rp2040:
  board: rpipico2w
  framework:
    platform_version: https://github.com/maxgerhardt/platform-raspberrypi.git#develop
    version: dev

EDIT:
There seems to be an issue with the ADC.

No matter what ADC PIN I choose, I get the following error:

src/esphome/components/adc/adc_sensor.cpp: In member function 'virtual float esphome::adc::ADCSensor::sample()':
src/esphome/components/adc/adc_sensor.cpp:303:26: error: 'PICO_VSYS_PIN' was not declared in this scope
  303 |     float coeff = pin == PICO_VSYS_PIN ? 3.0 : 1.0;
      |                          ^~~~~~~~~~~~~
*** [.pioenvs/xxx/src/esphome/components/adc/adc_sensor.cpp.o] Error 1

It's defined in the Pico SDK, so I'm not sure what I'm overlooking or where to create an issue about it, esphome, platform-raspberrypi or pico-sdk...