posts:open-hardware-analog-io: Add post on open analog I/O

Also update the open source force spectroscopy post to link to my
thesis.

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

diff --git a/posts/Open_source_force_spectroscopy.mdwn b/posts/Open_source_force_spectroscopy.mdwn
index 0bc5c04ea729f4d4845e83af42b40c8d437258f6..5f9fa960bde02beed4dbd4468063bc5a3de11101 100644 (file)
--- a/posts/Open_source_force_spectroscopy.mdwn
+++ b/posts/Open_source_force_spectroscopy.mdwn
@@ -1,6 +1,7 @@
 There are a number of open source packages dealing with aspects of
 [[single-molecule force spectroscopy|force_spectroscopy]].  Here's a
-list of everything I've heard about to date.
+list of everything I've heard about to date (for more details on
+calibcant, Hooke, and sawsim, see my [[thesis|Thesis]]).
 
 <table>
        <thead>