Re: Homebrew STG card - Firewire or USB ?

[Jon Elson <jmelson-at-artsci.wustl.edu>]

Doug Fortune wrote:

> Jon Elson wrote:
>
> > > If you wanted to consider PC ->USB->breakout box with I/O's
> > > then the dirty work has already been done, and almost dirt cheap at
> > >
> > > http://www.ActiveWireInc.com/
> > >
> > > "ActiveWire-USB with programmable I/O pins that can interface to
> > >   anything.  Control the pins from your browser by HTML/ javascript or
> > >   VBasic or C.  Win95/98/2000, Linux, FreeBSD, LabView drivers available
> > >   NOW! Macintosh next...  "
>
> > One thing that needs to be addressed is worst-case latency on the USB, and
> > using the USB drivers.  Can this really handle real-time work?  The DAC,
> > PWM output, or whatever drives the servos, and whatever reads the encoders
> > needs to be serviced at predictable intervals.
>
> Ok, how about going to the next step, 100,200, or 400 Mbits/s Firewire?
> a book: http://www.ercb.com/brief/brief.0065.html
> Adaptec has cards and development kits:
> http://www.adaptec.com/products/solutions/1394.html
> http://www.whatis.com/firewire.htm  overview says

Well, just because it is faster does not mean it is real time.

> FireWire is Apple Computer's version of a new standard, IEEE 1394 High
> Performance Serial Bus, for connecting devices to your personal computer.

No, actually National Semiconductor (and others, I think) devised FireWire
quite a while ago, and the consortium arranged to make it a registered
standard.

> FireWire
> provides a single plug-and-socket connection on which up to 63 devices can be
> attached with data transfer speeds up to 400 Mbps (megabits per second). The
> standard describes a serial bus or pathway between one or more peripheral devices and
> your computer's microprocessor. In the next few years, you can expect to see many
> peripheral devices coming equipped to meet this new standard. FireWire and other
> IEEE 1394 implementations provide:
>
>      A simple common plug-in serial connector on the back of your computer and on many
> different
>      types of peripheral devices
>      A thin serial cable rather than the thicker parallel cable you now use to your
> printer, for example
>      A very high-speed rate of data transfer that will accommodate multimedia applications
> (100 and
>      200 megabits per second today; with much higher rates later)
>      Hot-plug and plug-and-play capability without disrupting your computer
>      The ability to chain devices together in a number of different ways without
> terminators or
>      complicated set-up requirements
>
> IEEE 1394 provides two types of data transfer: asynchronous and isochronous. Asynchronous
> is for
> traditional load-and-store applications where data transfer can be initiated and an
> application
> interrupted as a given length of data arrives in a buffer. Isochronous data transfer
> ensures that data flows
> at a pre-set rate so that an application can handle it in a timed way. For multimedia
> applications, this
> kind of data transfer reduces the need for buffering and helps ensure a continuous
> presentation for the
> viewer.
>
> The proposal then is to buy a PCI firewire card for the PC (current generations of Apples
> and upcoming generations of PC's will probably have firewire already built-in), and build
> a single daisy-chainable servo controller/driver board.  Up to 16 of them can be logically
> chained together on a single cable,  for considerable flexibility in choosing the number
> of axes.
>
> If the data rate & latency prove acceptable, this could carry us many years into the
> future...

Well, first, the USB is present on many PC motherboards, already.
Linux support is supposed to be there, too.  12 Mbits/sec seems iffy,
but if the protocol was efficient, then it is plenty.  Let's say you have 3 axes,
and need to receive a 24-bit position and send a 12-bit DAC value
for each axis, every cycle, which we will set to 2 KHZ.  Now, that's
3 axes x 5 bytes/axis x 8 bits/byte x 2000 cycles/sec = 240,000 bits/sec,
or 2% of the available bandwidth.  (now, actually, there would need to
be a block out and a block in every cycle, but it still looks like there
has got to be enough to do this, and add more axes, crank up the cycle
rate, and still be in the clear.

Clearly, data rate is not a problem.  I have no idea what the driver
performance of the Linux end of the USB support is, but it could be
subverted to become part of the RT package, if necessary.  That
would be extra work, of course, but might be necessary to be sure
the necessary I/O is performed on time.

Finally, there is the performance of the far-end unit, such as the
Active-Wire boards, which are VERY interesting, but there isn't
much performance info.  Finally, from the Active-Wire documents,
I couldn't tell how much I/O you really get from their main board.
Can you stack several of the DAC, opto-isolator, motor control,
etc. add-on boards on one Active-Wire USB board, or do you
need another $59 USB board for each add-on board?
Has anyone taken a look at the Linux support for this thing?
I couldn't find any reference to the Linux support other than
where it says "drivers available now".

Jon