Add RP2350 support #2337

Merged
earlephilhower merged 44 commits from split into master 2024-08-25 21:21:46 +03:00
earlephilhower commented 2024-08-18 00:44:57 +03:00 (Migrated from github.com)

The PR has been tested on SparkFun, ILabs, and Pico 2 RP2350 boards. Everything is working except for:

  • OTA (I need to understand the new boot setup much better)
  • FreeRTOS (An RPI port exists but is not part of the upstream tree we use and a manual merge will be needed)
  • HSTX not made into a library (TBD in future release)
  • RP2350 optimizations (SHA256, others. Will be added at some point in the future once other stuff working)

(Also, for some reason the one official Pico2 that I have tried OpenOCD on has failed, but the same config works fine on the iLabs RP2350 BConnect so it's either some HW lockout on my sample or a wiring issue on the Pico2 board rev 2624 6.17)

The PR has been tested on SparkFun, ILabs, and Pico 2 RP2350 boards. Everything is working except for: * OTA (I need to understand the new boot setup much better) * FreeRTOS (An RPI port exists but is not part of the upstream tree we use and a manual merge will be needed) * HSTX not made into a library (TBD in future release) * RP2350 optimizations (SHA256, others. Will be added at some point in the future once other stuff working) (Also, for some reason the one official Pico2 that I have tried OpenOCD on has failed, but the same config works fine on the iLabs RP2350 BConnect so it's either some HW lockout on my sample or a wiring issue on the Pico2 board rev 2624 6.17)
earlephilhower commented 2024-08-18 05:40:23 +03:00 (Migrated from github.com)

Looks like the MINGW on GitHub Actions is now producing applications which don't run outside of MinGW. Windows picotool builds. Will look into it later, but for now only Mac and Linux can build RP2040 and RP2350 w/the new toolchain.

Looks like the MINGW on GitHub Actions is now producing applications which don't run outside of MinGW. Windows picotool builds. Will look into it later, but for now only Mac and Linux can build RP2040 and RP2350 w/the new toolchain.
zjwhitehead commented 2024-08-18 08:45:24 +03:00 (Migrated from github.com)

I've got my hands on a couple of the RP2350 boards from Sparkfun (https://www.sparkfun.com/products/24870)
Happy to test if you have any specific requests while you're waiting for your own boards to come in.

I've got my hands on a couple of the RP2350 boards from Sparkfun (https://www.sparkfun.com/products/24870) Happy to test if you have any specific requests while you're waiting for your own boards to come in.
earlephilhower commented 2024-08-18 10:00:48 +03:00 (Migrated from github.com)

Thanks, @zjwhitehead. No rush just yet.

At this stage, it's more proof of life than actual tests. If you have a Mac or run Linux and can use the git repo, you could try a very simple sketch that prints out out the serial port, like

void setup () {
Int I = 0;
while (1) { Serial.println(I++); delay(100); }
}
void loop () {}

There's a good chance it won't do anything, but maybe we'll be lucky. Worst case, you can reinstall MicroPython...

Things like the extra PIO or the flash access(filesystems, eeprom) aren't there yet and really need a board in hand to work on. There's a lot of infrastructure that needs to be there before that fine a refinement...

Thanks, @zjwhitehead. No rush just yet. At this stage, it's more proof of life than actual tests. If you have a Mac or run Linux and can use the git repo, you could try a very simple sketch that prints out out the serial port, like ```` void setup () { Int I = 0; while (1) { Serial.println(I++); delay(100); } } void loop () {} ```` There's a good chance it won't do anything, but maybe we'll be lucky. Worst case, you can reinstall MicroPython... Things like the extra PIO or the flash access(filesystems, eeprom) aren't there yet and really need a board in hand to work on. There's a lot of infrastructure that needs to be there before that fine a refinement...
arturo182 (Migrated from github.com) reviewed 2024-08-18 15:40:59 +03:00
arturo182 (Migrated from github.com) left a comment

I tried a simple Hello World with and without the changes I suggested, it builds but after flashing it just puts me back in the bootloader, so there's probably more changes needed.

I tried a simple Hello World with and without the changes I suggested, it builds but after flashing it just puts me back in the bootloader, so there's probably more changes needed.
arturo182 (Migrated from github.com) commented 2024-08-18 15:39:51 +03:00

Should be rp2350

Should be rp2350
arturo182 (Migrated from github.com) commented 2024-08-18 15:28:13 +03:00

This should probably be rp2350

This should probably be rp2350
arturo182 (Migrated from github.com) commented 2024-08-18 15:37:06 +03:00

Is this correct? I think there are defines in that board header that might be hardcoded to RP2040.

Is this correct? I think there are defines in that board header that might be hardcoded to RP2040.
arturo182 (Migrated from github.com) commented 2024-08-18 15:39:19 +03:00

config_autogen.h is missing here. Also, I had to create the rp2350 directories by hand, maybe adding a mkdir -p here would solve that.

`config_autogen.h` is missing here. Also, I had to create the rp2350 directories by hand, maybe adding a `mkdir -p` here would solve that.
arturo182 (Migrated from github.com) commented 2024-08-18 15:15:19 +03:00

Did you mean to remove this file? I had to add it back to try and build libpico.

Did you mean to remove this file? I had to add it back to try and build libpico.
Architeuthis-Flux commented 2024-08-18 19:14:41 +03:00 (Migrated from github.com)

I still don't have an RP2350 board, so absolutely no testing but it can build and link Blink.ino.

So... who's sending Earle some Pico 2s (and something with the RP2350B)? I just ordered some + a few extras in case you don't already have them on the way.

You're doing the lord's work here, you at least deserve some free hardware. Email me and I'll have them shipped out to you asap.

> I still don't have an RP2350 board, so absolutely no testing but it can build and link Blink.ino. So... who's sending Earle some Pico 2s (and [something with the RP2350B](https://shop.pimoroni.com/products/pga2350?variant=42092629229651))? I just ordered some + a few extras in case you don't already have them on the way. You're doing the lord's work here, you _at least_ deserve some free hardware. [Email me](mailto:KevinC@ppucc.io) and I'll have them shipped out to you asap.
earlephilhower (Migrated from github.com) reviewed 2024-08-18 20:23:43 +03:00
earlephilhower (Migrated from github.com) commented 2024-08-18 20:23:43 +03:00

D'oh, that was my mistake. A new one was required for SDK 2.0 but I forgot to git add it!

D'oh, that was my mistake. A new one was required for SDK 2.0 but I forgot to `git add` it!
earlephilhower (Migrated from github.com) reviewed 2024-08-18 20:26:49 +03:00
earlephilhower (Migrated from github.com) commented 2024-08-18 20:26:48 +03:00

Yeah, that's a doozy. Definitely cut-n-paste error on my part and it would bork all the RP2350 libs! It would still link in the 2040 register map/etc. in the SDK library so things like clock startup would be...interesting. 😆

Yeah, that's a doozy. Definitely cut-n-paste error on my part and it would bork all the RP2350 libs! It would still link in the 2040 register map/etc. in the SDK library so things like clock startup would be...interesting. :laughing:
earlephilhower (Migrated from github.com) reviewed 2024-08-18 20:48:19 +03:00
earlephilhower (Migrated from github.com) commented 2024-08-18 20:48:19 +03:00

Good catch! Points out another issue. I make the SDK build in unique subdirs, but the config_autogen.h is always put at {build root dir}/pico/... so it's not possilbe to build 2 chips in the same subdir. I've modified my makefiles to do it sequentially in different dirs...

Good catch! Points out another issue. I make the SDK build in unique subdirs, but the config_autogen.h is always put at {build root dir}/pico/... so it's not possilbe to build 2 chips in the same subdir. I've modified my makefiles to do it sequentially in different dirs...
earlephilhower (Migrated from github.com) reviewed 2024-08-18 20:50:13 +03:00
earlephilhower (Migrated from github.com) commented 2024-08-18 20:50:13 +03:00

Yup,

Yup,
earlephilhower commented 2024-08-18 21:16:29 +03:00 (Migrated from github.com)

Thanks @arturo182 ! A fresh set of eyes catches things much faster than the pair that was writing things in the first place.

The libraries and paths/includes are now significantly updated so you may want to give it one more quick try.

The ELF now has something in embedded_block but nothing in binary_info (it's not on the rp2040 either since OTA lives there). I wonder if the RP2350 ROM requires one before the embedded_block in order to figure out which CPUs to engage. If things still get stuck in the bootloader that may be the issue...

Thanks @arturo182 ! A fresh set of eyes catches things much faster than the pair that was writing things in the first place. The libraries and paths/includes are now significantly updated so you may want to give it one more quick try. The ELF now has something in embedded_block but nothing in binary_info (it's not on the rp2040 either since OTA lives there). I wonder if the RP2350 ROM requires one before the embedded_block in order to figure out which CPUs to engage. If things still get stuck in the bootloader that may be the issue...
PontusO commented 2024-08-18 21:41:38 +03:00 (Migrated from github.com)

the might may be some clues on my repo at https://github.com/PontusO/arduino-pico-rp2350. I have on branch "alpha-arduino-pico" which is based on a 2 months old version of the pico-sdk. This works like a charm. I have done all hardware verification based on that branch. I have tried most things on that branch and very few things were broken. Then I have the master branch, based on the pico-sdk 2.0.0 which builds but where the binary just hangs in an exception on startup.
I am unable at the moment to dig into this but you might find some clues there.

the might may be some clues on my repo at https://github.com/PontusO/arduino-pico-rp2350. I have on branch "alpha-arduino-pico" which is based on a 2 months old version of the pico-sdk. This works like a charm. I have done all hardware verification based on that branch. I have tried most things on that branch and very few things were broken. Then I have the master branch, based on the pico-sdk 2.0.0 which builds but where the binary just hangs in an exception on startup. I am unable at the moment to dig into this but you might find some clues there.
earlephilhower commented 2024-08-18 23:02:47 +03:00 (Migrated from github.com)

It's a pain they had to squash all their work into a single 349,994 additions and 66,341 deletions(!!!) commit so we can't even do a brute-force git bisect to figure out what's gone pear shaped. :( I get it from a commercial sense, you don't want to show the internal sausage making...but it still is a PITA.

I'll look into your fork, @PontusO (especially the PSRAM which I think is not on the Pico2 board...but I have some ESP PSRAM chips somewhere that I could wire up from the ESP8266 virtual-memory patches) Since you said the SDK release was causing you crashes, I figured I'd start from scratch and maybe have a little better luck. We'll get there eventually!

It's a pain they had to squash all their work into a single `349,994 additions and 66,341 deletions`(!!!) commit so we can't even do a brute-force `git` bisect to figure out what's gone pear shaped. :( I get it from a commercial sense, you don't want to show the internal sausage making...but it still is a PITA. I'll look into your fork, @PontusO (especially the PSRAM which I think is not on the Pico2 board...but I have some ESP PSRAM chips somewhere that I could wire up from the ESP8266 virtual-memory patches) Since you said the SDK release was causing you crashes, I figured I'd start from scratch and maybe have a little better luck. We'll get there eventually!
PontusO commented 2024-08-18 23:05:24 +03:00 (Migrated from github.com)

If you send me your adress I'll express you a couple of boards so you have something to work with.

If you send me your adress I'll express you a couple of boards so you have something to work with.
arturo182 commented 2024-08-19 02:42:25 +03:00 (Migrated from github.com)

Very happy to report that with the new changes, a simple Hello World is showing up as a USB CDC and working on my RP2350 Stamp 🎉

edit: Also blinky and I2C scanner!

Very happy to report that with the new changes, a simple Hello World is showing up as a USB CDC and working on my [RP2350 Stamp](https://www.solder.party/docs/rp2350-stamp-select/) 🎉 edit: Also blinky and I2C scanner!
earlephilhower commented 2024-08-19 04:26:21 +03:00 (Migrated from github.com)

Great news, @arturo182 ! Your eagle eyes on the review made it much easier to get going. There's lots of porting to do now, but porting is a lot easier than initial bring up.

I'll add RP2350 to the CI and see what actually builds (no guarantee it'll work, mind you!) and we'll see where we stand.

Great news, @arturo182 ! Your eagle eyes on the review made it much easier to get going. There's lots of porting to do now, but porting is a lot easier than initial bring up. I'll add RP2350 to the CI and see what actually builds (no guarantee it'll work, mind you!) and we'll see where we stand.
earlephilhower commented 2024-08-19 06:32:59 +03:00 (Migrated from github.com)

Quick summary of the status. Not all are breakers for an alpha or beta release, and definitely usable by the brave early users for testing:

  • Everything except FreeRTOS and the Bluetooth libraries now builds.
  • FreeRTOS needs porting from M0+ to M33 (FP register,etc.) and the new register map/ARM exceptions.
  • OTA will build but is not implemented (boot ROM and flash magic address shifting and M33 init vector related).
  • Flash operations (EEPROM, LittleFS) I have concerns about. Probably will work but due to the bootrom adjusting flash addresses they may not write where they think (i.e. the image we know about in the build chain gets other stuff smushed onto it in picotool and written into flash...so you don't really have 4M to write, and maybe only 4M-4K or something...meaning EEPROM will do bad things).
  • Multicore should work, but probably not the core freeze (rp2040.idleOtherCore()/etc.) .
  • Newlib is still built for M0+ which is forward compatible to M33 but obviously not as optimal as we would like.
  • The new OpenOCD (required to work w/RP2350) has build problems on Windows and Mac.
  • Non-UF2 upload not implemented (see above!)
  • No new RP2350 features (other than extra PIO which was trivial to add) like PSRAM.
Quick summary of the status. Not all are breakers for an alpha or beta release, and definitely usable by the brave early users for testing: * Everything except FreeRTOS and the Bluetooth libraries now builds. * FreeRTOS needs porting from M0+ to M33 (FP register,etc.) and the new register map/ARM exceptions. * OTA will build but is not implemented (boot ROM and flash magic address shifting and M33 init vector related). * Flash operations (EEPROM, LittleFS) I have concerns about. Probably will work but due to the bootrom adjusting flash addresses they may not write where they think (i.e. the image we know about in the build chain gets other stuff smushed onto it in `picotool` and written into flash...so you don't really have 4M to write, and maybe only 4M-4K or something...meaning EEPROM will do bad things). * Multicore should work, but probably not the core freeze (rp2040.idleOtherCore()/etc.) . * Newlib is still built for M0+ which is forward compatible to M33 but obviously not as optimal as we would like. * The new OpenOCD (required to work w/RP2350) has build problems on Windows and Mac. * Non-UF2 upload not implemented (see above!) * No new RP2350 features (other than extra PIO which was trivial to add) like PSRAM.
alexriegler12 commented 2024-08-19 15:07:09 +03:00 (Migrated from github.com)

Will support for the RISC-V cores be added too?
(Pure RISC-V or one Arm and one RISC-V core)

Will support for the RISC-V cores be added too? (Pure RISC-V or one Arm and one RISC-V core)
arturo182 commented 2024-08-19 15:34:38 +03:00 (Migrated from github.com)

For FreeRTOS, RPi released a port for both ARM and RISC-V on the RP2350:

https://github.com/raspberrypi/FreeRTOS-Kernel

For PSRAM, Sparkfun has a library and examples, might be a good starting point: https://github.com/sparkfun/sparkfun-pico/tree/main/sparkfun_pico

For FreeRTOS, RPi released a port for both ARM and RISC-V on the RP2350: https://github.com/raspberrypi/FreeRTOS-Kernel For PSRAM, Sparkfun has a library and examples, might be a good starting point: https://github.com/sparkfun/sparkfun-pico/tree/main/sparkfun_pico
earlephilhower commented 2024-08-19 20:27:04 +03:00 (Migrated from github.com)

@arturo182 ,

For FreeRTOS, RPi released a port for both ARM and RISC-V on the RP2350:
https://github.com/raspberrypi/FreeRTOS-Kernel

sigh One more custom fork (like OpenOCD). We currently run untouched FreeRTOS master upstream (they merged SMP into the main branch a while back) with only customized variant hooks. I'll give the custom fork a look but given its low-level register access its going to need real HW to bring up (and ensure we don't break the RP2040). There was a lot of code to write and debug in order to make FreeRTOS work with flash access (pausing the other core even in spite of unmaskable exceptions, ensuring the writing core doesn't try and swap out in the middle of writing, etc.).

For PSRAM, Sparkfun has a library and examples, might be a good starting point: https://github.com/sparkfun/sparkfun-pico/tree/main/sparkfun_pico

Nice. Will take a look. Again, though, it looks like something I'll need HW in hand to futz with. With the work from @PontusO , the linker can place (uninitialized) variable in PSRAM directly (like the AVR PROGMEM decorator), and the Sparkfun guys implemented a custom allocator. There's a happy medium in there somewhere... :)

@alexriegler12, Is there some specific value to running RV vs. the ARM? I could understand doing 2 separate tapeouts, one ARM (with associated licensing $$$) and one RV (cheaper, probably smaller area). Both on one die, with only 1/2 usable at any one time, itseems kind of wasteful and they have to pay the ARM licensing anyway. Cool engineering experiment, though.

@arturo182 , > For FreeRTOS, RPi released a port for both ARM and RISC-V on the RP2350: > https://github.com/raspberrypi/FreeRTOS-Kernel *sigh* One more custom fork (like OpenOCD). We currently run untouched FreeRTOS master upstream (they merged SMP into the main branch a while back) with only customized variant hooks. I'll give the custom fork a look but given its low-level register access its going to need real HW to bring up (and ensure we don't break the RP2040). There was a lot of code to write and debug in order to make FreeRTOS work with flash access (pausing the other core even in spite of unmaskable exceptions, ensuring the writing core doesn't try and swap out in the middle of writing, etc.). > For PSRAM, Sparkfun has a library and examples, might be a good starting point: https://github.com/sparkfun/sparkfun-pico/tree/main/sparkfun_pico Nice. Will take a look. Again, though, it looks like something I'll need HW in hand to futz with. With the work from @PontusO , the linker can place (uninitialized) variable in PSRAM directly (like the AVR `PROGMEM` decorator), and the Sparkfun guys implemented a custom allocator. There's a happy medium in there somewhere... :) @alexriegler12, Is there some specific value to running RV vs. the ARM? I could understand doing 2 separate tapeouts, one ARM (with associated licensing $$$) and one RV (cheaper, probably smaller area). Both on one die, with only 1/2 usable at any one time, itseems kind of wasteful and they have to pay the ARM licensing anyway. Cool engineering experiment, though.
alexriegler12 commented 2024-08-19 23:42:41 +03:00 (Migrated from github.com)

It's mainly that all features of the new chip should be supported. It would be interesting if I can run tests on the cores to compare the performance, if I can get my hand on a Pico 2 soon. It could be that future RPI Pico chips ditch the ARM cores altogether and replace it with RISC-V completely.

It's mainly that all features of the new chip should be supported. It would be interesting if I can run tests on the cores to compare the performance, if I can get my hand on a Pico 2 soon. It could be that future RPI Pico chips ditch the ARM cores altogether and replace it with RISC-V completely.
gigapod commented 2024-08-20 16:22:10 +03:00 (Migrated from github.com)

@earlephilhower - if you send me an email (kirk.benell at sparkfun) with your address, we'll get a board or two with PSRAM shipped to you for development / testing.

-Kirk

@earlephilhower - if you send me an email (kirk.benell at sparkfun) with your address, we'll get a board or two with PSRAM shipped to you for development / testing. -Kirk
Hedda commented 2024-08-23 07:42:47 +03:00 (Migrated from github.com)

Is there some specific value to running RV vs. the ARM? I could understand doing 2 separate tapeouts, one ARM (with associated licensing $$$) and one RV (cheaper, probably smaller area). Both on one die, with only 1/2 usable at any one time, itseems kind of wasteful and they have to pay the ARM licensing anyway. Cool engineering experiment, though.

It's mainly that all features of the new chip should be supported. It would be interesting if I can run tests on the cores to compare the performance, if I can get my hand on a Pico 2 soon. It could be that future RPI Pico chips ditch the ARM cores altogether and replace it with RISC-V completely.

That is my guess as well.Just speculations but it would make sense that this is partially an architecture experiment on the RP2350/Pico2 as well as a stop-gap to give developers of libraries like yours and other projects a few years head start to test and add support for future MCU models that will probly only have RISC-V instruction set architecture, as by doibg this there is then is a greater chance those libraries/projects have matured their RISC-V support enough so there will not as much work if and when they release a new MCU and Pico board variant that only has RISC-V cores.

I am almost willing to bet that they will release a pure RISC-V cores-only MCU in 3-years time. And that they will release two different variants at the same time, with one model only having RISC-V cores and a other variant only having ARM cores. That way they would after that have two lineups, (which is more similar to how Espressif MCU product lineup). They have at least now given library developers a chance to catch up and thus allow everyone not to stress as much when they fully change to pure RISC-V instruction set architecture.

> > Is there some specific value to running RV vs. the ARM? I could understand doing 2 separate tapeouts, one ARM (with associated licensing $$$) and one RV (cheaper, probably smaller area). Both on one die, with only 1/2 usable at any one time, itseems kind of wasteful and they have to pay the ARM licensing anyway. Cool engineering experiment, though. > > > It's mainly that all features of the new chip should be supported. It would be interesting if I can run tests on the cores to compare the performance, if I can get my hand on a Pico 2 soon. **It could be that future RPI Pico chips ditch the ARM cores altogether and replace it with RISC-V completely.** That is my guess as well.Just speculations but it would make sense that this is partially an architecture experiment on the RP2350/Pico2 as well as a stop-gap to give developers of libraries like yours and other projects a few years head start to test and add support for future MCU models that will probly only have RISC-V instruction set architecture, as by doibg this there is then is a greater chance those libraries/projects have matured their RISC-V support enough so there will not as much work if and when they release a new MCU and Pico board variant that only has RISC-V cores. I am almost willing to bet that they will release a pure RISC-V cores-only MCU in 3-years time. And that they will release two different variants at the same time, with one model only having RISC-V cores and a other variant only having ARM cores. That way they would after that have two lineups, (which is more similar to how Espressif MCU product lineup). They have at least now given library developers a chance to catch up and thus allow everyone not to stress as much when they fully change to pure RISC-V instruction set architecture. * https://github.com/earlephilhower/arduino-pico/issues/2325
gigapod commented 2024-08-23 18:10:01 +03:00 (Migrated from github.com)

All -

I just wanted to pass on a few items we learned over the past 3 months in implementing PSRAM on our the RP2350 boards that might be helpful for the port. These are all reflected in the https://github.com/sparkfun/sparkfun-pico repo we put together.

  • The start memory mapped address for PSRAM is fixed - part of the pico-sdk. (0x11000000).
  • All the boards we know of seem to use some version of the APS6404L PSRAM IC
  • Key needs to detect, initialize and use PSRAM is the CS pin of the IC and what max frequency supported. Everything else can be determined at runtime. I could see the presence of a PSRAM CS pin define as the key to enable/setup PSRAM at startup.
  • Clock frequency is determined by VDD supplied to the IC: 133Mhz @ VDD=3.0V, 109MHhz @ VDD=3.3V (what we use)

We provided examples implementing an allocator based on that Circuit Python was using, which was also based on what the ESP32 IDF provides (since some ESP32 modules include PSRAM).

Anyway, I hope this is helpful.

Also, if you're an active member on this porting effort, do feel free to contact me as noted above. We should have more RP2350 boards in a week or so, and I'd be happy to send a board to the core porting team - as well as a follow-on board that includes wifi support.

-Kirk

All - I just wanted to pass on a few items we learned over the past 3 months in implementing PSRAM on our the RP2350 boards that might be helpful for the port. These are all reflected in the https://github.com/sparkfun/sparkfun-pico repo we put together. - The start memory mapped address for PSRAM is fixed - part of the pico-sdk. (0x11000000). - All the boards we know of seem to use some version of the APS6404L PSRAM IC - Key needs to detect, initialize and use PSRAM is the CS pin of the IC and what max frequency supported. Everything else can be determined at runtime. I could see the presence of a PSRAM CS pin define as the key to enable/setup PSRAM at startup. - Clock frequency is determined by VDD supplied to the IC: 133Mhz @ VDD=3.0V, 109MHhz @ VDD=3.3V (what we use) We provided examples implementing an allocator based on that Circuit Python was using, which was also based on what the ESP32 IDF provides (since some ESP32 modules include PSRAM). Anyway, I hope this is helpful. Also, if you're an active member on this porting effort, do feel free to contact me as noted above. We should have more RP2350 boards in a week or so, and I'd be happy to send a board to the core porting team - as well as a follow-on board that includes wifi support. -Kirk
earlephilhower commented 2024-08-24 20:38:10 +03:00 (Migrated from github.com)

Thanks @PontusO for the boards w/PSRAM and WIFI (and custom SWD adapters...I'm sure to need them!), @gigapod for the SparkFun board w/PSRAM, and @Architeuthis-Flux for the OG Pico 2s (very nice packaging, BTW! And where you found a plastic punch labeler this century I have no idea 😆)!

@gigapod if you're using an ESP chip on WiFi for the next board, if you make sure it has proper connections for esp-hosted-fg and ESPHost it will "just work" with the IP stack here (using their FW, of course, and not the AT one).

Also, @gigapod did you flip the Vdd and speeds? 133@3.0 and 109@3.3? It just seems odd to have higher V but lower F.

Thanks @PontusO for the boards w/PSRAM and WIFI (and custom SWD adapters...I'm sure to need them!), @gigapod for the SparkFun board w/PSRAM, and @Architeuthis-Flux for the OG Pico 2s (very nice packaging, BTW! And where you found a plastic punch labeler this century I have no idea :laughing:)! @gigapod if you're using an ESP chip on WiFi for the next board, if you make sure it has proper connections for `esp-hosted-fg` and `ESPHost` it will "just work" with the IP stack here (using their FW, of course, and not the `AT` one). Also, @gigapod did you flip the Vdd and speeds? 133@3.0 and 109@3.3? It just seems odd to have higher V but lower F.
gigapod commented 2024-08-24 20:49:08 +03:00 (Migrated from github.com)

@gigapod if you're using an ESP chip on WiFi for the next board, if you make sure it has proper connections for esp-hosted-fg and ESPHost it will "just work" with the IP stack here (using their FW, of course, and not the AT one).

Also, @gigapod did you flip the Vdd and speeds? 133@3.0 and 109@3.3? It just seems odd to have higher V but lower F.

@earlephilhower
Some follow-ups:

  • WiFi will be on a non-ESP solution - same as what the forthcoming Pico 2 W uses ... expected in Q4. Should be almost the same to Pico W functional use - at least in our testing with micro python on proto boards
  • Vdd and speeds - yeah, seems backwards, but 133@VDD=3.0, and 109@VDD=3.3 is correct from the data sheet here

quick screen shot:

Screenshot 2024-08-24 at 11 43 56 AM
> > @gigapod if you're using an ESP chip on WiFi for the next board, if you make sure it has proper connections for `esp-hosted-fg` and `ESPHost` it will "just work" with the IP stack here (using their FW, of course, and not the `AT` one). > > Also, @gigapod did you flip the Vdd and speeds? 133@3.0 and 109@3.3? It just seems odd to have higher V but lower F. @earlephilhower Some follow-ups: - WiFi will be on a non-ESP solution - same as what the forthcoming Pico 2 W uses ... expected in Q4. Should be almost the same to Pico W functional use - at least in our testing with micro python on proto boards - Vdd and speeds - yeah, seems backwards, but 133@VDD=3.0, and 109@VDD=3.3 is correct from the data sheet [here](https://cdn.sparkfun.com/assets/0/a/3/d/e/APS6404L_3SQR_Datasheet.pdf) quick screen shot: <img width="500" alt="Screenshot 2024-08-24 at 11 43 56 AM" src="https://github.com/user-attachments/assets/985bde79-d502-4f89-b542-dd5ce22f5a3d">
earlephilhower commented 2024-08-24 21:00:05 +03:00 (Migrated from github.com)

Great, thanks for the info on the WiFi and the PSRAM. Odd on the datasheet but oh well, the variant will pass in a clock # and we'll use that along w/the CS and call it a day!

Great, thanks for the info on the WiFi and the PSRAM. Odd on the datasheet but oh well, the variant will pass in a clock # and we'll use that along w/the CS and call it a day!
earlephilhower commented 2024-08-25 02:28:45 +03:00 (Migrated from github.com)

The way I've implemented PSRAM is to allow both PSRAM decorators (works like PROGMEM) and pmalloc/pcalloc (both in the rps250/PSRAMTest example). The PSRAM variables get placed at the beginning of PSRAM, and what's leftover is set to the TLSF allocator. When a pointer to PSRAM is passed to realloc or free it "does the right thing" and calls TLSF instead, while taking care of locking and IRQs. It needs documentation and only had basic testing, but it seems a straightforward connection.

PSRAM can be used now for C++ objects by using placement new constructors. I'm debating whether to allow bracketing a block with an RAII-like object which causes all memory allocs to use PSRAM during its lifetime.

Object *o;
{
    PSRAMAllocation x;
    o = new Object(params...);
}
The way I've implemented PSRAM is to allow both `PSRAM` decorators (works like `PROGMEM`) and `pmalloc`/`pcalloc` (both in the rps250/PSRAMTest example). The `PSRAM` variables get placed at the beginning of PSRAM, and what's leftover is set to the TLSF allocator. When a pointer to PSRAM is passed to `realloc` or `free` it "does the right thing" and calls TLSF instead, while taking care of locking and IRQs. It needs documentation and only had basic testing, but it seems a straightforward connection. PSRAM can be used now for C++ objects by using placement new constructors. I'm debating whether to allow bracketing a block with an RAII-like object which causes all memory allocs to use PSRAM during its lifetime. ```` Object *o; { PSRAMAllocation x; o = new Object(params...); } ````
earlephilhower commented 2024-08-25 06:16:38 +03:00 (Migrated from github.com)

I think other than docs this is good to go for an initial release. While I'm sure there are bugs, I don't actually know of anything not working on the 2350 other than FreeRTOS and OTA (both of which look to be very involved and I'd not want to hold up a release on them).

I think other than docs this is good to go for an initial release. While I'm sure there are bugs, I don't actually know of anything not working on the 2350 other than FreeRTOS and OTA (both of which look to be very involved and I'd not want to hold up a release on them).
FeuerSturm commented 2024-08-25 07:51:31 +03:00 (Migrated from github.com)

@earlephilhower
First of all, thanks a lot for all the work you are doing!
Please pardon my lack of knowledge that results in a probably stupid question:
Will all TinyUSB features work right out of the box with this PR for the RP2350, receiving USB HID packets, setting USB vendor and product specifically?

@earlephilhower First of all, thanks a lot for all the work you are doing! Please pardon my lack of knowledge that results in a probably stupid question: Will all TinyUSB features work right out of the box with this PR for the RP2350, receiving USB HID packets, setting USB vendor and product specifically?
earlephilhower commented 2024-08-25 07:59:29 +03:00 (Migrated from github.com)

@FeuerSturm TinyUSB in the Pico-SDK repo works fine. The CDC(serial) works as does HID (I tested the keyboard example, but if 1 works the others are just a different report format). Assuming Adafruit_TinyUSB has moved to the latest version of TinyUSB then it should work as well if that's what you were asking.

@FeuerSturm TinyUSB in the Pico-SDK repo works fine. The CDC(serial) works as does HID (I tested the keyboard example, but if 1 works the others are just a different report format). Assuming Adafruit_TinyUSB has moved to the latest version of TinyUSB then it should work as well if that's what you were asking.
FeuerSturm commented 2024-08-25 08:11:18 +03:00 (Migrated from github.com)

@earlephilhower
Thanks, yes, that was exactly what I was asking.
I am eager to get home tonight and try it out 👍

@earlephilhower Thanks, yes, that was exactly what I was asking. I am eager to get home tonight and try it out 👍
earlephilhower commented 2024-08-25 08:17:25 +03:00 (Migrated from github.com)

Awesome. A quick test of the Adafruit_TinyUSB boot-keyboards and mass storage device examples worked fine on the RP2350, so I believe they're all up to date.

Awesome. A quick test of the Adafruit_TinyUSB boot-keyboards and mass storage device examples worked fine on the RP2350, so I believe they're all up to date.
earlephilhower commented 2024-08-25 08:31:11 +03:00 (Migrated from github.com)

@Architeuthis-Flux I just noticed the breadboard you sent was also an RP2350 board in disguise!

I haven't looked too deeply into it, but I assume the 2350 actually does the analog mux control and it doesn't really make sense to add a Jumperless RP2350 board to the menus, yes? If the user flashes the board they'll basically lose all the cool functionality and (most importantly) the RGBs!

@Architeuthis-Flux I just noticed the breadboard you sent was also an RP2350 board in disguise! I haven't looked too deeply into it, but I assume the 2350 actually does the analog mux control and it doesn't really make sense to add a `Jumperless RP2350` board to the menus, yes? If the user flashes the board they'll basically lose all the cool functionality and (most importantly) the RGBs!
Architeuthis-Flux commented 2024-08-25 09:37:13 +03:00 (Migrated from github.com)

@Architeuthis-Flux I just noticed the breadboard you sent was also an RP2350 board in disguise!

I haven't looked too deeply into it, but I assume the 2350 actually does the analog mux control and it doesn't really make sense to add a Jumperless RP2350 board to the menus, yes? If the user flashes the board they'll basically lose all the cool functionality and (most importantly) the RGBs!

I've spent the last few days getting all the firmware to run all the Jumperless 23(V5)0 stuff on a single core (I was using core 1 for the LEDs and sending data to the crossbar switches, but it doesn't really need all that), so I can leave the other one completely free to run arbitrary user code. So yes, it would be amazing to add Jumperless to Arduino-pico's menu. Next step is for me to write an abstraction layer to treat it as just another dev board. It'll be stretching the concept of a typical board definition, being single core with 10 GPIO, 6 (+-8V shifted) ADCs, 4 (+-8V) power supplies, 2 current sensors, a probe, 445 addressable LEDs (making a weirdly spaced 14x30 display), and the ability to route all that stuff anywhere.

I'd be happy to keep the latest version of the firmware accessible in a convenient format somewhere so it can be pulled like any other library, and generally do whatever it takes to make life easy for you and Jumperless users.

btw, what I sent you is an OG Jumperless which runs on an RP2040. As soon as the latest Jumperless V5 prototypes with the R2350B get in, you will have one. But take your time, it'll take about a month.

> @Architeuthis-Flux I just noticed the breadboard you sent was also an RP2350 board in disguise! > > I haven't looked too deeply into it, but I assume the 2350 actually does the analog mux control and it doesn't really make sense to add a `Jumperless RP2350` board to the menus, yes? If the user flashes the board they'll basically lose all the cool functionality and (most importantly) the RGBs! I've spent the last few days getting all the firmware to run all the [Jumperless 23(V5)0](https://www.crowdsupply.com/architeuthis-flux/jumperless-v5) stuff on a single core (I _was_ using core 1 for the LEDs and sending data to the crossbar switches, but it doesn't really need all that), so I can leave the other one completely free to run arbitrary user code. So yes, it would be amazing to add Jumperless to Arduino-pico's menu. Next step is for me to write an abstraction layer to treat it as just another dev board. It'll be stretching the concept of a typical board definition, being single core with 10 GPIO, 6 (+-8V shifted) ADCs, 4 (+-8V) power supplies, 2 current sensors, a probe, 445 addressable LEDs (making a weirdly spaced 14x30 display), and the ability to route all that stuff anywhere. I'd be happy to keep the latest version of the firmware accessible in a convenient format somewhere so it can be pulled like any other library, and generally do whatever it takes to make life easy for you and Jumperless users. btw, what I sent you is an [OG Jumperless](https://github.com/Architeuthis-Flux/Jumperless) which runs on an RP2040. As soon as the latest [Jumperless V5](https://github.com/Architeuthis-Flux/JumperlessV5/tree/JumperlOS/Hardware/Jumperless23V50) prototypes with the R2350B get in, you will have one. But take your time, it'll take about a month.
arturo182 commented 2024-08-25 18:27:40 +03:00 (Migrated from github.com)

Would greatly appreciate it if you could also merge https://github.com/earlephilhower/arduino-pico/pull/2352 after this PR but before making a release, thanks!

Would greatly appreciate it if you could also merge https://github.com/earlephilhower/arduino-pico/pull/2352 after this PR but before making a release, thanks!
lyusupov commented 2024-08-26 10:28:39 +03:00 (Migrated from github.com)

Core 4.0.1

Pico 2 build ( with arduino-cli ) still uses ARDUINO_ARCH_RP2040 architecture definition:

image

Is this an intentional quirk ?

Core 4.0.1 Pico 2 build _( with arduino-cli )_ still uses `ARDUINO_ARCH_RP2040` architecture definition: <img width="773" alt="image" src="https://github.com/user-attachments/assets/24bd9a9b-1f56-4216-a768-660804830e0a"> Is this an intentional quirk ?
earlephilhower commented 2024-08-26 16:39:22 +03:00 (Migrated from github.com)

Yes, that's the "Arduino core architecture." To identify which variant, use the SDK's #if defined(PICO_RP2350) define.

Yes, that's the "Arduino core architecture." To identify which variant, use the SDK's `#if defined(PICO_RP2350)` define.
lyusupov commented 2024-08-26 17:50:36 +03:00 (Migrated from github.com)

Ok.
However, ARDUINO_ARCH_RP2350 is also in use in some places to identify the Pico 2. And this fact looks confusing....

image
Ok. However, `ARDUINO_ARCH_RP2350` is also in use in some places to identify the **Pico 2**. And this fact looks confusing.... <img width="886" alt="image" src="https://github.com/user-attachments/assets/a7015950-e96b-4cdb-ad28-5093ecce2a76">
earlephilhower commented 2024-08-26 18:45:44 +03:00 (Migrated from github.com)

Ah, that's probably a bug I made and only in the platform.io stuff. Good catch. I'll update that back to the ARCH_RP2040 define.

Ah, that's probably a bug I made and only in the platform.io stuff. Good catch. I'll update that back to the ARCH_RP2040 define.
earlephilhower commented 2024-08-26 18:50:05 +03:00 (Migrated from github.com)

#2361 to fix

#2361 to fix
zackees commented 2024-08-29 03:23:53 +03:00 (Migrated from github.com)

Hi, I'm a dev at FastLED. Trying to add RP2350 support for FastLED, do you know what I'm doing wrong?

image

This is the board json I'm injecting into ~/.platformio

https://github.com/FastLED/FastLED/blob/master/ci/boards/rpipico2.json

Hi, I'm a dev at FastLED. Trying to add RP2350 support for FastLED, do you know what I'm doing wrong? ![image](https://github.com/user-attachments/assets/b29bf336-bb3b-44b4-ac4c-b03b74322fb2) This is the board json I'm injecting into ~/.platformio https://github.com/FastLED/FastLED/blob/master/ci/boards/rpipico2.json
earlephilhower commented 2024-08-29 04:09:21 +03:00 (Migrated from github.com)

Just a quick note, that JSON was copied from the 4.0.1 release which unfortunately had the Pico2 @ 133 instead of 150MHz. You probably want to pull the latest version of it so you don't leave performance on the table.

What is the error message you're getting?

I don't use P.IO, but do you need to actually specify the board=rpipico2 somewhere? If it's the dict key, rpico2 should be rpipico2.

@maxgerhardt would be the expert here on getting the Pico2 running. He might need to update his platform-rpi library to pull in the latest tools (esp. picotool which is now mandatory but before was unused).

Just a quick note, that JSON was copied from the 4.0.1 release which unfortunately had the Pico2 @ 133 instead of 150MHz. You probably want to pull the latest version of it so you don't leave performance on the table. What is the error message you're getting? I don't use P.IO, but do you need to actually specify the `board=rpipico2` somewhere? If it's the dict key, `rpico2` should be `rpipico2`. @maxgerhardt would be the expert here on getting the Pico2 running. He might need to update his platform-rpi library to pull in the latest tools (esp. picotool which is now mandatory but before was unused).
zackees commented 2024-08-30 05:48:25 +03:00 (Migrated from github.com)

I had a mismatch between the different names. I've fixed that on my end and now i'm waiting for a new compile

I had a mismatch between the different names. I've fixed that on my end and now i'm waiting for a new compile
zackees commented 2024-08-30 05:50:02 +03:00 (Migrated from github.com)

Okay, it made it to the next build failure.... digging in..

rp2350

Okay, it made it to the next build failure.... digging in.. [![rp2350](https://github.com/FastLED/FastLED/actions/workflows/build_rp2350.yml/badge.svg)](https://github.com/FastLED/FastLED/actions/workflows/build_rp2350.yml)
zackees commented 2024-08-30 05:51:21 +03:00 (Migrated from github.com)

this is my platformio.ini file:

; PlatformIO Project Configuration File
;
;   Build options: build flags, source filter
;   Upload options: custom upload port, speed and extra flags
;   Library options: dependencies, extra library storages
;   Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; https://docs.platformio.org/page/projectconf.html

[env:rpipico2]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = rpipico2
framework = framework-arduinopico@https://github.com/earlephilhower/arduino-pico.git
board_build.core = earlephilhower
board_build.filesystem_size = 0.5m
this is my platformio.ini file: ``` ; PlatformIO Project Configuration File ; ; Build options: build flags, source filter ; Upload options: custom upload port, speed and extra flags ; Library options: dependencies, extra library storages ; Advanced options: extra scripting ; ; Please visit documentation for the other options and examples ; https://docs.platformio.org/page/projectconf.html [env:rpipico2] platform = https://github.com/maxgerhardt/platform-raspberrypi.git board = rpipico2 framework = framework-arduinopico@https://github.com/earlephilhower/arduino-pico.git board_build.core = earlephilhower board_build.filesystem_size = 0.5m ```
maxgerhardt commented 2024-08-30 10:54:23 +03:00 (Migrated from github.com)

You're not following my guidance at all with the platformio.ini from https://github.com/FastLED/FastLED/issues/1673#issuecomment-2316314295. framework = arduino has to be given and the updated package as platform_packages = framework-arduinopico@https://github.com/earlephilhower/arduino-pico.git.

I'll fix up the PlatformIO platform then you can test as normal without fancy package updates.

You're not following my guidance at all with the `platformio.ini` from https://github.com/FastLED/FastLED/issues/1673#issuecomment-2316314295. `framework = arduino` has to be given and the updated package as `platform_packages = framework-arduinopico@https://github.com/earlephilhower/arduino-pico.git`. I'll fix up the PlatformIO platform then you can test as normal without fancy package updates.
maxgerhardt commented 2024-08-30 13:55:39 +03:00 (Migrated from github.com)

FYI, dual-core Cortex-M33 on RP2350 is working great in PlatformIO: https://github.com/maxgerhardt/platform-raspberrypi/issues/69#issuecomment-2320836518.

FYI, dual-core Cortex-M33 on RP2350 is working great in PlatformIO: https://github.com/maxgerhardt/platform-raspberrypi/issues/69#issuecomment-2320836518.
zackees commented 2024-08-30 23:34:17 +03:00 (Migrated from github.com)
Thanks, added your suggestion, see https://github.com/FastLED/FastLED/commit/57b74810a885810a7e27baa3c20a83440e4add17
Sign in to join this conversation.