Re: USB to parallel converters

From: Nate Lawson <nate_at_root.org>
Date: Wed, 23 Jun 2010 13:41:48 -0700
Message-ID: <4C22718C.8050409@root.org>
Wolfgang Moser wrote:
> Nate Lawson schrieb:
>> Anders Carlsson wrote:
>>> While I have no practical experience of USB to parallel converters, I
>>> wouldn't expect much from them. Recently I bought two cheap USB to RS232
>>> converters: one HL-340 based and one PL-2303 based. I managed to get the
>>> HL-340 to speak to a serial EPROM programmer, but failed miserably to
>>> use both with C2N232I which was my intended use. I have looked up the
>>> matter and there are several factors such as choice of chipset, whether
>>> the adapter also have voltage level converters onboard, of course
>>> drivers and more. Since not even serial communication seems to be
>>> possible to "get right", I think you can look for a long while to find a
>>> USB adapter that better simulates a parallel port.
>>
>> Short answer: USB/LPT adapters will not work for driving hardware.
>> PCI/cardbus/expresscard adapters may work, depending on their design.
> 
> this is true, but...
> 
> please have a look onto the page I posted a link to. Although you are
> right about latency and such, Henrik Haftmann found a way to let most
> old DOS based programming dongles and software work even under modern
> Windows OSes.

It's an interesting design. He hooks the READ_PORT_UCHAR functions in
Windows or traps the inb/outb with debug registers. He gets around the
latency problem by trying to package multiple bit manipulations in a
single USB packet. Two back-to-back writes may get sent as a single USB
packet and then split apart again on the microcontroller.

However, in the cases where the software reads twice, he is stuck by the
125 us packet delay as well. So it is not always smart enough to handle
the IO cases. I think it will be fast enough for XE/XA1541 serial use
(possibly even with speeders) but certainly not parallel nibbling.

Have you tested it?

He is considering implementing a "bulk" mode where multiple commands are
queued up, including any delays between, and the whole batch is executed
by the microcontroller. Of course, that requires major software changes
to the user's code to support. This is the model the xum1541 uses,
especially for nibbling.

-- 
Nate


       Message was sent through the cbm-hackers mailing list
Received on 2010-06-23 21:00:30

Archive generated by hypermail 2.2.0.