Schorschi
Posts: 245
Joined: Thu Nov 22, 2012 9:38 pm

For now, I am not going to use dtoverlay for most of my sensors

Mon Aug 24, 2020 5:19 pm

For now, I am not going to use dtoverlay for most of my sensors. This is a decision that I have come to with significant regret. The number of times I get remote IO errors the dtoverlays is significantly higher than other methods available.

For example, a typical BME280 sensor, with python based query of sensor data, I rarely get any type of i2c communication error, even with using Node Red based query of a BME280 sensor, I once in a while get a remote IO error. But with the same sensor, wiring unchanged, on the same Pi device, the dtovelay method for the BME280 sensor I get remote IO errors at least once every few minutes.

Over a 24 hour test, where only the driver/software query method changes I got the following results. Python based, no errors. Node Red based, using the bme280-sensor module, and node-red-contrib-i2c-bus module, 2 errors. However, the BME280 dtoverlay method, over 100 errors. Nor is this behavior limited to the BME280 sensor. I have tried a number of other sensors which dtoverlay supports, and the number of remote IO errors is still more than other available methods as noted above.

The concept of the dtoverlay model, I do believe in, and it has merit. But from a practical sense, at least for now, for the various sensors I have tested, the consistency is to variable for my needs, use cases. Of course, over time I will continue testing, because long term I would love to avoid the code complexity that dtoverlay based methods avoid.

As a side note, there is one other limitation of the dtoverlay design that I would like to see addressed, this is how i2c address conflicts are handled. Let me clarify, this is not an actual i2c address conflict on the i2c bus, but in the /boot/config.txt configuration options parse the explicit specification of i2c address per dtoverlay configuration. For example, the following sensors can have the same hardwired address, due to various breakout board designs, such that HTU21D at 0x40, and Si702X at 0x40 can conflict.

Now of course, when the sensors are wired to the same i2c bus, say bus 1 on Pi4, this is an issue, but that is the not the case I am referencing, the specific issue is that the dtoverlay configuration can't, per my understanding, resolve which sensor is actually present at address 0x40, be it the HTU21D or Si702X is actually present. If you enter the two dtoverlay lines in the the /boot/config.txt file, 1 for each sensor, only the first address match is honored, regardless which sensor is actually present. Meaning if that if you have 2 lines both explicitly qualifying address 0x40, only the first one is honored, acted upon. The dtoverlay logic should be a bit smarter in matching the right driver to the right device, and not relay on i2c address alone. If there is a way to avoid this issue, please communicate it accordingly.

trejan
Posts: 2949
Joined: Tue Jul 02, 2019 2:28 pm

Re: For now, I am not going to use dtoverlay for most of my sensors

Mon Aug 24, 2020 5:56 pm

Schorschi wrote:
Mon Aug 24, 2020 5:19 pm
For now, I am not going to use dtoverlay for most of my sensors. This is a decision that I have come to with significant regret. The number of times I get remote IO errors the dtoverlays is significantly higher than other methods available.
Your problem is with the driver in the Linux kernel and not device tree which is just configuring it. There shouldn't be any significant difference in reliability between an entirely user space driver and one in the kernel though as they both use the same I2C subsystem and physical controller to communicate.
Schorschi wrote:
Mon Aug 24, 2020 5:19 pm
The dtoverlay logic should be a bit smarter in matching the right driver to the right device, and not relay on i2c address alone. If there is a way to avoid this issue, please communicate it accordingly.
You've asked for this before and it still isn't possible. I2C was never designed for this and there is no standardised way of automatically detecting what kind of I2C device is at a specific address. The firmware isn't going to start doing device specific probes to determine what is at an address before loading the DT overlay for it.

The best you can do is to write your own detection routine that carefully probes the devices and selects from a list of possible sensors. Once it has decided what that device is then it can call out to dtoverlay to manually load the overlay for it. You're just moving the complexity into the detection routine though.

Return to “Automation, sensing and robotics”