I’ve been struggling recently with the extremely small JST SH connectors, which are 1.0mm crimp-style. No matter what wire I use, I can’t get them to stop breaking, and they’re a royal pain to put together in the first place. This is a problem, because it’s one of the only connectors I can find that’s small enough to fit on my current project’s board with 6 pins. I need those pins for power, ground, the two Xmega PDI lines, and a debug serial port. Currently I connect either a standard AVR-ISP mkII or a Bluetooth serial adapter to the boards via this tiny connector, and all that wear and tear on the connector and wires is becoming quite evident.
I’m about to ditch Bluetooth for quite a few reasons, but that’s a whole other story. Suffice it to say: the replacement will be an Xmega-based device, and that’s where this nifty little trick comes from.
I did some hunting and found that there actually is a connector that’s even smaller than the SH-6: USB micro-B. It’s a hair narrower, and about 20% shallower, resulting in that much more board space to work my routing magic. The only problem: USB only has 5 pins….
My first (or near enough) thought was “use the shield”. Since I’d be constructing the cable from scratch, I can solder a 6th wire to the shield (which is not otherwise connected to anything but the cable’s braid) and use that as ground. Cheesy, but functional.
Then I thought about how the PDI protocol is actually implemented. I’d rewritten most of the PDI stack based on the example code in LUFA recently, and it turns out that PDI is basically a bidirectional synchronous serial protocol. That means that RX and TX are both connected via 220R resistors to the PDI_DATA line, and XCK drives PDI_CLK. This presents the possibility that the PDI and serial lines could be shared.
As it turns out, this works very nicely. On my breadboard I hooked up an Xmega target and Xmega programmer, with a crazy serial loopback chain that routed from an FT232R through the programmer to the target, and out another FT232R. The PDI and serial ports from the target are routed to the middle, where the resistors create PDI_DATA from RX and TX. PDI_CLK, RX, and TX hop over to the three pins on the programmer. The software running on the programmer is a two-port serial loop-through, with the exception of a “p” coming from the test computer. In that case, it shuts down the normal serial port, starts up the PDI interface, confirms the chip’s signature, then switches back.
The end result is a 5-pin interconnect between the two chips with both full hardware programming and serial debugging capabilities. As such, we can now route it through a USB micro-B connector ;-)
Now, this won’t work with a “discrete” PDI prorgammer, since you only get the combined Rx+Tx line out of the programming header, and this trick depends on combining them on the device. Thus, you pretty much have to have a “custom” unit doing the programming and serial bridging. However, that’s exactly where I’m headed after Bluetooth bites the dust…