Re: Homebrew STG card - Firewire or USB ?

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

Matt Shaver wrote:

>
> Thanks for this analysis! Hans W made a similar argument for high speed
> serial connections, but I recall that Fred and I talked about this one day
> and we came to the conclusion that for 8 axes plus 8 bytes of digital I/O,
> plus some allowance for protocol overhead you're talking nearly 1Mbit/sec (we
> figured it the way you did) and that figure has stuck in my head ever since.

Well, for serial I/O, with uarts, or whatever, the CPU has to manage the
protocol, with interrupts for (nearly) every byte, etc.  It is pretty clear
that the USB includes a fair bit of hardware, with either a CPU addressable
buffer memory or a DMA channel, to handle 12 Mbits/sec.  With the
hardware assist, and the 12 mBits/sec data rate, this sounds like it could work,
maybe even up to 8 axes.

>
> As for Linux support there is supposed to be some stuff in the 2.3
> development kernel.
>
> > 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.
>
> I think you're right about this. I wonder where the USB interface is in
> hardware space? I/O ports? IRQs? Could we just take it over and program it
> ourselves at it's lowest level assuming we were the only device hooked to the
> bus?

Well, I think we would have to make the restriction, at least, that you do
NOTHING else with the USB except for what EMC would know about,
when EMC is running.  So, that probably means, no keyboards, mice, or
scanners (!) hooked to it.  Also, since the USB drivers do reconfiguration
on the fly when stuff is hot-plugged/unplugged, it would be restricted to
NO plugging or unplugging when EMC is running.

The USB interface is generally hooked to the PCI bridges, and won't bother
the ISA/leagacy IRQs and DMA channels.  That should be true for practically
all Pentium-class motherboards in desktop systems.  Laptops - who knows?

> I think I read that the USB is a host master arrangement, so the USB
> software could be brought over to the real-time side of Linux which would
> then assign top priority to CNC related data transfers and defer all others.

Yes, by hook or by crook, hopefully the bulk of the driver code
could be moved to an RT module without a great deal of effort.

> 3. I'd be more comfortable if:
>
>         A. We built the "far end" from scratch ourselves, rather than relying on a
> company that could disappear at any time. It looks like they used an
> Anchorchips (Cypress) USB microcontroller as the basis of their board. I
> would hope that you would get at least a skeleton program for this device if
> you bought the (hopefully low cost) development kit.

Yes, maybe this is the best way to go.  This way, we could do whatever
is needed to assure worst-case latency, and also make our own back-end
bus for the USB converter card, to address however many modules we
think is needed.

>         B. I could find a simple, jargon free explanation of the USB!

Ah, there was a pretty extensive multi-part article that ran last year (and may
have started in 1998) in Circuit Cellar, Ink., the Steve Ciarcia magazine.
It looks a lot like an Ethernet protocol, to make things oversimplified.

> P.S. I've started reading at the Cypress site and I may be getting item #3B
> (or near enough). I'll do a little digging and see what comes of it...

Well, keep us posted.  But, if it looks like serious expense for
development gear, etc., then maybe the parallel port adapter is
a more straightforward path.

Jon