HOWTO: Connecting an IBM LPFK to a USB port
classiccmp at philpem.me.uk
Wed Sep 3 16:06:14 CDT 2008
I've just finished testing my fully assembled (i.e. intended-to-be-permanent)
LPFK-to-USB cable. It uses an FTDI TTL-232R USB-to-RS232/TTL converter, a
MAX232 level translator, five 0.1uF 0805-size surface-mount ceramic
capacitors, a BC547 transistor (well, actually the SMD variant, the BC857), a
4k7 0805 SMD resistor, an 8-pin Mini-DIN plug... and a plastic Maxim/Dallas
Semiconductor antistatic box. I did end up using a bit of copper tape and
superglue as well (to hold the 4k7 and BC857 on the body of the MAX232)...
First problem: if the connector is assembled as recommended by the
manufacturer, it's too big to fit in the LPFK's rather small connector port.
The solution to this is simple -- ditch the thick (2mm on my connector)
rubberised outer cover and use heatshrink instead. As long as you're quick,
the plastic inner support won't melt, but assembly is pretty much one-way.
It's not easy to assemble, fairly easy to cut apart again, but $DEITY help you
when you need to put it back together again. Six wires to desolder, *then* you
can put the heatshrink back on. Thankfully properly-soldered mini-DIN
connectors are usually quite reliable...
Next problem is that the LPFK speaks 12V RS232, while the TTL-232R uses
TTL-form inverted RS232. Another easy solution -- put a MAX232 between the
LPFK and the TTL-232R to bump the levels. I also added a transistor and a 4k7
resistor to toggle the LPFK's reset line from the serial port's RTS output.
That means that when the PC is idle, the LPFK is held in reset, and when the
port is open the LPFK is released from reset. Advantage being that if you
manage to crash the LPFK, you just need to toggle RTS and wait a few seconds
for the LPFK to restart. It does tend to blink a few times when the USB
drivers pick up the cable, but only on Windows. Maybe it's the software for my
mobile phone trying to pick up a serial cable (despite the fact my phone
connects over USB.. natch).
I couldn't find any small plastic cases in my junk box, so I used an empty
Maxim/Dallas antistatic plastic box. As in, the little clear plastic boxes
that hold the parts they send out as free samples. These are small, relatively
tough (though a bit thin) and ideal for small projects. Speaking frankly, I'd
much rather have unclipped a ferrite EMI bead from a USB cable and used that,
but the only ones I could find were moulded onto the cable. Shame, they were a
Lastly, I had to reprogram the TTL-232's descriptor table so it claimed the
full 500mA of current from the PC. Unplugging the cable from the LPFK will
allow the TTL-232 (and MAX232) to start up and enumerate, then you can use
FTDI's MProg tool to reprogram the power consumption descriptor (and the
description strings too, if you like). Some USB chipsets / motherboards / etc.
are more fussy about power consumption than others. 99.5% of the machines I've
used seem to ignore the USB port's power consumption unless you short it out,
in which case the machine tends to reboot in short order...
I've also got an LPFK driver library that works with the USB cable, but should
also work with a standard serial cable. You can grab the source code from
<http://hg.philpem.me.uk/liblpfk/>, and it should work on any OS that supports
POSIX serial communications (that would be Linux, OSX, the BSDs and most of
the other Unices, and possibly QNX and Slowlaris - sorry, Solaris - as well).
Porting to Win32 is left as an exercise to the reader.
The library can do LED setting in both cached and uncached modes (translation:
you can change one LED's state and have the LPFK update immediately, or change
a dozen at the same time). Key processing is done with an lpfk_read() function
that returns LPFK_E_NO_KEY if no keys have been pressed recently, or
alternatively returns the first key code in the serial FIFO buffer.
classiccmp at philpem.me.uk
More information about the cctalk