Support for RP2350

[akhodeir]

Current Behavior

No support of Raspberry Pi Pico boards.

Desired Behavior

Support of RP2350

Suggested Solution

Raspberry PI announced RP2350 which is more powerful than RP2040
it has:

• Dual Arm Cortex-M33 cores with hardware single-precision floating point and DSP instructions @ 150MHz.
• 520 KB on-chip SRAM
• 30 or 48 GPIO
• ... More
• it is much cheaper than equivalent STM32 microcontrollers.

Who does this impact? Who is this for?

it is much cheaper than equivalent STM32 microcontrollers and more available.

Additional context

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

[sensei-hacker]

Being able to run INAV on the Pico 2 would be cool. It would be nifty. Porting it would be a big job, though.

One would of course need to add all of sensors, a low-noise power supply circuit, etc to build a flight controller. So from a practical perspective it would be a lot of effort in order to achieve something that's less usable than an existing $20 flight controller.

This probably isn't a project that any of the core INAV devs are likely to take up. If @akhodeir or someone else wants to give it a shot, we can help answer questions about INAV that come up.

[b14ckyy]

Surely an interesting Project but I agree, nothing for the main INAV Repo/Code. I will move this to discussion.

[akhodeir]

@sensei-hacker , can you tell me what is required for the porting process so I can evalute the effort and time from my side?

[sensei-hacker]

The easier part would be similar to adding another STM32 target. See any of the targets in the src/main/target/ to see what that entails.

Also in target/ you'll find the main files for the different STM32F* processors - the STM32F11, the STM32F22, etc. That would need to be done for the RP2350.

Then you would probably need to implement function stubs which present uart, PWM, I2C, and SPI in the same way that the STM HAL does.

This is just off the top of my head. Since I haven't done it, I can't say for sure what all would be involved.

See also

iNavFlight/inav-configurator#1818

[akhodeir]

I went quickly through the code.

I see that VSD and CMSIS files are required information for the RP2350 for porting. do I get it correctly ?

using the Pico SDK is not an option ?

[sensei-hacker]

I went quickly through the code.

I see that VSD and CMSIS files are required information for the RP2350 for porting. do I get it correctly ?

using the Pico SDK is not an option ?

If you do a port you could certainly do it either way. You could do whatever you want - it's just a matter of how much effort it is, both to do initially and then to maintain over time. You could use CMSIS directly with the Gnu build system, (which is unusual for a Pico), or you could use the Pico build system (which is unusual for INAV).

Since the INAV code is updated daily while the hardware doesn't change, I would first consider the approach that makes the minimal changes to the functional code. If a lot of code needs to be changed to use the 2350 SDK, it may need more ongoing work to port new features and changes to the SDK. (Or maybe not since most changes to INAV aren't hardware-specific).

If I were doing it, I would probably start by looking at this repo and the accompanying blog post:

https://github.com/metebalci/rp2350-bare-metal-build

I would also look at Picobin.

I'm curious to see what you find out. My guess would be that the ongoing maintenance work would be less by using using the DVD and CMSIS directly, with the Gnu build chain. But I haven't done this port, so I could be 100% wrong.

[akhodeir]

I ported most of drivers(i2c, spi, ..etc)
I am to know what are necessary files to be used for final firmware. I see many files that are used for simulation( *_fake.c).
Can you please list them.

[Ncerzzk]

hi @akhodeir , would you mind introducing the progress of your work? I'm interested in this, too.

[lyusupov]

Pico 2W (RP2350) upgrade for SoftRF Standalone Edition

[sensei-hacker]

If someone is considering whether they want to do this, the attached files may be interesting.
They include things coming from an LLM bot - Claude. As can be seen on convo.html, the answers from Claude are NOT always accurate and should NOT be treated as dependable. The exchange does, however, point to some things you might think about.
inav_rp2350_dshot.txt
rp2350_hal_wrappers.txt
convo.html

[sensei-hacker]

I see that there was a recent port /target for the Pico in Betaflight. Because INAV and Betaflight both come from Cleanflight, some of the techniques used and lessons learned might apply here also.

https://github.com/betaflight/betaflight/pulls?q=is%3Apr+label%3ARPI+is%3Aclosed

The attached files are an automated update based on what might apply from the BF implementation.
The BF PRs were used to update an analysis of the INAV source code and the RP2350 datasheet.
There may be inaccuracies because I used an LLM, but much of it is likely accurate.
inav_rp2350_dshot.txt
rp2350_hal_wrappers.txt
inav_rp2350_port_plan.md
inav_rp2350_detailed.md