Well, kind of. Here’s how shit went down.<\/p>\n
First off, I had to make one last wire jump for everything to stand a chance of working. The reason is because I connected the RTS pin of the FTDI cable (through the wonderful Adafruit XBee adapter) to DIO8 on the XBees:<\/p>\n
(Don’t mind where it says “DIO12” – that’s because Sparkfun’s XBee footprint is weird, or something – it’s actually DIO8 according to the manual)<\/p>\n I chose DIO8 instead of DIO3, the usual choice, because it was much closer to the appropriate pins of the ATMega based on component placement. It would have been less of a topological acid trip to route the trace there. The only problem with choosing DIO8? It’s not a thing<\/em>. As in, DIO8 turned out to be only DI8 when I tried to configure it in X-CTU.<\/p>\n Hmm. Well that’s disappointing. Wire jump time:<\/p>\n I performed a Little Purple Wire jump, after cutting the DI8 trace, to DIO6 across the other side. Conveniently DIO6 was also the XBee’s default RTS pin. However, in the interest of following instructions for now, I configured the pin as standard digital input (on the transmtiter side) and a default-high digital output (on the receiver side). Now, I’m assuming there’s pretty much no difference at this point between setting it as instructed or setting both sides to “RTS FLOW CONTROL” for this pin, but I could be wrong.<\/p>\n The fix was promising at first – I could upload blink programs of various durations with no problems through Arduino, getting to the “Done Uploading” stage every time. But as soon as I tried uploading a bigger program, it would quit – usually after only a few seconds (short enough to transmit a blink program, but nothing much else). The activity LED would turn off, whereas if it were transmitting, it would be on pretty solidly.<\/p>\n Scoping the TX\/RX pins and the DIO pin associated showed that the reset pulse was making it through (as my hack D13 LED did flash) and at least something program-like was being transmitted. However, it would randomly shut off, and the process would abort with avrdude-in-Arduino complaining that the programmer was out of sync.<\/p>\n I thought it might have been a mild baud rate mismatch<\/a> problem (and still suspect it to some degree), so I hardwired Tx and Rx straight to eachother on the XBee adapter board:<\/p>\n Of course<\/em> this arrangement worked. The blame now lay square with the XBee, and at Shane’s behest, I reset both XBees to factory default, wiping every setting I might have changed, and then changed things back exactly as instructed. (The transmitting one came out of the defunct RazErblades glove controller<\/a> and the receiving side came out of…. hell if I know where)<\/p>\n It worked.<\/p>\n But only sporadically. I’m in a position now where some uploads will complete, some will totally fail within the first few seconds, and others will seemingly fail and cause Arduino to wait forever in the “Uploading…” stage until finally terminating, usually a full minute later, with an out of sync error.<\/p>\n Weeeeird. Well, at least I can upload some code:<\/p>\n![\"\"](\"\/pics\/edf\/pc25.png\")
<\/a><\/p>\n![\"\"](\"\/pics\/edf\/pc22-mid.jpg\")
<\/a><\/p>\n![\"\"](\"\/pics\/edf\/pc23-mid.jpg\")
<\/a><\/p>\n