Non-SDK usage

[mhinner]

Hi,

are you willing to make some documentation or package to allow usage without your SDK ? Something like ARM CMSIS, but I would not care if it's just your hardware/regs & hardware/structs files with minor modifications, like what I am trying to use now.

I've got working a small GPIO project using these headerfiles:

./inc/hardware ./inc/hardware/irq.h ./inc/hardware/gpio.h ./inc/hardware/platform_defs.h ./inc/hardware/pico.h ./inc/hardware/pll.h ./inc/hardware/resets.h ./inc/hardware/address_mapped.h ./inc/hardware/regs ./inc/hardware/regs/io_bank0.h ./inc/hardware/regs/ssi.h ./inc/hardware/regs/usb.h ./inc/hardware/regs/intctrl.h ./inc/hardware/regs/uart.h ./inc/hardware/regs/sio.h ./inc/hardware/regs/adc.h ./inc/hardware/regs/timer.h ./inc/hardware/regs/dreq.h ./inc/hardware/regs/i2c.h ./inc/hardware/regs/addressmap.h ./inc/hardware/regs/pio.h ./inc/hardware/regs/rtc.h ./inc/hardware/regs/pads_bank0.h ./inc/hardware/regs/dma.h ./inc/hardware/regs/pll.h ./inc/hardware/regs/spi.h ./inc/hardware/regs/pwm.h ./inc/hardware/regs/xosc.h ./inc/hardware/regs/busctrl.h ./inc/hardware/regs/watchdog.h ./inc/hardware/regs/syscfg.h ./inc/hardware/regs/tbman.h ./inc/hardware/regs/resets.h ./inc/hardware/regs/io_qspi.h ./inc/hardware/regs/sysinfo.h ./inc/hardware/regs/xip.h ./inc/hardware/regs/psm.h ./inc/hardware/regs/vreg_and_chip_reset.h ./inc/hardware/regs/rosc.h ./inc/hardware/regs/pads_qspi.h ./inc/hardware/regs/clocks.h ./inc/hardware/regs/m0plus.h ./inc/hardware/structs ./inc/hardware/structs/scb.h ./inc/hardware/structs/ssi.h ./inc/hardware/structs/usb.h ./inc/hardware/structs/uart.h ./inc/hardware/structs/xip_ctrl.h ./inc/hardware/structs/sio.h ./inc/hardware/structs/adc.h ./inc/hardware/structs/timer.h ./inc/hardware/structs/i2c.h ./inc/hardware/structs/pio.h ./inc/hardware/structs/rtc.h ./inc/hardware/structs/bus_ctrl.h ./inc/hardware/structs/dma.h ./inc/hardware/structs/pll.h ./inc/hardware/structs/ioqspi.h ./inc/hardware/structs/mpu.h ./inc/hardware/structs/spi.h ./inc/hardware/structs/pwm.h ./inc/hardware/structs/xosc.h ./inc/hardware/structs/watchdog.h ./inc/hardware/structs/syscfg.h ./inc/hardware/structs/resets.h ./inc/hardware/structs/psm.h ./inc/hardware/structs/vreg_and_chip_reset.h ./inc/hardware/structs/padsbank0.h ./inc/hardware/structs/interp.h ./inc/hardware/structs/rosc.h ./inc/hardware/structs/pads_qspi.h ./inc/hardware/structs/systick.h ./inc/hardware/structs/clocks.h ./inc/hardware/structs/iobank0.h ./inc/hardware/clocks.h

and the following modified SDK sources:

./boot_stage2.ld ./boot2_w25q080.S ./crt0.S ./gpio.c ./memmap_default.ld

• main.c which contains these routines taken from the SDK: main.c:void pll_init(PLL pll, uint32_t refdiv, uint32_t vco_freq, uint32_t post_div1, uint8_t post_div2) { main.c:void xosc_init(void) { main.c:void clocks_init(void) { main.c:void runtime_init(void) {

The "datasheet" (I would prefer to call it SDK user guide :) ) lacks a lot of important information in my opinion. I can provide feedback on what info I had to find out to get it working (I am still not finished).

Martin

PS: I would also like to see a textual info in boot2 code with it's type, there is some space left, so as it is clear from binary/uf2 what platform it is intended for:

    .ascii "RPi-pico boot2 w25q080"

or even

    .ascii "This is RPi-pico flash image, boot2/w25q080"

(or use board identifier, I believe you have it in some header files)

[swetland]

As a writer of bare-metal Cortex-M code and contributor to a small OS that would like to target rp2040 (https://github.com/littlekernel/lk), I'd like to throw in support for this idea. Having a clean "hw registers and essential init code" package or layer that can be used without the full vendor SDK is very valuable.

It needn't be maintained as an entirely separate package, just a directory hierarchy in the SDK that can be scooped out easily. (for example, Nordic's NRF528xx SDK, which is quite enormous, has modules/nrfx/mdk/... which contains just register headers, init code, and linker files, and it's very easy to just grab that).

[kilograham]

The bootrom builds using the SDK and doesn't pull in much. (there is a PICO_BARE_METAL flag which minimizes what is pulled in) - i know this isn't exactly what you want but gives you an idea

Also have a play with with https://github.com/raspberrypi/pico-playground/tree/master/standalone/static_sdk just set the dependent libraries to the ones you need.

[mhinner]

In my opinion the cmake/PICO_BARE_METAL does not solve the problem at all I do not have to build using sdk at all, my project has separate Makefile (not even cmake).

The problem is requirement to modify several header files to get the "cmsis-like" environment without getting more and more and more included (copied to the project). It's not difficult, but not very practical for updates. I think it can be easily solved by re-organizing the header files dependency and structure a little bit. Plus a tiny piece of documentation and a script to copy all required files out of the SDK directories.

Or maybe we can just use svdconv to generate CMSIS header files, have not checked if supplied svd is complete.

[swetland]

I'm used to having to crack open the TRM and type up a header file for whatever peripheral I need next when doing MCU bringup, because the idea that the vendor would provide working headers and that they'd be licensed under a reasonable license was generally laughable back in the bad old days. Of course that assumes a TRM was available without NDA or threat of lawsuit if you used it to develop and publish open source software.

Now in this shiny new world where useful vendor headers exist, the next battle is one I think if as "all the world is not linux" (eg if you only provide support as a set of GPLv2 Linux Drivers, you make things needlessly difficult for all the other open platforms out there).

Having the hw headers cleanly separable from the SDK would both speed up initial ports of FreeRTOS, LK, Zypher, etc, etc, and make it easy for them to pickup bug fixes, improvements, and future pico family support.

Maybe @mhinner could propose some specific structural changes that would move things in that direction for folks to consider? I have only just started poking at the SDK drop so don't have a good picture myself, just yet.

[lurch]

@mhinner

Or maybe we can just use svdconv to generate CMSIS header files, have not checked if supplied svd is complete.

Yes, the SVD file should be complete - both that and all the files in https://github.com/raspberrypi/pico-sdk/tree/master/src/rp2040/hardware_regs/include/hardware/regs are autogenerated from the same set of input-metadata. Please let us know if there's parts of the SVD that are missing / lacking information.

@swetland

the next battle is one I think if as "all the world is not linux"

You may have noticed that across all our PDFs we've provided instructions for Linux, Windows and MacOS? :slightly_smiling_face:

[swetland]

the next battle is one I think if as "all the world is not linux"

You may have noticed that across all our PDFs we've provided instructions for Linux, Windows and MacOS?

I did mean from a being able to port an open source OS to a new platform standpoint. Once Si vendors started really embracing Linux it started getting hard to get reasonable support for other things. And then they did it again with Android when that started gaining momentum (though at least the kernel is common-ish) (sorry about that).

[lurch]

I'd be fairly surprised to see Android running on the RP2040 :laughing:

[mhinner]

Maybe @mhinner could propose some specific structural changes that would move things in that direction for folks to consider? I have only just started poking at the SDK drop so don't have a good picture myself, just yet.

I will do some experiments with my current source and let you know. I would prefer to use as much from ARM CMSIS as I think there is not many people familiar with RP2040-SDK M0+ generic stuff such as irq handling, furthermore I really do not like code like this:

((io_rw_32 ) (PPB_BASE + M0PLUS_NVIC_ICPR_OFFSET)) = 1 << TIMER_IRQ_0; ((io_rw_32 ) (PPB_BASE + M0PLUS_NVIC_ISER_OFFSET)) = 1 << TIMER_IRQ_0;

(modified generic version of rp irq enable)

I think there should be layered structure, header files that define basic types, then register/struct definitions (not requiring anything board specific!), then helper functions to work with these (such as NVIC_EnableIRQ ). Plus bare-bone startup, gcc runtime init and linker files.

[kilograham]

If you read rptl.io/picoc then it describes the similar layers the SDK has in place. Additionally each piece of functionality that you mention (types, linking, runtime init) are encapsulated in individual interface libraries (i.e. headers, or code + headers) that you can choose to compose yourself. The code you pasted above is not idiomatic and survived from various pre-SDK test code.

[mhinner]

Well.. it's not related to my issue, but I see the similar code all over the place, but it is more or less about coding style.

Also include dependency makes it a bit difficult to use outside the SDK, as I wrote it before, and yes, I have read relevant parts of https://datasheets.raspberrypi.org/pico/raspberry-pi-pico-c-sdk.pdf

I worked a bit with RP2040, I will probably make a script that processes your headerfiles to produce a standalone version (usable with CMSIS), only RP2040 specific stuff will be used.

Alternatively I will use the supplied SVD. May I ask you what tools do you use to convert SVD to header files?

I must add I think you've done great work, if I compare it with (e.g.) STM32 HAL, it's much better design IMHO, mainly for hobby market. It's just that your SDK is targetting 'different audience' than me.

[lurch]

Alternatively I will use the supplied SVD. May I ask you what tools do you use to convert SVD to header files?

We don't generate our header files from the SVD. Instead (as I hinted at earlier), we have some custom python scripts which generate both the SVD file and all the register-headers from the same internal register-description metadata files.

[mhinner]

Thanks for clarification. Are you willing to

1) provide the python scripts + their source data 2) if feasible, auto-generate additional files in future with modification I make to the scripts ?

Basically at this moment I am using this: .../hardware/structs$ (cat ../regs/addressmap.h ; cat .h )| grep -v ^#include | grep -v ^#ifndef | grep -v ^#endif| grep -v ^#define\ _HARDWARE_STRUCT._H | grep -v check_hw_layout > ~/tmp/rp2040_structs.h

& some hand modifications (such as scb/mpu/systick removal as I use CMSIS for this). & include of hardware/regs/...

It's far from perfect, but somehow works with CMSIS, uses almost CMSIS compatible coding style, does not depend on unnecessary files, etc.

[aallan]

provide the python scripts + their source data

Unfortunately this will not be possible.

[lurch]

Also, you seem to be making changes to the .../hardware/structs header-files - however these are all hand-written and it's only the .../hardware/regs header-files that are autogenerated.