Michael J. Mahon wrote:
And even the USB isochronous modes are more geared to keeping a buffer from emptying than to precise real-time reactions in a communication that is 2-way. It is not possible, AFAIK, to control something on the other end of a USB link with microsecond precision.
I can concur there Michael. A year or 2 back we designed a USB I/O module for a customer. Most of the I/O was human input - buttons and switches - so timing wasn't that critical.
But they added some I/O for security - a door security module that you push out a random bit-stream and read it back on another pin to detect when the circuit has been broken. There were specific requirements for the frequency of the check - and hence the bit-stream. This is when the trouble began.
Looking on a CRO it looked fine - *most* of the time. We were using USB1.1 and pushing output every (IIRC) 1ms, expecting something back every 1ms tick. But occasionally we'd see gaps of several milliseconds where windows decided it was busy doing more important things, then a burst while it caught up. It was pretty much a lost cause.
And no, the jitter wasn't in the app itself, as we toggled a pin on the parallel port every time a frame was written to the USB module. At times we saw it push several 1ms frames into the USB stack and nothing out the other end.
Having said that, I don't believe in this case that it is a fault with USB itself. My guess is either crappy windows scheduling, or crappy windows programming of the USB host controller.
Someone mentioned that the 'magic box' that was required would actually *be* an Apple II - and for protected disks this may well be the case. But it's not actually a bad idea! It's fast getting to the stage where a 6502 can be implemented in a CPLD (probably can now?) and without the graphics and I/O there's not much more to an Apple than a CPU and some ROM & RAM. I'm yet to think this thru myself but I'm wondering if that really could be the way to go here? Interesting....
Regards, -- | Mark McDougall | "Electrical Engineers do it | <http://members.iinet.net.au/~msmcdoug> | with less resistance!"