PlatformIO Community

RP2040, and in general Zephyr 3.0 support

Zephyr 3.0.0 released recently, but there doesn’t seem to be an entry in the registry for it. I understand that with semver this would possibly introduce many breaking changes, but is there a general plan of when and how Zephyr 3.0.0 would be available?

It’s added support for many boards, and I would like it if RP2040 boards, which were added in this release, would have an RTOS available for install on PlatformIO. Thanks!

1 Like

Indeed, this would be good. This is already tracked in https://github.com/platformio/platform-raspberrypi/issues/32.

Why Zephyr?
FreeRTOS work very well and you will find more materials and support…

Actually I started adding Zephyr 3.1.0 support in https://github.com/maxgerhardt/platform-raspberrypi/tree/zephyr, but the compiled firmware doesn’t run yet – they changed the build process two a 3-stage linking (pre0, pre1, final elf) and that is… giving me a slight headache.

Yeah, FreeRTOS also has support for the RP2040, but neither is that currently a framework in PlatformIO. I’m particularly interested in Zephyr because it provides many HALs that are used by libraries in its ecosystem, allowing for some more hardware-agnostic development, which I’m interested in.

Oh that’s brilliant, I understand that these things take time. I’ll keep an eye on it, thanks for telling me.

1 Like

Mixing SCons, Python and CMAKE :slight_smile:

Yes it is with the latest Arduino-Pico version which I support in https://github.com/platformio/platform-raspberrypi/pull/36, the Arduino-Pico core has FreeRTOS with symmetric multiprocessing (SMP) extensions to do true multicore and multithreading on both Cortex-M0+ cores, really fancy stuff.

But I’m getting closer with Zephyr, at least I corrected some critical linking errors yesterday, but it still does not run… Feels like something tiny is missing.

1 Like

Max, can you share compiler verbose log?

I have the verbose reference build log from Zephyr and PlatformIO on my computer, can send this evening. My gut feeling is that I’ll see pretty quickly what’s missing when comparing them. The current behavior is that after drag-and-dropping the UF2 file on the device, it immediately reappears as a UF2 drive. If the firmware were bad, then it would just do nothing usefull, but the fact that it reappers may point to the UF2 file being bad or the bootloader (boot2_some_flash_chip.S) missing and thus immediately triggering the “oh no I have no firmware, please flash me” behavior.

1 Like

Native Zephyr 3.1.0 build, on Linux, with zephyr-sdk-0.14.2 as toolchain (arm-zephyr-eabi-gcc version 10.3.0): $ /usr/bin/cmake -DWEST_PYTHON=/usr/bin/python3 -B/home/max/zephyrproject/zephyr - Pastebin.com

Converting to uf2, output size: 22528, start address: 0x10000000

Build with PlatformIO, on Windows, used same Zephyr SDK version as toolchain: Processing pico (platform: https://github.com/maxgerhardt/platform-raspberrypi.g - Pastebin.com

Converting to uf2, output size: 21504, start address: 0x10000000

I haven’t yet looked at in more detail.

Max, thanks

why can’t i see: -DCONFIG_ARM -DCONFIG_MP_NUM_CPUS=?
I try to compile ( Zephir ) it as a library

But that’s in the .pio\build\zephyr\include\generated\autoconf.h with a tons of other stuff

#define CONFIG_BOARD "rpi_pico"
#define CONFIG_RP2_FLASH_W25Q080 1
#define CONFIG_SOC "rp2040"
#define CONFIG_SOC_SERIES "rp2"
#define CONFIG_NUM_IRQS 26
#define CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC 125000000
#define CONFIG_FLASH_SIZE 2048
#define CONFIG_FLASH_BASE_ADDRESS 0x10000000
//..
#define CONFIG_ARM 1
#define CONFIG_ARCH_IS_SET 1
#define CONFIG_SRAM_SIZE 264
#define CONFIG_SRAM_BASE_ADDRESS 0x20000000
//..
#define CONFIG_MP_NUM_CPUS 1
#define CONFIG_HAS_RPI_PICO 1
#define CONFIG_PICOSDK_USE_UART 1
#define CONFIG_PICOSDK_USE_GPIO 1
#define CONFIG_ZEPHYR_HAL_RPI_PICO_MODULE 1

and I’ve seen compile commands that use this via -imacros [..]autoconf.h compiler flags so that these macros are always present.

In the Zephyr reference build, those are the same /home/max/zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h

#define CONFIG_BOARD "rpi_pico"
#define CONFIG_RP2_FLASH_W25Q080 1
#define CONFIG_SOC "rp2040"
#define CONFIG_SOC_SERIES "rp2"
#define CONFIG_NUM_IRQS 26
#define CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC 125000000
#define CONFIG_FLASH_SIZE 2048
#define CONFIG_FLASH_BASE_ADDRESS 0x10000000
#define CONFIG_PINCTRL 1
#define CONFIG_HEAP_MEM_POOL_SIZE 0
#define CONFIG_ROM_START_OFFSET 0x0
#define CONFIG_CORTEX_M_SYSTICK 1
#define CONFIG_SYS_CLOCK_TICKS_PER_SEC 10000
#define CONFIG_SERIAL_INIT_PRIORITY 55
#define CONFIG_TEST_EXTRA_STACK_SIZE 0
#define CONFIG_SERIAL 1
#define CONFIG_BUILD_OUTPUT_UF2_USE_FLASH_BASE 1
#define CONFIG_MP_NUM_CPUS 1
1 Like

dam … Zephyr is very complex OS for a simple library