I think you are out of luck on the latency front, I was looking at low level USB controller code(uhci) today. Basically the hardware works around DMA lists tied to 1ms interrupts. In it was a comment on the interrupt type transfer actually being "polled" ;), the term interrupt being a misnomer in this case.
Most PC hardware is cached/buffered, and designed to be that way. The most obvious solution for CNC/stepper control is to delegate the work to a microcontroller(a smart controller). This scheme has it's disadvantages, probably the biggest is the extra time and expense involved with software programming microcontrollers(and making PC boards). The LPT port used to be faster. Now it's relegated to some superIO chip hanging off a 4-bit peripheral bus somewhere on the south side.. Good grief. My 2Ghz machine can only bit bang at 1Mhz, ugh! On Mon, 29 Nov 2004 20:02:26 -0500, Gene Heskett <[EMAIL PROTECTED]> wrote: > On Monday 29 November 2004 19:00, Joe Pfeiffer wrote: > > And I taken the liberty of adding that list to the Cc: line. > > > > >Gene Heskett writes: > > > We have a rather lively discussion going on on the emc (linuxCNC) > > > list regarding the use of a usb port to replace the disappearing > > > parport, and main 'bone of contention' is the maximum data rate > > > of 1000 groups of packets/second because there is a 1 ms delay > > > built into the protocol. Sure you can send more packets, but > > > they go out at 1ms intervals, death to any realtime control > > > efforts. Maximum step rate would be 500 per second, with the > > > first slowdown being to 250 etc. > > > >Where is that in the standard? After seeing your message I spent a > >while rummaging around and couldn't find anything about it... I did > >find the 1 msec frame for full-speed and low-speed devices, and the > >125 usec microframe for high-speed devices, but I couldn't see any > >reason multiple transfers couldn't happen in a frame; in fact, the > >tables in chapter 5 give a pretty clear picture that lots of > > transfers can occur in a frame. > > That also describes the problem. Sure, many bytes can be sent per > frame (if thats the proper term) or on a 2.0 circuit, maybe a > microframe. > > The point being that for real time control of stepper motors, the step > signals need to go out at a steady beat, whether that beat is 10 > times a second, or 50,000 times a second, and any variation in > between. In other words, when the motor is to be stepped, and an > outb is done at a certain rate, that certain rate must be maintained, > and cannot be subjected to any resync to a fixed clock that might be > built into the protocol. They cannot go out 10 packets at a time, > (your "multiple packets per frame" above) and then wait for the next > time the port can be energized, thereby skipping the time slots those > 10 packets represent, and then sending them as a single burst of > data. Motors, being subject to inertia effects, simply cannot have > their input signals subjected to the loss of coherency that we are > reading into the present information regarding the usb standard thats > published, albeit rather hard to come by if you are not a member of > the usb consortium. > > In other words, a one byte write must be rx'd at the motor in a delay > thats no more than the parallel->serial to get thru the cable and > then seriel->parallel to get to the output port amount of time. > > Does that clarify our dilemma? > > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
