"Bob La Londe" fired this volley in
:

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.

When a machine-lanquage 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.

LLoyd


LLoyd