Groups | Search | Server Info | Login | Register

Groups > perl.module-authors > #3258

Re: Module heirarchy naming for SPI/I²C device drivers

Show key headers only | View raw

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

Back to perl.module-authors | Previous | Next — Previous in thread | Find similar

Thread

Module heirarchy naming for SPI/I²C device drivers leonerd@leonerd.org.uk ("Paul \"LeoNerd\" Evans") - 2015-10-21 18:54 +0100
  Re: Module heirarchy naming for SPI/I²C device drivers mca@sanger.ac.uk (Matthew Astley) - 2015-10-22 11:39 +0100
    Re: Module heirarchy naming for SPI/I²C device drivers leonerd@leonerd.org.uk ("Paul \"LeoNerd\" Evans") - 2015-10-22 12:42 +0100
    Re: Module heirarchy naming for SPI/I²C device drivers leonerd@leonerd.org.uk ("Paul \"LeoNerd\" Evans") - 2015-10-22 18:15 +0100
    Re: Module heirarchy naming for SPI/I²C device drivers aaron@priven.com (Aaron Priven) - 2015-10-22 12:52 -0700
  Re: Module heirarchy naming for SPI/I²C device drivers dpchrist@holgerdanske.com (David Christensen) - 2015-10-22 18:20 -0700

csiph-web