|
Posted by Joe Pfeiffer on October 22, 2009, 2:31 pm
> Joe Pfeiffer wrote:
>> I came in late in this discussion
> Joe, the discussion morphed a little.... So there's an FPGA board
> that has nine user-selected robot peripherals out of a field of
> about 30 possible. There is a SLIP encoded protocol to the board
> that does register reads and writes to the control and status
> registers that define each peripheral.
> Think about USB. You don't want to deal with *USB* for everything --
> you want the USB subsystem to hide the USB connected peripherals
> behind device drivers. My intent was to do the same for the robot
> peripherals on the FPGA board. There would be /dev/dp/quadrature0
> to get the values from the quadrature decode on the FPGA. I'd hide
> the details of the SLIP protocol and the detail of the register set.
> So my original thought was to build a couple of simple device drivers
> that were shims. They offered up a /dev/dp/quadrature0 device node even
> though the real driver was a user-space daemon talking over ttyUSB0.
> My question was, is it better to use real device node or (like LIRC)
> use a unix domain socket as the low level connection point?
> If you have a stong opinion I would like to hear it.
This isn't a particularly strong opinion, but if I were doing it I'd
expose the device using your /dev/dp/quadrature (etc) approach, but
there's no real reason for there to actually be device drivers unless
part of your interface calls for ioctl calls -- they can easily be Unix
domain sockets, or even a FUSE filesytem.
Much more important is that there be a good, well-documented API on top
of however you expose the device that users can use without knowing
those details. The user just wants to be able to call get_quadrature(),
and not worry about how that function is implemented.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
|