In response to the recent troll invasion:

I've just started work at a CNC router manufacturer, doing control
system programming. The machine I'm using to test & prototype control
algorithms is Linux with the RTAI real-time patches and I/O card
drivers from the Comedi project. The way to get a hard-real-time
process? Build and install a ——ing kernel module! As regards
communicating with arbitrary I/O cards Comedi isn't completely
useless, merely so painful it should be called Tragedi.

The prototyping machine is completely in my control, so I could use
Plan 9 — if I could justify writing the drivers. Trouble is, the
driver for the D/A converter comes with Comedi and someone here has
already written a driver for the quadrature encoder. So I'm stuck on
that end. I got a lot of programming done in school using acme under
Plan 9; for the first time I realize why the lunix world likes
Eclipse. ☹

So you have the source for the quadrature encoder, and a DAC cannot be thar complex can it? why not email Comedi and ask them for card programming info.

Having said that I do sympathise, its difficult to work out the trade off between
putting up with systems you find unplesant and hoping you don't use them much,
or puttin the effort to redesign them.

Still you could use 9vx to run plan9 on top of this system, that way you could maybe
migrate the system gradually.

Russ has a version of libthread for windows on his web page.

-Steve

On Wed, Jul 2, 2008 at 7:13 PM, Steve Simon quintile.net> wrote:

Comedi is an Open Sores project to unify the worlds data acquisition
devices under one driver model. It's about as good a model as fits
the Linux Way™ of these things, and there's enough sample code
included to make it feasible to bring up a new card fairly quickly.
Rather have Comedi drivers than some random vendor's conceptions of
how to program the device, but it's nothing like a simple write(2) to
/dev/analogout0/channel1.

The only issue is that I can't justify the time needed to write Plan 9
drivers when a usable system already exists.

Unless vx32 can run real-time tasks (pretty sure it cannot) that's not
much use. Almost every bit of my code (all except a very thin command
interface) is living in a loadable kernel module

Don't you want Kalman filters in *your* OS kernel?