Hello, in 2021 I developed a Zephyr 2.6.0 based app which interfaces with STMicro's IIS2DH accelerometer. During development stages I was able to talk more directly to this sensor through Zephyr's I2C API, by passing the following member of a valid IIS2DH device pointer: device->data->bus. This reflects STMicro's Zephyr driver code, as found in `zephyr/drivers/sensor/iis2dh/iis2dh.h`, both in Zephyr 2.6.0 and more recently released Zephyr 3.1.0. New features and bug fixes as of 2022 compel my team to move forward to use Zephyr 3.2.0, where I have recently encountered non-trivial rewrite of the IIS2DH sensor data structures in `zephyr/drivers/sensor/iis2dh/iis2dh.h`. I've adjusted my app side code accordingly, but have run into a subtle issue where, as soon as I make a reference to compile iis2dh.h and related sources, the test h t t p s ://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/sensor/iis2dh/iis2dh.h#L49 returns false, and my device pointer thus lacks an i2c data member. The same DT_ macro tests true in my app source file, for interfacing with the IIS2DH.
These differing macro evaluation results occur at build time. I've even added pre-processor messages to in-tree header file `iis2dh.h`, and can see when `#if DT_ANY_INST_ON_BUS_STATUS_OKAY(i2c)` fails there, as well as whether it passes or fails in test code in my own app sources.
I'd actually like to use Zephyr's sensor API correctly, but whether I do so or continue to interface in custom manner with more direct calls to Zephyr I2C read and write routines, I am very certain I need to resolve this build time issue in STMicro's provided sensor library. I've posted a minimal Zephyr application on my github account, publicly, which one can build to reproduce this behavior. The repo URL is github.com/tedhavelka/iis2dh-minimal.
One thing I suspect may be happening is that somehow some sources, like iis2dh.h and kin, are getting pre-processed before Zephyr toolchain has completed all device tree source parsing. I know I've called out I2C devices in DTS overlays correctly: they compile and I see sensor data when building against Zephyr 2.6.0 and 3.1.0. So my hardware is correctly wired, and the my project device tree source has not changed, nor needed to change, in the move to Zephyr 3.2.0. But STMicro IIS2DH in-tree driver source has changed. The macro check `DT_ANY_INST_ON_BUS_STATUS_OKAY(i2c)` is new in Zephyr 3.2.0, and appears to be failing early during build at a time it should be passing.
Any help on this subtle issue I appreciate! I can provide further info if that's needed and helpful. Thank you,
- Ted
