Bug #108508 for Device-BusPirate: PIRATE_DEBUG environment variable required

Fri Nov 06 04:06:37 2015 david [...] tulloh.id.au - Ticket created

Subject:	PIRATE_DEBUG environment variable required
Date:	Fri, 6 Nov 2015 20:06:07 +1100
To:	bug-Device-BusPirate [...] rt.cpan.org
From:	David Tulloh <david [...] tulloh.id.au>

Hi, If the environment variable PIRATE_DEBUG is not defined then a bunch of warnings about it being undefined are thrown, particularly by the I2C mode module. This is a minor issue, defining the environment variable is an effective workaround for the problem. Thanks for the library. David

Sat Nov 07 14:06:02 2015 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Fri Nov 06 04:06:37 2015, david@tulloh.id.au wrote: Show quoted text

> If the environment variable PIRATE_DEBUG is not defined then a bunch of > warnings about it being undefined are thrown, particularly by the I2C mode > module.

Oops; yeah. Tiny fix - see attached. Show quoted text

> This is a minor issue, defining the environment variable is an effective > workaround for the problem. > > Thanks for the library.

I'm surprised anyone's using it, really. ;) I've lately found the Bus Pirate to be a rather flaky and unreliable thing, at least in binary IO mode. It's reasonable enough from the point of view of playing with it in human-interface text mode, but it's prone to lots of failures on binary IO. I've been using the FTDI FT232H chip instead lately. -- Paul Evans

Subject:

rt108508.patch

=== modified file 'lib/Device/BusPirate/Mode/I2C.pm' --- lib/Device/BusPirate/Mode/I2C.pm 2015-04-04 17:35:59 +0000 +++ lib/Device/BusPirate/Mode/I2C.pm 2015-11-07 19:04:11 +0000 @@ -17,7 +17,7 @@ use constant MODE => "I2C"; -use constant PIRATE_DEBUG => $ENV{PIRATE_DEBUG}; +use constant PIRATE_DEBUG => $ENV{PIRATE_DEBUG} // 0; =head1 NAME

Sat Nov 07 14:06:02 2015 The RT System itself - Status changed from 'new' to 'open'

Sat Nov 07 14:06:15 2015 leonerd-cpan [...] leonerd.org.uk - Status changed from 'open' to 'patched'

Sat Nov 07 14:06:15 2015 leonerd-cpan [...] leonerd.org.uk - Broken in 0.08 added

Mon Nov 09 20:20:26 2015 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Sat Nov 07 14:06:02 2015, PEVANS wrote: Show quoted text

> I'm surprised anyone's using it, really. ;) I've lately found the Bus > Pirate to be a rather flaky and unreliable thing, at least in binary > IO mode. It's reasonable enough from the point of view of playing with > it in human-interface text mode, but it's prone to lots of failures on > binary IO. > > I've been using the FTDI FT232H chip instead lately.

Furthermore, you may wish to see my recent (in the past few minutes - so some of these links may not be indexed yet ;) ) uploads to CPAN: https://metacpan.org/release/Device-Chip and specifically https://metacpan.org/pod/Device::Chip::Adapter::BusPirate https://metacpan.org/pod/Device::Chip::Adapter::FTDI These between them provide a standard interface for talking to chips. Right now (as it's version 0.01 and only today's work) it only talks SPI but I'm hoping by the end of the week to have I²C and possibly some attempt at raw GPIO bitbanging done too. I'll be migrating my existing Device::BusPirate::Chip::* modules to this new style, having started today with https://metacpan.org/pod/Device::Chip::MAX7219 If you're writing any chip-specific code using the Bus Pirate currently, I'd suggest that if you target the Device::Chip interface instead, then it'll be looking a lot better for forward compatibility with other kinds of adapter. Hope that helps, -- Paul Evans

Tue Nov 10 14:26:57 2015 leonerd-cpan [...] leonerd.org.uk - Correspondence added

Released in 0.09 -- Paul Evans

Tue Nov 10 14:26:58 2015 leonerd-cpan [...] leonerd.org.uk - Status changed from 'patched' to 'resolved'

Tue Nov 10 14:26:58 2015 leonerd-cpan [...] leonerd.org.uk - Fixed in 0.09 added