1

I recently inherited some firmware with weird problems in regards to the duration of reading sensor values. The board is based on the ESP32 Wrover MCU and has multiple sensors connected via the I2C bus. The firmware makes use of the port of the FreeRTOS task library and uses the main loop to read two sensors as well as an extra task on the same core to read some more sensor via a DS2482 I2C to OneWire bridge. Usually I would expect the reading of the sensors to take at most one second (assuming the 'worst' case under normal conditions) via the bridge, but it takes a multitude of that, usually around 30 or more seconds for one sensor. Not only the reading but any communication over the bridge takes a very long time. One more detail: The sensors behind the bridge are connected one per channel of the bridge and the one wire channel is reset each time before a sensor is read.

My current suspicion is that using multiple tasks on the same I2C bus may screw up the timings of the communication and thus cause communication errors leading to the increased read times.

Does that suspicion sound reasonable at all or what would you suggest to investigate on the described system (knowing well, that I didn't provide too many details)?

Any ideas are welcome.

Thanks!

|improve this question
  • 2
    I've run into ports of FreeRTOS where using the I2C hardware is wrapped at quite a high level in an atomic block so it will block scheduling from occurring as you expect. That could be worth checking but it'd probably be a more widely reported issue if it was what's happening here. I'd look at how long form reset to data being ready it is for the one-wire sensors and maybe even write a test program that doesn't use an RTOS to see how often you can get data from things beyond the bridge in the way you're doing it now. (i.e. reset the sensor and then get data) – hooskworks Oct 24 '19 at 8:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.