Further Raspberry Pi RP2xxx development on pico-sdk

[KarlK90]

Hi Giovanni,

instead of posting to Discord I rather post here as this seems better suited for longer posts.

To get to the point: I advocate baseing further development stronger on the offical pico-sdk's "Hardware Structs Library" and "Hardware Registers Library" instead on the offical or our own CMSIS header files. At the moment we mostly use the "Runtime Support Library" as outlined in the official pico-sdk manual[1].

These libraries can be used in relativ isolation and don't necessarly pull in all the other dependencies in the pico-sdk (sure there is still some "polution"). For better RTOS isolation the pico-sdk now also features a `PICO_CONFIG_RTOS_ADAPTER_HEADER` define that allows us to overwrite some decisions of pico-sdk e.g. naming of linker sections. This could surely be expanded.

To add another thought: I assume that any bigger application (e.g. QMK) that leverages the custom RP2040/RP2350 peripherals like PIOs that don't fit into the existing ChibiOS HAL drivers will use the pico-sdk as a dependency anyway. Same is true for support libraries in the pico-sdk like the boot2 startup code[2] for the RP2040 which is needed for executing from flash. Or the optimized assembly for gcc intrinsics that use the RP2040 built-in integer divider[3].

After our chat in Discord I tried to go down the route of using the official CMSIS headers from RPI[4], which have been generated from their official SVD files using SVDConv. These headers are lacking in various ways:

1. They only provide structs for the drivers, no register defines. These can be generated though.
2. The resulting structs do not cluster repeating registers[5] in peripherals like GPIOs or DMA/PWM channels, same is true for the register defines - once generated.
3. It is possible to pre-process the SVD files to generate the clusters and better defines. I tried that process, but it is *a lot* of work with sub-optimal results in the struct and define nameing.
4. The generated CMSIS peripheral base address defines have name collisions with the pico-sdk headers
5. I assume that there will probably be more conflicts - but I stopped at this point to write this post.

Of course it is still possible to write our own CMSIS headers or to improve the code generation but both options are error prone and time consuming.

For me personally I would like to rather spend my time in leveraging the existing struct and header defines from pico-sdk and refactor the existing drivers (which is pretty straight forward [7]). If the coupling is unnessarly high there is a good chance that the pico-sdk maintainers are open to a PR (at least from my experience).

So yes, relying on pico-sdk means making compromises, but maybe not as bad as it used to be?

Looking forward to your response

Cheers,
Stefan / KarlK90

[1]: See Chapter 2.3 https://datasheets.raspberrypi.com/pico ... -c-sdk.pdf
[2]: https://github.com/raspberrypi/pico-sdk ... oot_stage2
[3]: https://github.com/raspberrypi/pico-sdk ... /divider.S
[4]: https://github.com/raspberrypi/pico-sdk ... SIS/Device
[5]: https://github.com/raspberrypi/pico-sdk ... #L298-L350
[6]: https://github.com/KarlK90/ChibiOS/blob ... P2040.yaml and https://github.com/KarlK90/ChibiOS/comm ... 4434443794
[7]: https://github.com/KarlK90/ChibiOS-Cont ... 80268e119b

[Giovanni]

Hi,

There are 2 main problems with the SDK on top of my mind:

1) Naming of types conflicting with OSAL and chibios in general, see semaphore_t but there are others.
2) Bad practice of inclusions with relative paths.

This is why my preferred way is to use CMSIS files, if official ones are insufficient then lets use our own version and only for those peripherals used by HAL: 1) We don't need a full header, 2) It is already largely done, 3) It is a one-time effort.

Integration of SDK for use of other peripherals would still be allowed (we already include some SDK files for initialization) but integration problems would not be in our perimeter.

Giovanni

[KarlK90]

Hi Giovanni,

thanks for your quick reply. I'll try to address your concerns:

1) Naming of types conflicting with OSAL and chibios in general, see semaphore_t but there are others.

For a collision test[1] I included all headers from the mentioned "Hardware Structs Library" and "Hardware Registers Library" that I want to use instead of CMSIS:

Code: Select all

pico-sdk/src/rp2350/hardware_structs/include/hardware/structs
pico-sdk/src/rp2350/hardware_regs/include/hardware/regs


And enabled all RT features in my chconf.h - this includes the semaphores you mentioned. This compiles cleanly without any errors or duplicate struct or macro definitions. These libraries have transitive dependencies to pico_platform and pico_base_headers, which we already include for the startup code but do not depend or include any specific implementation or abstractions like semaphores/mutexes. The really only describe the hardware layout and register bits.

2) Bad practice of inclusions with relative paths.

I'm not quite sure what you mean here, but the include paths like #include "hardware/regs/clocks.h" should prevent most collisions in the application space?

This is why my preferred way is to use CMSIS files, if official ones are insufficient then lets use our own version and only for those peripherals used by HAL: 1) We don't need a full header, 2) It is already largely done, 3) It is a one-time effort.

1. Agreed
2. That is only true for RP2040 and peripherals like USB is missing
3. Same is true for switching the existing drivers over to the hardware structs and regs library - which is largely mechanical work that can be done fast. Plus the effort for writing the RP2350 headers is already done. As they are the official ones that the whole SDK is building upon also pretty much battle tested whereas our implementation effort would be prone to accidental errors and incomplete.

As another point I would like to add that if RaspberryPi releases another MCU that is highly compatible it would reduce the work needed for porting as we already would have switched to their libraries.

If there is a chance to switch to these libraries instead of our CMSIS headers let me know - I would happily invest the time .

Cheers,
KarlK90 / Stefan

[1]: https://github.com/KarlK90/ChibiOS/comm ... 5e014653e5