Initializing SPI and TWI drivers on Zephyr

RE: Initializing SPI and TWI drivers on Zephyr

kleonhardt — Tue, 23 Jul 2024 06:22:37 GMT

Please note that the peripheral driver examples are using the Zephyr independent drivers, but the examples for a target chip e.g. bmi280 are made with the Zephyr device tree drivers. Don't mix them, you will only be confused.

And by the way, even though the TWI initialization partly is done by Zephyr initialization by a call to nrfx_twim_init, the pin configuration is done later. I imagine that all pin configuration in the devicetree are done centrally during the Zephyr initialization.

RE: Initializing SPI and TWI drivers on Zephyr

trampas — Mon, 22 Jul 2024 10:36:40 GMT

That is also my understanding. The idea with the Zephyr devicetree drivers is that you can port your code to another processor easy. Which I think is kind of crazy in the embedded space, but that is what the Zephyr creators dream of.

The thing that might help is looking at the zephyr driver source code, this help me once I understood that device trees just create a header file. The driver source code should help you understand the zephyr drivers better.

RE: Initializing SPI and TWI drivers on Zephyr

kleonhardt — Mon, 22 Jul 2024 07:30:04 GMT

Thanks, that was helpful in many ways. However, it did not really answer my question.

I made some debugging, and it seems that the Zephyr INIT_LEVEL_POST_KERNEL initialization does not include a call to nrfx_spi_init in the same way as i2c calls nrfx_twim_init. And in my example I "manually" called the nrfx_spi_init/nrfx_twim_init functions for initialization. Worked for SPI but not for I2C obviously. I cannot see why it should be different. But it is of cause wrong both adding the driver to the device tree, an do the initialization in the application code.

Can this be explained? Are my observations wrong?

Further more I found the initializer fro the twim_0_config struct that is used for initializing the twi peripheral, but the scl/sda pins are not defined here.

Are the pin mappings done later in the Zephyr devicetree initialization? I have not been able to find it.

RE: Initializing SPI and TWI drivers on Zephyr

kleonhardt — Mon, 22 Jul 2024 06:47:02 GMT

I just realized that there are two categories of peripheral drivers.

Zephyr devicetree drivers. (Included by e.g. #include <zephyr/drivers/i2c.h>)
Zephyr independent drivers. (Included by e.g #include <nrfx_twim.h>

All the peripheral examples seems to be using "Zephyr independent drivers.", so there is no help here if you want to use the Zephyr Devicetree.

Is this correct?

RE: Initializing SPI and TWI drivers on Zephyr

trampas — Thu, 18 Jul 2024 21:52:37 GMT

First off in Zephyr with device trees is to realize the device trees get "preprocessed" or "compiled" down to a header file in your build/zephyr/include/generated directory called "devicetree_generated.h". That is the device tree mess all gets processed to this one header file, nothing more or less.
The source code for drivers in Zephyr then look at the "devicetree_generated.h" header file to see if they need to create a driver for you or not. For example when you include the I2C in the device tree the nordic I2C driver source file then knows to build driver and before main() the driver is configured and ready to be used.

&i2c1 {
	compatible = "nordic,nrf-twim";
	status = "okay";
	pinctrl-0 = <&i2c1_default>;
	pinctrl-1 = <&i2c1_sleep>;
	pinctrl-names = "default", "sleep";
};

Above the above device tree says to use the "nordic-nrf-twim" driver and use the pins and such defined for I2C1. Then what I do is in my device tree I add the following:

&i2c1 {
	tlv320aic3206: tlv320aic3206@18 {
		compatible="i2c-device";
		label="TLV320AIC3206";
		reg=<0x18>;
	};
	sx1509b: sx1509b@3E {
		compatible="i2c-device";
		label="SX1509B";
		reg=<0x3E>;
	};
	ltc2959: ltc2959@63 {
		compatible="i2c-device";
		label="LTC2959";
		reg=<0x63>;
	};
};

Here this says that I have three chips on the I2C and what the I2C address is for each chip. Each chip will be a generic i2c-device driver, that is not any custom driver per chip, rather I will have to use I2C read/writes to talk to the chips in my code.

Zephyr still creates a driver for each chip, "i2c-device". All device tree drivers are referenced by getting a pointer to the 'device', but since these are "i2c-device" we can use the "i2c_dt_spec" special purpose device type pointers.

static const struct i2c_dt_spec dev_i2c = I2C_DT_SPEC_GET(DT_NODELABEL(tlv320aic3206));
static const struct i2c_dt_spec dev_i2c_sx1509b = I2C_DT_SPEC_GET(DT_NODELABEL(sx1509b));
static const struct i2c_dt_spec dev_i2c_ltc2959 = I2C_DT_SPEC_GET(DT_NODELABEL(ltc2959));

Again the these macros are part of the device tree confusion, and basically a way to go from your device tree label to get a pointer to the actual device driver. Once you have these pointers to the device driver you can use them with I2C driver API.docs.zephyrproject.org/.../i2c.html

i2c_write_read_dt()
i2c_write_dt()
i2c_read_dt()

Getting started the whole device tree system is a big confusing mess, and I found little documentation that helped me. Once I figured out that the device tree compiles to the one header file, it helped a lot. That is the device tree header file is the glue for everything.

Also note that the Zephyr nomenclature is that the "compatible" part of the device tree selects which driver that node in device trees uses. However Nordic's UARTE driver does not use the compatible flag as designed. Keep this in mind if you want to write custom 'out of tree' UARTE drivers as that it is very hard to do so without a lot of work. The Zephyr guys indicate this is a bug in Nordic's driver...