Saturday, May 15, 2010

Design Choice Consequences

Getting slightly philosophical for a technical blog here, but its fascinating how early design choices will affect future work.

For instance, you may have noted that I haven't mentioned much detail about the MCU that connects the XBee wireless module to the Roomba and grabs the ultrasound data. I've been struggling with this problem for a couple days now. The problem is that I want 2 UARTs in a single MCU, one to connect to the Roomba and one to the XBee. But I also want to be able to make my own in circuit programmer instead of buying one for a lot of money. Making programmers is fairly simple for PICs (quick google search for JDM programmer will give you some idea) but PICs with 2 UARTs are unusual and aren't supported with the normal free hex programming software like IC-Prog. Hmm.

I mentioned this to a friend today, who suggested multiplexing/demultiplexing the 2 serial lines together. Actually its a great solution, and I found it recommended on a couple sites and forums, but it has serious repercussions for my software later on. For example, imagine I want to see if the Roomba's main touch sensor is pressed. I select that channel for my TX output and send the message to get sensor data. Now I select the RX channel that comes from the Roomba, and get the sensor data. But in the mean time, if the Arduino tried to send any data over the XBee, it would get lost because the RX is demultiplexed to the Roomba not the Arduino.

As far as I can tell this means the processor on board the Roomba will have to be the Master for both channels of communication. It will have to send a message, then wait for the response (or a time-out) before communicating with the other device. There are other tricky solutions like triggering an interrupt on a rising edge generated by a serial communication on the RX line, and switching to receive from that channel but this could still generate problems if both Roomba and Arduino were transmitting at exactly the same time.

Not sure as of now what this will mean in terms of software, but I can't see it making things easier. And all because I am looking to save the cost of a MCU hardware debugger/programmer :) and make my own.

On a more technical note, I've decided on the PIC18F1320 and I'm working on designing a fun programmer that uses the on-board unregulated power supply of the Roomba instead of the tricky serial cable trick JDM uses. Less power friendly, and uses opto-couplers so I'm sure there is a fancier way, but I'm hoping to adapt it for use with a USB-Serial converter that generally won't generate the high voltages that the JDM style programmers use. I'll post results and improvements when I get some tests done. I also have a post planned that explains how the JDM programmer converts the 7.5V from a serial port into 12V programming voltages, and general programming theory/applications for the PIC.

No comments:

Post a Comment