R
Roger Hamlett
- Jan 1, 1970
- 0
The problem is that devices like this, do not take 'parallel portJim Thompson said:I would think that one of you bit-bangers could design a USB-to-LPT
device and then write software to take parallel port commands and
convert them to USB (and back). No?
commands', but direct bit I/O, often at high rates. So (for instance), the
driver may issue something like a 1uSec pulse easily when talking directly
to the port, but via the 'time sliced' system used on USB, this becomes
very difficult indeed. The only 'universal' way to do it for output, would
be to use something like a bulk I/O device, and sample the data to be sent
perhaps every uSec, and then send this as a block to the USB device, which
generates the output at the same rate. This however would fail, if the
communication is bidirectional. If (for instance), the local driver
expects to output a bit, and then only a uSec latter, retrieve a 'reply'.
By the time the transmission is packetted up, and sent over USB, then the
reply is received, hundreds of times the expected delay wuld have taken
place. The way it can be done, is to put significant intelligence in the
USB device, and program this to output the required patterns, and retrieve
the data, then send this as a 'non timing critical' transaction over USB.
This can be done, and several companies do such adapters for their older
devices, but it requires a new local driver, and custom code in the USB
device, which makes this a more expensive solution....
Best Wishes