Linux drivers for robots: /dev or sockets ?

General Robotics Forum - All aspects of robots and their applications. 

Page 3 of 3       << first < 1 2 3 Bookmark this page:  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
Linux drivers for robots: /dev or sockets ? Bob Smith 10-16-2009
If you were  Registered and logged in, you could reply and use other advanced thread options
Posted by Bob Smith on October 21, 2009, 3:10 am


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.

thanks
Bob Smith



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)

Page 3 of 3       << first < 1 2 3

The site map in XML format XML site map
other useful resources:
Official Robosapien Website
Lego Mindstorms Website

Contact Us | Privacy Policy