Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Hedda opened this issue Aug 9, 2024 · 11 comments
Open

Comments

@Hedda
Copy link

Hedda commented Aug 9, 2024

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.

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:

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:

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

"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.

image

image

image

image

image

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:

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

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

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 Hedda changed the title RP240 Platform - Raspberry Pi Pico 2 with RP2350 microcontroller support RP2350 Platform - new Raspberry Pi Pico 2 with RP2350 microcontroller support? Aug 9, 2024
@Hedda
Copy link
Author

Hedda commented Aug 9, 2024

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:

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
Copy link

chaudis commented Nov 25, 2024

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

@Hedda
Copy link
Author

Hedda commented Nov 26, 2024

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:

@danielkent-net
Copy link

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
Copy link
Author

Hedda commented Dec 5, 2024

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 and when all these new pull requests by @tomaszduda23 are merged?

It requires also:

Optional:

@danielkent-net
Copy link

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
Copy link

JanPetterMG commented Dec 16, 2024

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...

@gandarez
Copy link

Any update on this? I have a pico2w and I'm available for testing it.

@Hedda
Copy link
Author

Hedda commented Mar 18, 2025

No news on the ESPHome side, but FYI, Raspberry Pi has just announced general availability for the RP2350A and RP2350B in bulk, budles, or single pieces:

Before this the RP2350 microcontroller unit itself has been very hard to source for hobbyist and low-volume projects that just want the MCU and not a complete development board.

PS: They have also pre-announced new RP2354A and RP2354B microcontrollers variants with 2MB of stacked flash memory on top of the microcontroller chip to allow more compact designs.

@Hedda
Copy link
Author

Hedda commented Mar 18, 2025

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:

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

Be aware that while you will probably never get a official answer from PlatformIO, you should know that PlatformIO's CEO have more or less made it clear that they will not allow their upstream platform-raspberrypi to keep being developed in their repository/repositories as long as Raspberry Pi Foundation or Raspberry Pi Ltd is not officially paying PlatformIO to maintain it there, and infer that the decision to discontinue support for upstream PlatformIO platforms are entirly up to the companies paying PlatformIO to maintain each platform.

The alternative options for now is to either use a fork or use a Raspberry Pi Pico Arduino core without PlatformIO. New forks of PlatformIO's platform libraries have therefore been created and maintained separate due to the lack of ongoing development in PlatformIO upstream platform library. Anyone in the community can use and contribute to those, see example:

FYI, it looks like we can see practically the same situation between PlatformIO and Espressif (platform-espressif32 for ESP32) which this has gone on for longer:

PlatformIO is also no longer taking community contributions to improve its platform-raspberrypi platform library in their upstream repository/repositories, which means that upstream development of PlatformIO's platform library for Raspberry Pi Pico(s) have stalled or put on hold for now. Because of this users feel forced to move to forks or alternative Arduino-Pico core without PlatformIO in order to use the new RP2350 MCU/SoC.

For additional information, please refer to these GitHub links where the discussions there are self-explanatory, allowing you to draw your own conclusions:

PS: I understand PlatformIO is a company that need income but I do not see how this practice will benefit them in the long run.

@Strat00s
Copy link

TLDR: it's always about money...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants