Suggestions for connection two AVRs

Just a thought, if needing more pins or more flash or just for having a need to have two devices “talk” to each other, what do you guys think? I2C? Serial?
Let’s assume one AVR is in a box with an LCD and some buttons, maybe LEDs.
Another is farther away, controlling sensors, relays, whatever.
To have status messages displayed on the LCD from the other controller and send down command from buttons, a connection between the two would be required. Preferably two-way.

Serial might be simple as far as commands going back and forth, but most only have one U(S)ART available.
I2C may already be in use, complicating the whole setup.

Soooo… What do you guys think?

That’s OK, use the serial interface to communicate between the two.

What else would you need it for?

I am going with RS485 full duplex, and a management half duplex bus on the side. The idea is that it can be linked around my yard and is secure enough to allow bootloading to be initiated by a single host at any time. I plan to link several irrigation controllers through it to a single Nuc (or Pi) computer that will have a database and a garden expert. I need this to work without internet access, so the cloud is out.

Paul__B:
That’s OK, use the serial interface to communicate between the two.

What else would you need it for?

Thank you, Paul. Good point, even if i want to monitor it using the uart, communication can still work between the two.

ron_sutherland:
I am going with RS485 full duplex, and a management half duplex bus on the side. The idea is that it can be linked around my yard and is secure enough to allow bootloading to be initiated by a single host at any time. I plan to link several irrigation controllers through it to a single Nuc (or Pi) computer that will have a database and a garden expert. I need this to work without internet access, so the cloud is out.

Neat. Rs485 is TWI/I2C, right? That looks like a scalable solution. I really only need two, so I will probably stick with serial.

Thank you for posting.

somedude: Rs485 is TWI/I2C, right?

no. rs485 is exactly the same as rs232 except differential and multidrop (needs 3 pins). it is far more expensive and complicated and only makes sense for long distance. i have implemented a much simpler version of inter-chip comm also using rs232 but single wire (poor mans rs485). cheap, fast, use any pin, and allows unlimitied multidrop.

bottom line: for long distance (ie 1 mile) rs485 is the standard, for talking to i2c device use i2c, for inter-avr protocol 1 wire asynch makes most sense.

john1993:
i have implemented a much simpler version of inter-chip comm also using rs232 but single wire (poor mans rs485). cheap, fast, use any pin, and allows unlimitied multidrop.

for inter-avr protocol 1 wire asynch makes most sense.

Hi john1993, Could you please tell us how to do the poor mans rs485 with multidrop using a single wire? I would like to experiment with that and connect several Arduinos.

I2C is only good for a few meters and has almost no noise immunity so it probably should not be ran outside an enclosure and expected to be reliable. 5V (TTL) level RS232 is really not much better than I2C once outside an enclosure, so expect lockups and bad data. The chips that convert TTL RS232 to actual voltage specifications are not cheap, so I do not think RS485 is more expensive. Also, RS232 struggled to reach across my yard (35 meters) and still be reliable, so I had to start looking at RS485.

At some point, I found this board from Sparkfun: http://cdn.sparkfun.com/datasheets/Dev/Arduino/Shields/RS485_schematics.pdf

And that really got me thinking and studying it. So with two wires the bus can be controlled, but the key is to use a chip that has fail-safe biasing built in (I use ISL3172 & ISL3152). This is when things start to get a little deep, but it is worth understanding. The fail-safe simply means the differential bus is seen by all devices on the bus as being in a defined state if no device is driving the bus, that state is high or true. Since the TX defaults to high it can be used to disable the driver, and suddenly it acts like an undriven bus with a defined state, sort of like I2C (it is still not I2C thought). Now anyone can talk on the bus, but only one at a time.

dmjlambert: Hi john1993, Could you please tell us how to do the poor mans rs485 with multidrop using a single wire? I would like to experiment with that and connect several Arduinos.

it uses the same timing as regular serial except only one wire which is tristated when not sending. software is also very simple using master slave (speak only when spoken to) protocol. up to 128 slaves in most cases although i have personally never needed more than a dozen or so hooked up at once. master can be a pc or another arduino.

example: first byte sent by master is always id (address). slaves fetch their unique id from last ee location. with bit 7 of id set and another byte (data) sent then slave writes that to a port. if clr then slave reads an input port and returns that data byte to master.

generally most implementations dont need full 128 slaves so certain id byte combinations can act as special commands: ie ff means ALL slaves read, 7f means ALL slaves write, etc. if you need more info just ask and if anyone really wants to experiment i might be able to put up a file.

I am highly interested, and I would love it if you would put up a file. Thanks.

Please pretend I'm a newbie and give lots of details (because I am when it comes to this subject).

Note that whatever applies to one modality over distance, applies to all. Whether RS-232 or RS-485, you send any data of importance in "packets" with synch markers, length and checksum with a resend request protocol.

Thanks everyone for the interesting dialogue.

Sounds like I might be able to pull it off with serial since I only need a few meters between the two.

dmjlambert:
Please pretend I’m a newbie and give lots of details (because I am when it comes to this subject).

actually this can be quite the beginner project depending on how fancy you want to get. iirc it took less than an hour to get a first version running yet proved to be of practical use for many applications over the years. the key is “walk before you run” approach aka “progressive iteration”:

project #1:
using standard arduino uno or promini setup make sure you can send a single serial byte from the arduino monitor and have it output to digital pins. the led comes in handy here and should make this a tit job.

project #2:
implement two byte scheme prefacing the id byte described earlier. initially a hard coded number in master and slave. then maybe add the read from port and send back to master function. still just one slave with fixed address hanging off a pc making it easy to work out these parts of the protocol.

project #3:
go to multi-slave arrangement maybe try putting the id in ee at this point too instead of hard coded. also a good time to try hooking up more than one slave and get that running.

project #4:
if like somedude you want to go arduino-to-arduino instead of pc then throw together a program for a master chip. this is trivial compared to slave program because all you are doing is sending out bytes and complexity really depends on the application. remember kiss and “walk before you run” and it should be a cinch.

for instant gratification ive attached a hex file using protocol similar to that in post #7. originally created for mega8 it uses pb1 for rx and puts up the byte received on portb. at 16mhz the baud is 57kbps and at 8mhz (no xtl) 28.8kbps. a newly flashed chip will have ff in the last ee location so any id will work. for example entering any key then ‘c’ turns pb5 led on and any key then ctl-c turns off.

this same file works on tiny13, t25, t85, t24, t46/461, mega8515, and probably dozens of other avr that have “classic” io map.

even though the program is only a couple dozen bytes in size its been used for applications ranging from holiday lights to industrial wire factory installation. there is a mega328 version floating around here somewhere and i will try to find if theres interest. m8 is my goto chip so was easy for me to read one and post.

multi802.hex.txt (284 Bytes)