FAQ
[[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 namespace

     Device::BusPirate::Chip::*

   because they're written to talk to the hardware device via a
   particular piece of USB-attached hardware, called a Bus Pirate.

   However, there's nothing specific about the operation of these SPI or
   I²C devices, that relates to the Bus Pirate. In particular, there are
   other computer <-> SPI or I²C adapters available, such as the GPIO
   port built into a Raspberry Pi, or the FTDI FT232H 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
ultimately connected to the computer, and provide an abstracted API
that the driver can use to communicate with the chip, regardless of
this mechanism.

Ultimately, it'd be cool to end up with lots of hardware chip drivers
on CPAN that can talk to all kinds of hardware, via whatever mechanism
people use to physically attach it.

But lets start with the name...

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk
http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS

Search Discussions

  • Matthew Astley at Oct 22, 2015 at 10:39 am

    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
    ultimately connected to the computer, and provide an abstracted API
    that the driver can use to communicate with the chip, regardless of
    this mechanism.
    Cool!

    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 Bus::I2C::EEPROM [2]
    since families of chips will naturally share code.


    The CPAN search for just I2C shows a few things,

       https://metacpan.org/release/i2c (i2c_{ser,lpt})
       https://metacpan.org/pod/HiPi (various under HiPi::*)
       https://metacpan.org/pod/Device::LPS331AP
       https://metacpan.org/pod/Device::Gyroscope::L3GD20
       https://metacpan.org/pod/Device::SMBus
       https://metacpan.org/pod/Device::WebIO::Device::I2CUser

    so it's probably too late to converge on one perfect naming scheme
    anyway.

    Ultimately, it'd be cool to end up with lots of hardware chip
    drivers on CPAN that can talk to all kinds of hardware, via whatever
    mechanism people use to physically attach it.

    But lets start with the name...
    I don't see a way to avoid the usual problem with someone releasing
    Bus::I2C::EEPROM::Lite and Bus::I2C::EEPROM::Tiny after the first come
    module gets bloated out with obsolete parts.

    --
    Matthew

    [1] http://www.rapidonline.com/Electronic-Components/Maxim-DS1307-Timekeeper-with-BCD-Real-Time-Clock-82-0567

    [2] http://www.rapidonline.com/Electronic-Components/ST-M24C64-WMN6P-EEPROM-64k-SO-8-73-3636
         http://www.rapidonline.com/EEPROMs


    --
      The Wellcome Trust Sanger Institute is operated by Genome Research
      Limited, a charity registered in England with number 1021457 and a
      company registered in England with number 2742969, whose registered
      office is 215 Euston Road, London, NW1 2BE.
  • Paul \"LeoNerd\" Evans at Oct 22, 2015 at 11:43 am

    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 Bus::I2C::EEPROM [2]
    since families of chips will naturally share code.
    Hmm. I'm not sure I like "Bus" - the driver talks to just one device,
    one chip. If it sits on a bus like I2C that's a different concern.

    I wonder if simply

       Device::Chip::*
    Well there's at least some precedent for putting it under Device::, so
    that's a start :)
    I don't see a way to avoid the usual problem with someone releasing
    Bus::I2C::EEPROM::Lite and Bus::I2C::EEPROM::Tiny after the first come
    module gets bloated out with obsolete parts.
    Eh... That's a standard problem across the whole of CPAN. We usually
    cope fairly well... :)

    --
    Paul "LeoNerd" Evans

    leonerd@leonerd.org.uk
    http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS
  • Aldo Calpini at Oct 22, 2015 at 11:45 am

    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 itself, is far from unambiguous to me
    (https://en.wikipedia.org/wiki/Bus). On the other hand, I think I2C and
    SPI are familiar enough to people working - or playing - with electronics.

    So I would go for:

    Device::I2C
    Device::SPI

    Which are hardware-abstract, and subclassed if/when needed
    (Device::I2C::FT232H, etc.).

    Just my personal opinion.


    cheers,
    Aldo
  • Paul \"LeoNerd\" Evans at Oct 22, 2015 at 5:16 pm

    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 hand, I think I2C
    and SPI are familiar enough to people working - or playing - with
    electronics. Ditto.
    So I would go for:

    Device::I2C
    Device::SPI

    Which are hardware-abstract, and subclassed if/when needed
    (Device::I2C::FT232H, etc.).
    Hmm. I'm not sure I like putting "SPI" or "I²C" or whatever (UART?
    1Wire?) in the module name. There are genuinely some chips that are
    available with a variety of interface types, or some even support a
    selection of them by different hardware configurations or whatever. So
    I think that the interface type should be an implementation detail, and
    not really part of the name.

    What do you think to simply

       Device::Chip::*

    as the namespace for individual chips. E.g

       Device::Chip::INA219
       Device::Chip::MAX7221

    I'm not sure if driver adapters (Bus Pirate, FT232H, Raspberry Pi
    GPIO, etc...) would necessarily warrant a dedicated space too; they
    become the consumers of these chips, much like my existing
    Device::BusPirate currently consumes chips within its space.

    --
    Paul "LeoNerd" Evans

    leonerd@leonerd.org.uk
    http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS
  • Aaron Priven at Oct 22, 2015 at 7:53 pm
    As someone who uses perl in a public transit agency I see I should rush out and grab Bus:: ASAP :)

    --
    Aaron Priven, aaron@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).
  • David Christensen at Oct 23, 2015 at 1:20 am

    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.

    Currently, they all live under the namespace

    Device::BusPirate::Chip::*

    because they're written to talk to the hardware device via a
    particular piece of USB-attached hardware, called a Bus Pirate.

    However, there's nothing specific about the operation of these SPI or
    I²C devices, that relates to the Bus Pirate. In particular, there are
    other computer <-> SPI or I²C adapters available, such as the GPIO
    port built into a Raspberry Pi, or the FTDI FT232H 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
    ultimately connected to the computer, and provide an abstracted API
    that the driver can use to communicate with the chip, regardless of
    this mechanism.

    Ultimately, it'd be cool to end up with lots of hardware chip drivers
    on CPAN that can talk to all kinds of hardware, via whatever mechanism
    people use to physically attach it.

    But lets start with the name...
    The OSI model immediately comes to mind:

          https://en.wikipedia.org/wiki/OSI_model


    But your idea is even larger in scope -- analogous to an OS architecture
    for device drivers and various subsystem stacks (e.g. multiple OSI
    pyramids). Designing such from scratch properly would be a huge
    undertaking, involving many experts. It may be best to simply copy a
    "good architecture" that is "close enough" for your purposes.
    Mainstream OS's should already have SPI and I2C drivers, communications
    stacks, networking stacks, disk drive/ file system stacks, etc.
    (Windows, DOS?, OSX, Linux, BSD, Android?, iOS?). But, I would expect
    commercial real-time embedded OS's to have better support for
    instrumentation, control, automation, robotics, etc. (QNX, VX/Works).
    Some research/ academic/ niche OS's might have good ideas (Plan 9, Mach,
    GNU, FreeDOS).


    If you go this route, please pick something whose documentation is
    freely available and/or is standard literature (Stevens, Bach, McKusick,
    etc.).


    David

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmodule-authors @
categoriesperl
postedOct 21, '15 at 5:54p
activeOct 23, '15 at 1:20a
posts7
users5
websitecpan.org...

People

Translate

site design / logo © 2021 Grokbase