zig-zephyr

Case study of interweaving zephyr and zig

Motivation

Zephyr is a mature RTOS which is written in C, Zig is a new envolving programming language.

We like to investigate the possibilities of using Zig in the context of Zephyr. This could mean:

writing the application in Zig
write Zephyr drivers or modules in Zig
use Zig as Build System

Could this be achieved in a minimal invasive approache?

One existing example for an aplication written in Zig using Zephyr can be found here: zig-zephyr-hello . What could be improved to get a smoother interaction without forcing us to write wrappers in C to make use of Zephyr from Zig.

Current Status

[X] Devicetree is translated to Zig because C Devicetree macros are not usable from Zig.
[X] Writing a Zephyr application in Zig, using C imported types and functions.
[X] Compiling Zephyr using zig cc as toolchain (linking zephyr_pre0.elf step does not work).
[ ] Translate KConfig to Zig
[ ] Building Zephyr using the Zig build system instead of CMake

Preconditions

A working Zephyr setup. I set it up as I have described it here. I used the zephyr sdk as non-zig toolchain.
In order to compile the Zig example the file
```
zephyrproject/zephyr/scripts/build/gen_syscalls.py
    
```
has to be patched by moving the line
```
wrap += "\t" + "compiler_barrier();\n"
    
```
just before the line:
```
wrap += "#endif\n"
    
```
or removing it at all. The reason for this is propably a bug in Zig which refuses to inline the syscall functions if the compiler (memory) barrier is there an results in undefined references.
An Arm Board for testing. For other boards the file of this repository
```
zig-zephyr/cmake/compiler/zig/zig-target.cmake
    
```
could be extended.
If using zig cc as toolchain, then the path of the zephyr sdk has to be adapted to your installation in the file CMakeLists.txt:
```
set(ZEPHYR_SDK_INSTALL_DIR $ENV{HOME}/bin/zephyr-sdk-0.15.1)
    
```
and the file zephyr-sdk-gcc.
The file src/c.zig contains a board (in our case for adafruit_feather_nrf52840) specific define:
```
@cDefine("NRF52840_XXAA", "");
    
```
this should be changed to suits your board.

Building the Examples

You have to adapt the commands for your board, I used the adafruit_feather_nrf52840 board. The C application (~src/main.c) is the blinky example taken from the Zephyr samples. The Zig application (~src/main.zig) is the equivalent in zig.

Compile main.c using Zephyr sdk

west build -d build -b adafruit_feather_nrf52840 -p

Compile main.c using zig cc

west build -d build -b adafruit_feather_nrf52840 -p -- -DZIGCC=1

Compile main.zig using Zephyr sdk

west build -d build -b adafruit_feather_nrf52840 -p -- -DZIGMAIN=1

Compile main.zig using zig cc

west build -d build -b adafruit_feather_nrf52840 -p -- -DZIGCC=1 -DZIGMAIN=1

Running

Is done like usual by flashing the image to the board, for example:

west flash -r blackmagicprobe --gdb-serial /dev/ttyACM0 --skip-rebuild --elf-file build/zephyr/zephyr.elf

Details of the journey

Inspired from Lup Yuen Lee’s Article about Building an App with Zig and Apache NuttX RTOS we will try to translate C Code to Zig using zig translate-c. We have to do this in the context of the Zephyr Build process, all compiler flags have to be the same like for invoking the C compiler. Therefore I started with:

Using the `zig cc` C compiler to compile Zephyr

We try to setup a toolchain which uses zig cc as C compiler.

By following the Custom CMake Guide of Zephyr we use this repository as TOOLCHAIN_ROOT with the cmake files under the cmake directory and setting the TOOLCHAIN_VARIANT to zig.

For the generic (host) part of the build we use the zephyr-sdk toolchain. We just direct some files to the correspondig files in ZEPHYR_BASE. Zig specific settings are in cmake/compiler/zig/target.cmake. I just tried it for an arm board so it is written for satisfy this needs.

Remarks

The critical step was the Unfixed size binary Build Step which builds zephyr_pre0.elf. If we use zigs clang it stops at

[149/159] Linking C executable zephyr/zephyr_pre0.elf

and tells

ld.lld: error: cannot find linker script -Map

The C compiler is called for this step.

Then I tried to use the zephyr-sdk-gcc for this step by writing a conditional clause in zigcc, which is the wrapper for zig cc.

If we do this we have no complaining about the arguments but get an

undefined reference to `__aeabi_memclr8'

This could be solved by adding -lc_nano to the compiler ars which links in the nano libc.

To view the invocation of the compiler do:

cd build
ninja -v

Compile main.zig with `zig build-obj` and use zephyr C code directly

I used zig translate-c with the same compiler arguments we found Zephyr was using to compile main.c. From this I extracted the relevant part for main.zig. In this form all macros were already expanded. With some CMake wizardry I managed it to fit the compiled object file into the Zephyr app application (see zig.cmake) Then I was faced with the compiler_barrier() issue, mentioned in the *Preconditions. I was happy to got it to compile, but the expanded macros were not usable from a programmers point of view. Thats way I

Translate the Devicetree to Zig

My aim was to have an easy usable perdant to the devicetree_generated.h header file in Zig. Whereas the header file is an artwork of encoding the devicetree data into C Preprocessor Macros my goal was to code the devicetree data in a clean and simple way which could be human viewable and usable.

Therefore Zig’s reach possibilities to create and initialize struct’s were realy useful. We got a tree which looks nearly like the zepyr.dts:

pub const soc = struct {
  const gpio_50000300 = .{
    ._device = @as([*c]const c.struct_device, &c.__device_dts_ord_10),
    .reg = [_]u32{0x50000300, 0x200, 0x50000800, 0x300},
    .port = @as( u32, 1),
    .gpio_controller = true,
    .ngpios = @as( u32, 16),
    .status = "okay",
    .compatible = [_][]const u8{"nordic,nrf-gpio"},
    .wakeup_source = false,
  };
};
pub const leds = .{
  .compatible = [_][]const u8{"gpio-leds"},
  // 16
  .led_0 = .{
    .gpios = .{.ph=&soc.gpio_50000300,.pin=@as( u32, 15),.flags=@as( u32, 0)},
    .label = "Red LED",
  },
};

In this tree the phandles are real references of their targets. Thus refer to gpios of led_0 is as easy as writing:

dt.leds.led_0.gpios

which is the analog of Zephyrs:

 GPIO_DT_SPEC_GET( DT_PATH( leds, led_0), gpios)

Right now not all properties are translated, but to complete it is not too difficult. (Aliases, Labels, Memory Maps for example)

nodecum/zig-zephyr