This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Including specific sensor header files

Hi everyone,

I have a board based on thingy91. I have lis2dh and adxl372 sensors on it. They are both connected via SPI, and I've added this to my overlay file:

&spi0 {
	compatible = "nordic,nrf-spim";
	status = "okay";
	sck-pin = <3>;
	mosi-pin = <4>;
	miso-pin = <5>;
	cs-gpios = <&gpio0 8 GPIO_ACTIVE_LOW>, <&gpio0 7 GPIO_ACTIVE_LOW>;

	lis2dh@0 {
		compatible = "st,lis2dh";
		label = "LIS2DH";
		spi-max-frequency = <8000000>;
		reg = <0>;
		irq-gpios = <&gpio0 9 0>;
	};

	adxl372@1 {
		compatible = "adi,adxl372";
		label = "ADXL372";
		spi-max-frequency = <8000000>;
		reg = <1>;
		int1-gpios = <&gpio0 6 0>;
	};
};

Also I've enabled the sensors in the prj.conf. I am able to initialize and get sensor readings, everything works fine there. The issue comes up when I try to include lis2dh.h and adxl372.h in my project. I do this because I want to have access to the SPI bus, and I want to be able to send custom values to the device registers(I wasn't able to find this as an option through the sensor api provided by Zephyr). I've added adxl372 and lis2dh to my list of include directories in top level CMakeLists.txt, and I am able now to include them in my source code. However when compiling, I get the following error:

error: 'const union lis2dh_bus_cfg' has no member named 'spi_cfg'
  122 |     const struct spi_config *spi_cfg = &cfg->bus_cfg.spi_cfg->spi_conf;
 

That's weird, because it is defined to use spi, and the devices do work. So I suspect that the macro DT_ANY_INST_ON_BUS_STATUS_OKAY(spi) is not working well because these files are included in a weird way(directly from my top level cmakelists.txt, instead of the usual way). 

How can I include these files in my source code and use them properly?

Cheers,

Aleksa

  • Aleksa said:
    I've changed to the spi3,

     Could you use and upload that file instead? The one you are using now is still using spi0

  • Actually I've posted the wrong output, but I use spi3 now and the issue is still the same.

  • So far I'm not able to reproduce this.

    Testing with asset_tracker_v2. I modified thingy91_nrf9160ns.overlay so it looks like this:

    /*
     * Copyright (c) 2021 Nordic Semiconductor ASA
     *
     * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
     */
    
    / {
            aliases {
                    temp-sensor = &bme680;
                    humidity-sensor = &bme680;
                    accelerometer = &adxl362;
            };
    };
    
    &i2c2 {
            bme680: bme680@76 {};
    };
    
    &spi3 {
            adxl362: adxl362@0 {};
            
            lis2dh@2 {
                    compatible = "st,lis2dh";
                    label = "LIS2DH";
                    spi-max-frequency = <8000000>;
                    reg = <0>;
                    irq-gpios = <&gpio0 9 0>;
            };
    };
    
    
    

    I added this to CMakeLists.txt :
    zephyr_include_directories(${ZEPHYR_BASE}/drivers/sensor/lis2dh)

    and added

    #include <lis2dh.h>
    to main.c, it compiled without any warnings or errors.
  • I have tried to make my own driver(because I feel that the sensor API is way too limited for these two sensors). I don't want to edit the zephyr unless I really have to(makes it harder to update ncs versions if I just edit it whenever I don't like how it works). For example in the adxl372.c there is a adxl372_bus_access() function, that extracts some configuration and in the end calls:

    return spi_transceive(adxl372_data->bus, &adxl372_data->spi_cfg, &tx, &rx);
    

    When I try to make the same function in my own code, it says spi_cfg is not a part of the struct adxl372_data. But it definitely has to be a part of it, since I've set CONFIG_ADXL372_SPI=y.  Same happens with the lis2dh, where it doesn't allow access to the spi part of the configuration.

    PS: Before I've tried accessing these fields that depend on whether or not the sensor is used via spi, my code did build too. Could you please try accessing them too?

  • I'm not able to reproduce this.

    Could you upload a small sample that reproduces this? (If you have done changes to Zephyr, add those files as well.)

Related