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

✔️ PASSED

1a5d712 fix: reintroduce led0 defines

Success	Failures	Total	Runtime
10379	0	10379	14m:15s

Artifacts

• Documentation preview

[AnnsAnns]

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

[crasbe]

Some mostly minor style comments. Speaking of comments, a lot of comments are still in the // style, which we don't use: https://github.com/RIOT-OS/RIOT/blob/master/CODING_CONVENTIONS.md#comments

Some defines and functions are not documented yet, but I'll have to review what Doxygen complains about. Also I have not checked the generated Doxygen documentation yet.

[crasbe]

I think RIOT already has a library of atomic commands. Perhaps @maribu knows more about that?

[AnnsAnns]

I did not know that this was something universal, the more you know

[AnnsAnns]

Oh are you referring to these? https://github.com/AnnsAnns/RIOT/blob/cac44edec7c7ccdc7ea618aef27c4335490b26d1/cpu/rpx0xx/include/io_reg.h#L54

[crasbe]

No, I had this in mind: https://github.com/RIOT-OS/RIOT/tree/master/sys/include/atomic_utils.h

Sorry for not posting the link initially.

[AnnsAnns]

I wont lie, that header is a bit overwhelming and complicated 😰 Is it something where you still need to write the functions for or is this just something that works out of the box.

[maribu]

It will work out of the box and provides atomic access, assuming all (potentially) concurrent accesses go via those functions.

[maribu]

Here is the doc btw: https://doc.riot-os.org/group__sys__atomic__utils.html

[AnnsAnns]

If I understand this correctly this would mean Id also have to adjust the shared UART code in the followup so Id rather avoid it and simply use the same method signatures that the rp2040 uses for atomic operations

[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: #21545 (comment))

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]

Again, mostly small stuff.

[crasbe]

No, I had this in mind: https://github.com/RIOT-OS/RIOT/tree/master/sys/include/atomic_utils.h

Sorry for not posting the link initially.

[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?

[crasbe]

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

Probably not much, but I don't have much time and no hardware yet for testing.

[AnnsAnns]

Thank you for the reviews (as always 😄)

[Teufelchen1]

Where does this file come from?

[Teufelchen1]

Ah from the pico sdk. That is not pulled automatically.

[crasbe]

I know why that is...
The Makefile adds picosdk to the USEPKG, however picosdk is not a package. It is stored in dist/tools, along with picotool. This was introduced in #21269.

Therefore the USEPKG does not do anything.

[crasbe]

The best approach would probably to move picosdk from dist/tools to pkg (in a separate PR, as that might also require changes to the picotool Makefile).

[crasbe]

Okay it's not that easy apparently, but I don't have time to look into it right now.

[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

[Teufelchen1]

can you add a few words on how the bootselect works?

[AnnsAnns]

With that, do you mean how to get into the flashing state via the bootselect button?

[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 😞 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 😅