Practical Zephyr - Devicetree semantics (Part 4) | Interrupt

Blog
1

Having covered the Devicetree basics in the previous article, we now add semantics to our Devicetree using so-called bindings: For each supported type, we’ll create a corresponding binding and look at the generated output to understand how it can be used with Zephyr’s Devicetree API.

This is a companion discussion topic for the original entry at https://interrupt.memfault.com/blog/practical_zephyr_dt_semantics
2

Thanks for the article series, I’ve been finding it useful getting up to speed with Zephyr. Following this article, I did get a bit stuck in the naming section of the blog post, the grep for ‘foo’ in devicetre_generated.h at the end of the section didn’t produce any results for me.

I should be using the same version of Zephyr (2.4.0) at the end of the section. Doing a before and after comparison of the devicetre_generated.h files the only change I could see was the compatible name, and couldn’t see the property values added. Any suggestions on what I might be doing wrong, or how to debug this?

Also, there were a few parts of this section I was a bit unsure about

  • The instructions in the naming section start off specifying using the name custom as the vendor name, but mid-way through it seems like these instructions describe the files having used the vendor name dummy which doesn’t seem to have been mentioned before.
  • I wasn’t completely sure about what it means to have the generator script update devicetree_generated without compiling (e.g. “Without recompiling, we can check whether the generator script has added our properties to devicetree_generated.h”). I was running the following as done in previous examples:
west build --board nrf52840dk_nrf52840 --build-dir ../build -- \
  -DEXTRA_DTC_OVERLAY_FILE="dts/playground/props-basics.overlay"

If it’s possible to clear any of this up for me that would be great, but either way thanks for creating this blog series :slight_smile: