Hi, and Thanks in advance!
Is anyone experienced is sending data between two or more arduinos? What's been your experience, most successful, longest range protocol?
Uart, SPI, I2C, CMOS, TTL, RS232, RS485....??
My project involves interactive consoles which each need to send data back to a macmini. We hope to have an seeeduino at each console, while employing a arduinoMega at a master station to send all data to the mac. Wireless or Ethernet communication are not likely based on our budget. Also, Wireless is out bc lots of emf interference is expected.
Thanks Again, Spacehippy Matt
longest range protocol
From your list that has to be RS485. It is a differential drive and you can go up to 500yards with it.
most successful,
That is down to the protocol and any error corrections you put it.
Uart is not a method of communication, it is an element involved in RS232 and RS485. The others SPI, I2C, CMOS are all signal level stuff for communicating on the same PCB.
TTY, can go a long way depending on the way you carry it. A 40mA current loop would be better than RS485 but then you would need something like a 180V supply to switch, which, no offence meant, given the original question, is way outside your league. Most UARTS won't support the 1.5 bit stop bit you need.
Did you mean TTL rather than TTY?
Given the presence of the words "Tesla" and "coil" in your title, can I suggest optical fibre?
Even something relatively cheap, using SPDIF parts.
That way, there's no copper between "dangerous end" and "expensive end".

Wow, thanks for the prompt responses. Yes, AWOL, optical fibre as a physical layer is definitely sounding most correct. As Grumpy_Mike pointed out, I mixed up a few these terms.
I did mean TTL. Is that the same as using serial.h?
Are there best practices for talking between arduino?
I looked into serial and it seemed I'd have to write a lot of code to synchronize messages so no one is talking at the same time. Can an Auduino read serial messages on any pins?
I guess the hope is that the distance could be added with a ttl-to-rs232 type circuit.
Thanks again!
I did mean TTL. Is that the same as using serial.h?
TTL just refers loosely to logic level serial comms, i.e. what comes off the AVR's pins without any buffering.
RS232 is buffered (inverted), and perhaps more importantly has both positive and negative swings.
The "soft" serial libraries allow serial comms on other pins, or the Mega has four hardware serial interfaces.
Yes, sharing serial lines over distances can be tricky.
Daisy chaining (in and then out on separate pins) is possible, at the expense of latency, and additional memory buffering.
You could use extra pins as address lines, or only allow particular devices timed slots.
Lots of ways to skin that cat.
AWOL, great explaination. Sry, I surely could've googled a bit more.
The "soft" serial library is exactly what I was hoping for. i can use any pins at the expense of processing. The tutorial asserts 9600 as a max for reliable.
is there a known breaking point where the std arduino cannot keep up with too many 9600 connections? would i be limited to those 4 "channels" on a mega? or can i still use the "soft" serial libraries?
The daisy chaining has a degree of elegance for covering the distance, but I just hate to add points of failures to where if any arduino goes "down" all are borked.
Using other pins as address lines is brilliant. Has this been done? Is there any supporting code/tut? It seems also very complex to manage, but it'd be interesting to look into.
thx as always, matt
The daisy chaining has a degree of elegance for covering the distance, but I just hate to add points of failures to where if any arduino goes "down" all are borked.
Not always a bad thing, from a safety POV, it could be indicative of a worse problem. Make sure you've got reliable timeouts to trigger everything to shut down in case you don't get any comms in a specified time period.
The address line idea is OK if you're not going to use optical fibre, otherwise it's a PITA to run lots point-to-point and regenerate.
Master/slave with addresses and half-duplex is probably the simplest/safest.
Otherwise, look at how networking technologies implement collision detection, and just accept a slower data rate.