CPU/Boards: Add Raspberry Pi Pico 2 (RP2350) support

[AnnsAnns]

Contribution description

This PR introduces the Raspberry Pi Pico 2 to Riot.

Currently the periph list is rather limited, it has GPIO and non-configurable extremely basic write only UART support. It does however, already configure the clocks using the XOSC and works well within the RIOT Ecosystem.

It supports OpenOCD, which I am currently using and (as introduced in #21269) Picotool for debugging/flashing. (And JLink though I did not test this)

One other big note is that we currently only support the Cortex M33 cores of the Pico 2, however, most of the code should reusable when adding support for the Pico 2s RISC-V cores.

There is still a lot to be done, the documentation is still "limited", however, I felt like it would make more sense to at least open the PR itself before continuing. Esp. to avoid potentially duplicated efforts from occurring.

I also took the liberty to already use #21515 for the license headers. I am not sure whether this is already the consensus.

Testing procedure

To showcase the current features I included a very minimal example, this is not intended to get merged but merely to showcase what is available as of now.

Issues/PRs references

[riot-ci]

Murdock results

:heavy_check_mark: PASSED

359d3a9efdba0ce5648f1186d0f5c5cba363e240 boards: Raspberry Pi Pico 2 support

Success	Failures	Total	Runtime
10560	0	10560	10m:34s

Artifacts

• Documentation preview

[AnnsAnns]

Also Murdock is "failing" because of the example that will not be merged, please ignore that :stuck_out_tongue:

[AnnsAnns]

After investigating the feasibility of using shared components such as UART I have decided that it probably makes more sense to limit the scope of this PR. (Also mentioned here: https://github.com/RIOT-OS/RIOT/pull/21545#discussion_r2148158585)

The idea of this PR is to add minimal support, and then later in a followup PR add support for the shared components such as the RP2040 UART Driver.

Doing this in this PR would most likely heavily impact reviewability, which I'd like to avoid, esp. when moving to a shared component would require major adjustments to some parts of the code.

[crasbe]

Please also check the Doxygen warnings/errors from the Static Test. Now that the Doxygen headers are included, Doxygen actually evaluates many of the headers which previously weren't.

[AnnsAnns]

I removed the example from the PR, for historic context, this was the example: https://github.com/RIOT-OS/RIOT/blob/4d7cc7dd9aa31ca371a1f627f98f24dfd4bc32ce/examples/basic/minimal/main.c

[crasbe]

fix: one day I will not have whitespace errors

You can also run the static tests locally, you know? :D With make static-test in the base directory.

[AnnsAnns]

Hey, just as a small status update, no pressure, is there anything that I still need to do for this PR?

[AnnsAnns]

Thank you for the reviews (as always :smile:)

[Teufelchen1]

1. The pico sdk is neither automatically pulled in nor is it explained in the doc that one should install it (and how to do it)
2. Doing make term automatically tried to pull picotool but failed due to libusb not installed - easy fix from my site (non-issue)
3. You are missing the CLOCK_CORECLOCK definition in periph_cpu.h
4. I could flash default and blinky. I was not able to get a term on them (no /dev/tty* showed up). Blinky did not blink the LED.
5. There are a lot of warnings when compiling in uart.cand some in gpio.c

[AnnsAnns]

1. The pico sdk is neither automatically pulled in nor is it explained in the doc that one should install it (and how to do it)

   2. Doing make term automatically tried to pull picotool but failed due to libusb not installed - easy fix from my site (non-issue)

   3. You are missing the CLOCK_CORECLOCK definition in periph_cpu.h

   4. I could flash default and blinky. I was not able to get a term on them (no /dev/tty* showed up). Blinky did not blink the LED.

   5. There are a lot of warnings when compiling in uart.cand some in gpio.c

Was this using picotool or using openocd? With picotool you might have to reinsert the pico 2 for the program to execute. The picosdk stuff is a bit unfortunate, will try to fix this in a separate PR as @crasbe suggested.

[Teufelchen1]

That was using picotool. I tried reinserting the pico but without success.

[AnnsAnns]

Man :disappointed: Will have to investigate

[AnnsAnns]

Little status update, the two culprits appear to be:

1. Flaws in documentation, as I did not clearly state (nor properly test) picotool support and forgot that UART would break
2. Blinky requires a few defines that I did not have in the project to properly function, the LED0 defines also appear to require "special" handling given that the pico2 (compared to pico1) has some safeguards in place that disable gpio pins by default. Initially this worked fine for the project since I had initialized pins for debug purposes but in the process of cleaning up it appears like I did a classical heisenberg bug :sweat_smile:

[crasbe]

You could (temporarily) add the rpi-pico-2 to the Quickbuild-Boards, similar to this commit: https://github.com/RIOT-OS/RIOT/pull/21590/commits/6d2ec699c212a77a385d51d0184ce03e6eb8006e

Currently CI does not actually build the quickbuild-applications for the RP2350 I think.

[AnnsAnns]

Will work through this :+1:

[AnnsAnns]

Just tested using #21629 it appears to work :)

[This comment was written before the new review comments]

[AnnsAnns]

Still works for me with the review changes applied

[AnnsAnns]

#21629 is currently also within this PR, I will revert/rebase it once it has been merged, this makes this PR flashable in the meantime though

[crasbe]

If you want to, you can also squash the comments down a bit. Just make sure not to accidentally squash in stuff you don't want to keep 😅

[AnnsAnns]

If you want to, you can also squash the comments down a bit. Just make sure not to accidentally squash in stuff you don't want to keep 😅

Squashed everything before the PR cherry-pick (otherwise rebasing would probably become hell)

[crasbe]

You can rebase this now :)

[crasbe]

Some of the files have the wrong indentation width (two spaces instead of four). I think VS Code can automagically fix that for you.

[AnnsAnns]

Some of the files have the wrong indentation width (two spaces instead of four). I think VS Code can automagically fix that for you.

VSCode was really fighting back against me creating rubbish formatting and trying to gaslight me into believing that 2 spaces are actually 4 spaces in some files but I think Ive fixed all of the indentation issues now, ty for noticing

[crasbe]

I think this had some unintended side-effects:

All the block comments are now incorrectly formatted 👀

[AnnsAnns]

I think this had some unintended side-effects:

All the block comments are now incorrectly formatted 👀

fixed

[AnnsAnns]

This one block got missed. But other than that I think we went through everything enough times.

Do you still have anything left to do or is this ready?

Squashing time :stuck_out_tongue:

[AnnsAnns]

Thank you for the countless reviews and patches over the last months :partying_face:

[crasbe]

You're welcome :)