Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with nested structs in BME680-Driver / I²C-init #609

Open
2 of 7 tasks
rk-sTEk opened this issue Feb 11, 2024 · 0 comments
Open
2 of 7 tasks

Problem with nested structs in BME680-Driver / I²C-init #609

rk-sTEk opened this issue Feb 11, 2024 · 0 comments

Comments

@rk-sTEk
Copy link

rk-sTEk commented Feb 11, 2024

The issue

I try to use the BME680-driver on an ESP32C6 with VSC on Linux with newest ESP-IDF (v5.1.2).
Unfortunately the controller went in an error by init the sensor. After a debug session I realized, that there is a wrong variable initialization.

the definitions in bme680.h:

/**
 * BME680 sensor device data structure type
 */
typedef struct
{
    i2c_dev_t i2c_dev;              //!< I2C device descriptor

    bool meas_started;              //!< Indicates whether measurement started
    uint8_t meas_status;            //!< Last sensor status (for internal use only)

    bme680_settings_t settings;     //!< Sensor settings
    bme680_calib_data_t calib_data; //!< Calibration data of the sensor
} bme680_t;


//Test-Dev without the first struct
typedef struct
{
 
    bool meas_started;              //!< Indicates whether measurement started
    uint8_t meas_status;            //!< Last sensor status (for internal use only)

    bme680_settings_t settings;     //!< Sensor settings
    bme680_calib_data_t calib_data; //!< Calibration data of the sensor
} bme680t1;

typedef struct
{
   i2c_dev_t i2c_dev0;              //!< I2C device descriptor
} bme680_t_1;

the definitions in i2cdev.h:

/**
 * I2C device descriptor
 */
typedef struct
{
    i2c_port_t port;         //!< I2C port number
    i2c_config_t cfg;        //!< I2C driver configuration
    uint8_t addr;            //!< Unshifted address
    SemaphoreHandle_t mutex; //!< Device mutex
    uint32_t timeout_ticks;  /*!< HW I2C bus timeout (stretch time), in ticks. 80MHz APB clock
                                  ticks for ESP-IDF, CPU ticks for ESP8266.
                                  When this value is 0, I2CDEV_MAX_STRETCH_TIME will be used */
} i2c_dev_t;

typedef struct
{
    i2c_port_t port;         //!< I2C port number
    i2c_config_t cfg;        //!< I2C driver configuration
    uint8_t addr;            //!< Unshifted address
    SemaphoreHandle_t mutex; //!< Device mutex
    uint32_t timeout_ticks;  /*!< HW I2C bus timeout (stretch time), in ticks. 80MHz APB clock
                                  ticks for ESP-IDF, CPU ticks for ESP8266.
                                  When this value is 0, I2CDEV_MAX_STRETCH_TIME will be used */
} i2c_dev_t_stek;

the declarations:

    bme680_t sensor;
    bme680t1 sensor2;
    bme680_t_1 sensor1;

    i2c_dev_t i2c_dev;
    i2c_dev_t_stek i2c_dev1;

The variables (breakpoint after the declarations) are shown in the picture.

What you see: The nested structs are absolutely wrong - and I don't know how and why. The compiler(?) uses the wrong struct definitions. And...after a nested struct the the definition in the typedef stops.

What is going wrong here?
Bildschirmfoto_2024-02-11_21-08-27

Which SDK are you using?

esp-idf

Which version of SDK are you using?

v5.1.2

Which build target have you used?

  • esp32
  • esp32s2
  • esp32s3
  • esp32c2
  • esp8266
  • other

Component causing the issue

BME680, I2CDEV

Anything in the logs that might be useful for us?

No response

Additional information or context

No response

Confirmation

  • This report is not a question nor a request for drivers.
@rk-sTEk rk-sTEk changed the title Problem with nested structs in BME680-Driver Problem with nested structs in BME680-Driver / I²C-init Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant