I am using an ESP32-S3 with the new Arduino Core v3.0 (esp32-hal-i2c-ng), running the library inside a pinned FreeRTOS task.
Because FreeRTOS is highly optimized, the delay(20) occasionally finishes before the sensor's 20.44ms conversion is complete. The sensor then NACKs the requestFrom. The library ignores the NACK, and calls Wire.read() on an empty buffer, which fatally crashes the new ESP32 v3.0 I2C state machine.
Could we add safety checks to read() to ensure Wire.requestFrom() actually returns bytes before executing Wire.read()? Additionally, exposing the Oversampling Ratio (OSR) as a configurable parameter would allow FreeRTOS users to lower the conversion time and avoid the RTOS scheduling collision entirely. In my case, I was able to get it working again changing it to 2048 oversample rate in the source, which is plenty for me.
I am using an ESP32-S3 with the new Arduino Core v3.0 (esp32-hal-i2c-ng), running the library inside a pinned FreeRTOS task.
Because FreeRTOS is highly optimized, the delay(20) occasionally finishes before the sensor's 20.44ms conversion is complete. The sensor then NACKs the requestFrom. The library ignores the NACK, and calls Wire.read() on an empty buffer, which fatally crashes the new ESP32 v3.0 I2C state machine.
Could we add safety checks to read() to ensure Wire.requestFrom() actually returns bytes before executing Wire.read()? Additionally, exposing the Oversampling Ratio (OSR) as a configurable parameter would allow FreeRTOS users to lower the conversion time and avoid the RTOS scheduling collision entirely. In my case, I was able to get it working again changing it to 2048 oversample rate in the source, which is plenty for me.