Can an overlay be created for the INA260 (current & voltage sensor)

[seamusdemora]

Describe the bug

Not a bug, but a request to add support for the INA260.

Steps to reproduce the behaviour

N/A

Device (s)

Raspberry Pi 4 Mod. B

System

N/A

Logs

N/A

Additional context

Adafruit has an Arduino library for this device, but that doesn't help on the RPi.

[JamesH65]

Is there a Linux kernel driver already available? Is it just matter of enabling it?

[6by9]

There appears to be a driver that has been submitted to the IIO mailing list once at https://patchwork.kernel.org/project/linux-iio/patch/20210322105056.30571-2-raviteja.narayanam@xilinx.com/ https://patchwork.kernel.org/project/linux-iio/patch/20210322105056.30571-3-raviteja.narayanam@xilinx.com/

It looks like they dithered over whether it got integrated into adc-ina2xx or not, and it died a death.

Adding downstream drivers adds a maintenance burden which is annoying, but potentially those could be imported with an overlay to make it work. Should the driver ever get merged upstream, the overlay may need to be updated.

[seamusdemora]

@JamesH65 @6by9 ,

Is there anything I could and should do to help move this forward? I have no experience with this sort of thing, but willing to try most anything :)

[JamesH65]

I doubt we will be doing anything on this as we are extremely busy on more vital issues, so it would have to come from an external source such as yourself.

[seamusdemora]

@JamesH65

Fair enough, and I understand. If I had a clue on how to go about this, I'd give it a go. I requested it because similar requests have been granted, and the INA260 is quite a useful device.

[JamesH65]

We only add support if that support is already in the Linux kernel and it just needs enabling in our particular build of the kernel. In this case, it appears that support is NOT there so it would require considerably more effort, i.e. writing code, testing and then ongoing support.

IIRC its fairly easy to use this device from Python without having kernel support so that might be worth looking in to.

[seamusdemora]

You may be correct. I don't use Python, but I'm using an Adafruit INA260 lib developed for Arduino in a Pico project, but I'd prefer to use it on the RPi. And there must be advantages to kernel support... otherwise there wouldn't be so many overlays that support various devices. I understand that there needs to be sufficient interest or a business case for resourcing this... I thought (hoped) that a few more users would jump in and ask about INA260 support. :) Maybe that'll happen yet?

[Jibun-no-Kage]

Just a side question, are their any other comparable sensors already supported? I just so happen to have a project where I need to use this type, or class, of sensor, but I have not yet purchased such.

@seamusdemora, Interesting you note Pico, do you happen to be using a code (compiled image?) or may be MicroPython? Sorry if I butting in, but just curious.

[6by9]

Follow the instructions to build the kernel at https://www.raspberrypi.com/documentation/computers/linux_kernel.html. I'd recommend omitting the --depth=1 option from the git clone as you'll potentially be needing to do more work with the tree.

I've linked to the mainline patches. Download those patches (hit the "series button"), and you can then use git am <file> to apply those patches. Hopefully they'll apply cleanly, but no guarantees. There are lots of guides on how to resolve conflicts with git.

Use make menuconfig or similar to allow you to enable the module (config option INA260_ADC).

Writing the overlay has some intricacies if writing a generic overlay, but I think you can add it as a fragment to https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/overlays/i2c-sensor-common.dtsi. It'll be almost identical to the others, but probably read

    fragment@N {
        target = <&i2cbus>;
        __dormant__ {
            #address-cells = <1>;
            #size-cells = <0>;
            status = "okay";

            ina260: ina260@40 {
                compatible = "ti,ina260";
                reg = <0x40>;
                #io-channel-cells = <1>;
            };
        };
    };

And will need an override to enable that fragment. As it appears to have a configurable I2C address, it would be nice to have an override to set that too, copying lm75addr.

Rebuild the kernel, push to your Pi, and add dtoverlay=i2c-sensor,ina260 to /boot/config.txt. Reboot, and hopefully your driver will load and you'll get the device exposed to userspace (I don't know how IIO does that).

Use git commit to create a patch for your overlay. For a Pull Request you'll also need to update the README in that same patch.

[seamusdemora]

@Jibun-no-Kage ,

Just a side question, are their any other comparable sensors already supported? I just so happen to have a project where I need to use this type, or class, of sensor, but I have not yet purchased such.

See 6x9's earlier post:

There appears to be a driver that has been submitted to the IIO mailing list once at https://patchwork.kernel.org/project/linux-iio/patch/20210322105056.30571-2-raviteja.narayanam@xilinx.com/ https://patchwork.kernel.org/project/linux-iio/patch/20210322105056.30571-3-raviteja.narayanam@xilinx.com/

@seamusdemora, Interesting you note Pico, do you happen to be using a code (compiled image?) or may be MicroPython? Sorry if I butting in, but just curious.

No apologies necessary; I appreciate your show of support for inclusion of the INA260 :). WRT your question: No, I'm using Adafruit's INA260 Arduino library. Arduino now supports Pico development, so it's easy enough to code a "sketch" using this library.

WRT INA260 vs INA2XX (ref 6x9's earlier post): I did a quick comparison of the two chips last night & made some notes. I can't get to those notes now, but for my use cases, there are a few diffs between the chips that make the INA260 a much better choice. One is the INA260's alarm register supports a current threshold, whereas the INA2XX supports only voltage. If you're interested, I'll post a note here when I've finished.

[seamusdemora]

@6by9 :

Thanks for the outline! I'll take a look at this & keep you posted :)

[6by9]

WRT INA260 vs INA2XX (ref 6x9's earlier post): I did a quick comparison of the two chips last night & made some notes. I can't get to those notes now, but for my use cases, there are a few diffs between the chips that make the INA260 a much better choice. One is the INA260's alarm register supports a current threshold, whereas the INA2XX supports only voltage. If you're interested, I'll post a note here when I've finished.

Note that the alert register really wants the ALERT pin connected to a GPIO to trigger an interrupt, however neither INA260 nor INA2XX implement such. A quick look suggests that neither driver supports setting or monitoring the thresholds either.

[Jibun-no-Kage]

After a bit of reading, I came to the same decision just use the INA260 and move on. I have custom built sprinkler system, based on a 8 relay board that has an integrated ESP8266, works great, easy setup with Node Red and Tasmota firmware. But I can't determine when a given valve is not responding, has failed. So figured I can insert INA260 into the common GND since all the sprinklers use a common GND. True, I only know if a given valve completed the circuit but I only allow a single value to be open at any one time. Thought of using multiple sensors, one per valve on the power lead side, but seemed over kill for my need.

I happen to have a Pi near the ESP8266 relay board, that is controlling other things. So easy to add the INA260.

[seamusdemora]

@Jibun-no-Kage

After a bit of reading, I came to the same decision just use the INA260 and move on. I have custom built sprinkler system, based on a 8 relay board that has an integrated ESP8266, works great, easy setup with Node Red and Tasmota firmware. But I can't determine when a given valve is not responding, has failed. So figured I can insert INA260 into the common GND since all the sprinklers use a common GND. True, I only know if a given valve completed the circuit but I only allow a single value to be open at any one time. Thought of using multiple sensors, one per valve on the power lead side, but seemed over kill for my need.

I happen to have a Pi near the ESP8266 relay board, that is controlling other things. So easy to add the INA260.

Yes - I think ESP8266 is also supported by Arduino, so you may find the Adafruit INA260 library useful. But the INA260 can only affirm you have current flow - not necessarily water flow. If the valve is stuck or the solenoid's armature doesn't move as it should, current will flow through the solenoid's coil - but water will not flow through the valve. A flowmeter might be a slightly more reliable indicator??

[Jibun-no-Kage]

Right, I am just looking for the current flow in this use case. The water flow I can monitor elsewhere, such as the main feed to all of the values. Given I use mechanical relays, the INA260 will tell me if the relay has frozen in an open or closed state as well, such as current flow long after the time duration for the value/zone, or no current during the time duration for the value/zone. Since I live in the desert, if I have a relay fail to work, I might have a horrible water bill, or dead plants. Neither is great. :)

[seamusdemora]

@Jibun-no-Kage ,

OK - I understand your use case now - very good. Again, if you're using Arduino & Pico (or any of the many other boards they support), you should find the INA260 lib easy to use. Feel free to ping me if I can help.

[Jibun-no-Kage]

Yes, if I did not have a Pi nearby to leverage. I most likely would be using a Pico.