On Tue, 19 Jul 2011 12:08:48 -0500, Lloyd E. Sponenburgh wrote:
"Bob La Londe" [wrote]

There is also something to the way resources are allocated for USB as
opposed to a dedicated hardware communication port. I'll leave that to
the guys who know more about specifically USB to explain if they like.
I know if I send a signal to a pin on a hardware LPT port it (barring
the speed of electrons down wire) its virtually delivered precisely
when its sent.

It has to do with the fact that USB resources are controlled from the
Windows kernel drivers. The windows kernel is not a real-time system.
It "queues" operations for completion, then goes off and does other
things while those queued tasks get done on a "when I can, IF I can"
basis.

That may be, but more importantly, USB -- being a serial protocol --
packetizes its messages at the hardware level, and software can do
little or nothing about it. USB hardware supports four kinds of
messages or transfers, none of which are entirely proper for
emulating a real-time LPT port.

(1) For example, although the shortest Control Messages may take as few
as 16 bytes to complete (two 8-byte packets for Setup Stage and Status
Stage), most USB control messages entail a handshake and a Data Stage,
so several times that many bytes get sent back and forth. (See
http://www.beyondlogic.org/usbnutshell/usb4.shtml)

(2) So-called "Interrupt Transfers" from device are "queued by the
device until the host polls the USB device asking for data."
To-device Interrupt Transfers can happen without buffering and
queueing, but still entail three packets (Token, Data, and Handshake
packets) and still can be delayed by buffering at device and by device's
packet validation step.

(3) After being set up, Isochronous Transfers are fast one-way transfers
with bounded latency and no guarantee of delivery, ie fast enough for
real-time control but not ok for reliable interactive control.

(4) Bulk Transfers likewise are unidirectional and fast but have no
guarantee of bandwidth or minimum latency.

The page http://opensourcebridge.org/proposals/40 comments: "Ever get
an urge to control a robot using real time Linux and a serial port, but
find that your computer only has USB ports? [...] Sure, youve been told
that USB is broken for real time at the specification level, but that
wont stop you from trying!"

When a machine-language component of software talks directly to a
hardware device (barring getting pre-empted by interrupt service
routines) the physical task occurs immediately. When a program talks to
the kernal routines instead of directly to the hardware, queued tasks
can take microseconds to _minutes_ to get executed on the hardware.
This is worsened by the fact that many USB peripherals themselves queue
operations, separate and apart from the kernel queuing.

That's why the EMC guys talk about using a "non-preemtive, real-time
kernel" in Linux to run machine control routines.

With the right kernel AND the right USB hardware, USB peripherals _can_
be used in real-time. You just have to pick devices that don't have
their own non-real-time queuing on-board. And if you have to use a
Microsoft product, don't use Windows -- use DOS. But, then, that's not
a very pretty scenario, either.

See http://www.freedos.org/freedos/news/technote/195.html re driver
problems with DOS.

--
jiw