This queue is for tickets about the Device-Chip-INA219 CPAN distribution.

Report information
The Basics

Nobody in particular
john [...]

(no value)
Broken in:
(no value)
Fixed in:
(no value)

Date: Sun, 4 Nov 2018 17:27:12 -0600
From: john <>


I am using Device::Chip::INA219 with Device::Chip::Adapter::LinuxKernel.   With D::C::INA219 unmodified I get this error with this code:

use strict;
use warnings;
use Device::Chip::INA219;
use Device::Chip::Adapter;
my $ADAPTER = "LinuxKernel";
my $MOUNTPARAMS = 'bus=/dev/i2c-1,addr=0x40';
my $ina = Device::Chip::INA219->new;
   Device::Chip::Adapter->new_from_description( $ADAPTER ),

my $vbus = $ina->read_bus_voltage->get / 1000;
print "vbus: $vbus\n";

I get this error from the mount_from_paramstr call:

Missing required parameter 'bus' at /usr/share/perl5/site_perl/Device/ line 128.

If I change D::C::INA219 "sub I2C_options" to include passing of the %params then things work OK:

sub I2C_options
    my $self = shift;
    my %params = @_;

    my $addr = delete $params{addr} // 0x40;
    $addr = oct $addr if $addr =~ m/^0/;

    return (
        %params,    # pass the parameters along
        addr        => $addr,
        max_bitrate => 100E3,

Is this a required change to D::C::INA219 or am I missing something?
Initial assessment appears that this is a bit of an API mismatch between the Device::Chip API overall, and the way that Device::Chip::Adapter::LinuxKernel was designed - that adapter happens to be one of the only ones *not* written by me ;) Whereas I've written most of the chip drivers themselves. My thinking is that perhaps the `bus` parameter ought to be given as a constructor argument to the LinuxKernel adapter instead, thus creating an adapter bound to a particular bus. That said, it's specific to the I²C part, and would be different for SPI or GPIO or whatever else, so at this point I'm a little unsure. Maybe instead the Device-Chip-Adapter-LinuxKernel distribution should actually provide different adapters per *actual* device - GPIO being quite different from SPI or I²C here. Either way, I don't think this is just a case that you're using it wrong; rather it's a larger API design decision question that needs to be looked at across the D:C ecosystem generally, to see what the right answer might be. Thanks for bringing it to our attention, and I hope to have a satisfactory answer for you soon :) -- Paul Evans

This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with to