earlephilhower commented 2 months ago

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 2 months ago

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 2 months ago

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 2 months ago

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

Architeuthis-Flux commented 2 months ago

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.

earlephilhower commented 2 months ago

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 2 months ago

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 2 months ago

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 2 months ago

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

arturo182 commented 2 months ago

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!

earlephilhower commented 2 months ago

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 2 months ago

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 2 months ago

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

arturo182 commented 2 months ago

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 2 months ago

@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 2 months ago

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 2 months ago

@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 2 months ago

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 2 months ago

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 2 months ago

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 2 months ago

@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:

earlephilhower commented 2 months ago

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 2 months ago

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 2 months ago

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 2 months ago

@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 2 months ago

@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 2 months ago

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

earlephilhower commented 2 months ago

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 2 months ago

@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 2 months ago

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

arturo182 commented 2 months ago

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 2 months ago

Core 4.0.1

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

Is this an intentional quirk ?

earlephilhower commented 2 months ago

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

lyusupov commented 2 months ago

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

earlephilhower commented 2 months ago

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 2 months ago

2361 to fix

zackees commented 2 months ago

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

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

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

earlephilhower commented 2 months ago

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 1 month ago

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 1 month ago

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

zackees commented 1 month ago

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 1 month ago

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 1 month ago

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

zackees commented 1 month ago

Thanks, added your suggestion, see https://github.com/FastLED/FastLED/commit/57b74810a885810a7e27baa3c20a83440e4add17

earlephilhower / arduino-pico

Add RP2350 support #2337

2361 to fix