posts/Open_hardware_analog_IO.mdwn

   1 [[!meta  title="Open hardware analog I/O"]]
   2
   3 Over at [Software Carpentry][SWC], Greg Wilson just posted [some
   4 thoughts about a hypothetical open science framework][GW].  He uses
   5 Ruby on Rails and similar web frameworks as examples where frameworks
   6 can leverage standards and conventions to take care of most of the
   7 boring boilerplate that has to happen for serving a website.  Greg
   8 points out that it would be useful to have a similar open science
   9 framework that small projects could use to get off the ground and
  10 collaborate more easily.
  11
  12 My [[thesis|Thesis]] is about developing an [[open source framework
  13 for single molecule force
  14 spectroscopy|Open_source_force_spectroscopy]], so this is an avenue
  15 I'm very excited about.  However, it's difficult to get this working
  16 for experimental labs with a diversity of the underlying hardware.  If
  17 different labs have different hardware, it's hard to write a generic
  18 software stack that works for everybody (at least at the lower levels
  19 of the stack).  Our lab does analog control and aquisition via an old
  20 National Instruments card.  NI no longer sells this card, and
  21 developing [[Comedi]] drivers for new cards is too much work for many
  22 to take on pro bono.  This means that new labs that want to use my
  23 software can't get started with off the shelf components; they'll need
  24 to find a second-hand card or rework the lower layers of my stack to
  25 work with a DAQ card that they can source.
  26
  27 I'd be happy to see an inexpensive, microprocessor-based open hardware
  28 project for synchronized, multi-channel, near-MHz analog I/O to serve
  29 as a standard interface between software and the real world, but
  30 that's not the sort of thing I can whip out over a free weekend
  31 (although I have [[dipped my toe in the water|AVR]]).  I think the
  32 missing component is a client-side version of [libusb][], to allow
  33 folks to write the firmware for the microprocessor without dealing
  34 with the intricacies of the [USB specs][USB].  It would also be nice
  35 to have a standard USB protocol for Comedi commands, so a single
  36 driver could interface with commodity DAQ hardware—much like the
  37 current situation for [mice, keyboards, webcams, and other approved
  38 classes][USB-class].  Then the software stack could work unchanged on
  39 any hardware, once the firmware supporting the hardware had been
  40 ported to a new microprocessor.  There are two existing classes (a
  41 [physical interface device class][PID] and a [test and measurement
  42 class][TM]), but I haven't had time to dig through those with an eye
  43 toward Comedi integration yet.  So much to do, so little time…
  44
  45 [[!tag tags/hardware]]
  46
  47 [SWC]: http://software-carpentry.org/blog/2013/06/twelve-bar-blues-of-science.html
  48 [GW]: http://software-carpentry.org/blog/2013/06/twelve-bar-blues-of-science.html
  49 [libusb]: http://www.libusb.org/
  50 [USB]: http://www.usb.org/developers/docs/
  51 [USB-class]: http://www.usb.org/developers/devclass_docs#approved
  52 [PID]: http://www.usb.org/developers/devclass_docs/pid1_01.pdf
  53 [TM]: http://www.usb.org/developers/devclass_docs/USBTMC_1_006a.zip