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
