On 10/21/2015 10:54 AM, Paul "LeoNerd" Evans wrote:
I've been writing a bunch of modules to talk to specific kinds of
hardware chips (sensors, motor controllers, radio interfaces, etc...)
that are electrically SPI or I²C. There's likely hundreds or
thousands of possibles here.
Cur
As someone who uses perl in a public transit agency I see I should rush out and
grab Bus:: ASAP :)
--
Aaron Priven, aa...@priven.com
> On Oct 22, 2015, at 4:45 AM, Aldo Calpini wrote:
>
> Bus, by itself, is far from unambiguous to me
> (https://en.wikipedia.org/wiki/Bus).
On Thu, 22 Oct 2015 13:45:18 +0200
Aldo Calpini wrote:
> I would personally keep Device, most of the hardware-related stuff on
> CPAN (not much, but still) is already in that namespace.
Agree.
> Bus, by itself, is far from unambiguous to me
> (https://en.wikipedia.org/wiki/Bus). On the other
On 22/10/15 12:39, Matthew Astley wrote:
Cool! The Bus::I2C:: namespace seems safe. Short, unambiguous,
unlikely to have a legitimate claim from software.
I would personally keep Device, most of the hardware-related stuff on
CPAN (not much, but still) is already in that namespace.
Bus, by it
On Thu, 22 Oct 2015 11:39:00 +0100
Matthew Astley wrote:
> The Bus::I2C:: namespace seems safe. Short, unambiguous, unlikely to
> have a legitimate claim from software.
>
> Under that you could put chip names like Bus::I2C::DS1307 [1] but I
> suspect software will fit better by function like Bu
On Wed, Oct 21, 2015 at 06:54:38PM +0100, Paul LeoNerd Evans wrote:
> [...] Currently, they all live under the namespace
> Device::BusPirate::Chip::*
> [...] I'm considering how to name device drivers for talking to
> these hardware chips in a way that's independent of how that chip is
> ulti
[[Background
~~
I've been writing a bunch of modules to talk to specific kinds of
hardware chips (sensors, motor controllers, radio interfaces, etc...)
that are electrically SPI or I²C. There's likely hundreds or
thousands of possibles here.
Currently, they all live under the