Communicating with microcontrollers - I2C, RS-232, etc...

tetsujin · Post by **tetsujin** » Tue Sep 02, 2008 8:30 pm

Hiya,

at some point in the future I want to do stop-motion with my models... As part of that I want the models themselves to have computer-controllable lights so I can automate certain tasks of controlling the lights... So basically I'm looking at my options for interfacing the PC to all those microcontrollers...

My first thought was DCC, the protocol used for model trains. This would only require two wires (DCC communicates by flipping the polarity of the lines that supply power) but I think it would be unidirectional... It would also require that each model carry a full-wave rectifier in order to get a DC power source...

My next thought was to use TTL-level RS-232 - probably a unidirectional communication with all the models monitoring the same signal line. That would probably be the easiest option - I could get a USB-to-232 chip and use that to get the TTL-level RS-232, or I could use a level converter or a simpler circuit... Then all communications over the serial channel would have to be encoded with the intended recipient and the microcontrollers in each model would just ignore anything not directed at them... This would be a three-wire solution...

I'm also considering I2C, which would be a four-wire solution (power plus clock and data) - it would also be bidirectional, and the different models could be simply strung along all on the same bus... Then I would need a separate interface (another microcontroller, I guess) to bridge RS-232 or USB to I2C... My main concern with this approach is that the physical topology of the I2C bus is a little unfavorable - it'll limit the communication speed (not a big deal, really) - I don't know if there would be other consequences of the way the wires would be run to (and through) the models... Also I am a bit wary of the I2C approach because I feel like it might be more complicated to implement than I need...

So I am wondering what people can tell me about the various approaches for a problem like this - especially I2C.

jwrjr · Post by **jwrjr** » Tue Sep 02, 2008 10:33 pm

I am partial to SPI - the transmission speeds are much faster. If it is a single-master setup, it should not be difficult. You can use RS-422 transmitters/receivers if you need to communicate with many controllers.

tetsujin · Post by **tetsujin** » Tue Sep 16, 2008 6:35 pm

Well, for what I'm doing I don't need a high data rate - really the premium is on minimizing the number of lines needed to carry power and data. This is why I initially thought of using DCC (unlike Dallas 1-wire, you can do DCC with just two lines for power and data and easily put out enough power to drive a bunch of LEDs... To get your DC power from DCC you just need a rectifier bridge and a capacitor to smooth out the signal - while with 1-wire each slave device needs a capacitor that can store enough power while the power/data line is "on" to continue powering the device when the power/data line is "off"...) For that reason I don't think SPI would work for my purposes - four lines plus power and ground is too much.

Presently I'm thinking of maybe using Dallas 1-wire, but with a separate line for a high-current DC power supply, to avoid the need to use a parasitic power supply feeding on the data line. It also seems like 1-wire's typical speed is better suited to my application. (I think I2C's speed is normally too high for the physical layout of the bus I'd be using... I could rig up a slower I2C master, or I could just get a regular 1-wire master and use that...) That would mean three wires into the model...

One of the tougher areas on one of my current models is the knee of a robot model - if the power + data comes in through the foot, then three wires have to go up through the knee to the microcontroller in the torso - and then, additionally, one wire has to come back down from the chest to the leg to control lights there... Running four wires through the belly, hip, and knee joints is already pushing it as is, I think... The reason I ultimately gave up on the idea of using DCC is because I realized there would still be at least four wires going through the knee joint (unless I used a couple diodes in the leg to get "ground" from the two DCC lines, I guess... Though dealing with DCC seems like it'd generally be a pain anyway...)

I'm planning to pick up a USB-to-1-wire adaptor and experiment with it a bit... It seems another advantage of 1-wire over I2C is that, of the premade USB adaptors with drivers already available on Linux, the ones for 1-wire are a lot cheaper than those for I2C...

jwrjr · Post by **jwrjr** » Tue Sep 16, 2008 10:10 pm

I2C will probably be a good choice in that there are many different processors that communicate via it while the Dallas/Maxim one-wire protocol is somewhat proprietary.

macfrank · Post by **macfrank** » Tue Sep 16, 2008 10:54 pm

1-Wire is simple in hardware but expensive in code & CPU time, especially if you have more than one device on the line and have to do a poll and ROM check. If your CPU is limited in ROM space and RAM space, it would be a poor choice. Each ROM ID is 8 bytes long and unless you're using a Maxim/Dallas device, you'll have to come up with your own ROM codes.

An option would be to have a single micro to act as the 1-wire communications interface to all the devices down the line. It can do SPI or IC2 to your main CPU.

tetsujin · Post by **tetsujin** » Wed Sep 17, 2008 1:52 am

jwrjr wrote:I2C will probably be a good choice in that there are many different processors that communicate via it while the Dallas/Maxim one-wire protocol is somewhat proprietary.

I may have to think about whether I can manage a fifth line through that knee joint, then... I do like the general design of I2C, and having that clock line is nice 'cause the slave devices don't need to do their own timing to interpret or respond to a signal...

With regard to the slave devices, they'd all be PICs. I haven't seen anything about running PICs as one-wire slaves, though, so I guess I'd need to work it out myself. I can see how that would be a burden on a microcontroller with no direct hardware support for acting as a one-wire slave... <shrug> Well I'll give it the ol' college try anyway. :) For stop-motion, communication would mostly be happening in between still-frames anyway, so it's OK if slave controllers turned off the lights they're controlling while responding to one-wire data... But, on the other hand, if the PIC's UART can just handle I2C for me that may be reason enough to use that instead... <shrug>