LSM6DSO and LSM6DSO32 compatible

[Rolandash]

Hello,

I am testing LSM6DSO and LSM6DSO32 on Zephyr.

As these 2 sensors are pin compatible, I prepared 2 identical boards, one is mounted with LSM6DSO and LSM6DSO32 on another. (The sensors are connected to MCU through SPI interface.)

My purpose is that I can use one single Zephyr image to drive the IMU sensor no matter which one of these 2 sensors is mounted on board.

It looks promising because one lsm6dso.c driver is provided in Zephyr, and this driver defined DT_DRV_COMPAT for LSM6DSO32. And Zephyr's official document also confirmed this compatible as well.

So I use the default sample/sensor/lsm6dso app for a simple testing.

The sample can be built and run for the board with LSM6DSO. The output from the uart console looks making sense.

But I encountered some problems when configure the dts file for the board with LSM6DSO32.

At first I config the dts file like this:

lsm6dso: lsm6dso@0 {
	compatible = "st,lsm6dso32", "st,lsm6dso";
        ...
}

This can not compile, the compiler complains:

error: redefinition of '__device_dts_ord_133'
   96 | #define DEVICE_NAME_GET(dev_id) _CONCAT(__device_, dev_id)

Then I changed the dts file to like this:

lsm6dso: lsm6dso@0 {
	compatible = "st,lsm6dso32";
        ...
}

and in the sample's main file, I changed the dev_id to:

const struct device *const dev = DEVICE_DT_GET_ONE(st_lsm6dso32);

This can compile and run, but the output result is bit strange, as the output rate of console is very slow compare to previous board with LSM6DSO.

In the end I changed the dts back to:

lsm6dso: lsm6dso@0 {
	compatible = "st,lsm6dso";
        ...
}

and the sample's main file back to:

const struct device *const dev = DEVICE_DT_GET_ONE(st_lsm6dso);

This time the board with LSM6DSO32 can run and the output rate looks the same as the other one, but the readings of accel and gyro looks have quite big differences.

What I am not sure is:

1) why have both compatible listed (compatible ="st,lsm6dso32", "st,lsm6dso") result in compiling error? This method is actually recommended by Zephyr official document.

2) It seems that if compatible = "st,lsm6dso32" is used, the program on LSM6DSO32 board runs abnormally. Am I missing something else?

3) Although set compatible = "st,lsm6dso" can make LSM6DSO32 board works like normal, I am still not sure the results I got are correct for LSM6DSO32. According to my search these 2 sensors actually have different register maps, and their default range of measurements are not same. 

Can you please give some hints?

Thank you in advance.

/Roland

[Federica Bossi · Accepted solution]

Hi @Rolandash ,

Zephyr expects only one compatible string per device node. The error (redefinition of '__device_dts_ord_133') happens because Zephyr’s device tree system tries to create two device instances for the same node, leading to a conflict. Although the Zephyr documentation suggests listing multiple compatibles for fallback, in practice, this can cause issues if both drivers are present or if the driver registration logic doesn’t handle it well. Use only one compatible string per node.

If you use "st,lsm6dso32", Zephyr will use the LSM6DSO driver, but with the LSM6DSO32-specific configuration. If the driver or DTS settings (like default ranges, ODR, etc.) are not properly set for LSM6DSO32, you may see abnormal behavior.

Using "st,lsm6dso" for LSM6DSO32 may work for basic functions but check the difference in the two register maps.