USB can be used in an interrupt driven system. For example a timer can be
used to to generate a periodic interrupt to trigger the usb data to be
sent. Just as can be done with a parallel or serial port. In the case of
directly driving steppers the periodic time constant must be low enough or
the stepper controller must be smart enough to buffer enough incoming data
to last until the next data transmission. Even smarter hardware might send
an interrupt request to the PC to request more data to fill it's buffer.
A good demo of this was done in the Windows port of EMC2 RTS. Here a
Windows XP, Vista, or 7 host uses the USB port to send data to a PIC uC to
be buffered. The step data is then used to drive the motor steps. The data
transfer rate is plenty high enough but the period between transfers is the
issue. Under Linux, USB can be accessed at a lower level then under Windows
and results in lower transmission latency.
Playing Devil's advocate I'd say that RTOSs in uC devices can and do
provide almost identical access to hardware USB as they do to parallel
ports.... But on the PC level you are right in that the OS allows much
lower level access to the para port.
On Tue, Jun 26, 2012 at 11:53 PM, Tony Smith <ajsmith1968@...> wrote:
> ∗∗
>
>
> > The typical approach for using a paralleled port is to write to the port
> directly
> > without buffering. Most implementations of stepper controllers using USB
> use
> > either a buffering mechanism or interrupt driven data feed.
> > The actual throughput of a high speed paralleled port is on the order of
> > 512Kbps. The standard through put of a USB 2.0 port is 480Mbps. The issue
> of
> > choppiness is one of the OS/Software implementation and not the hardware
> > port. The issue arises from the fact that writing directly to the
> parallele port is
> > much easier than writing directly to a USB port.
> > Again, the issue is in the software handling of the port and not the port
> speed.
>
> That's what I said, you need extra (and smart) hardware to use USB. There
> is no OS that can handle USB in the same fashion as parallel.
>
> It doesn't matter how fast you can pump bits out the USB port, there is no
> guarantee of when they will arrive. USB is like catching a bus, you wait
> for ages then three turn up at once.
>
> Tony
>
>
>
--
If you ask me if it can be done. The answer is YES, it can always be done.
The correct questions however are... What will it cost, and how long will
it take?
[Non-text portions of this message have been removed]