Fun Project. Have 7 or 8 UNO/DUEs each doing their own thing independently. Looking to coordinate a few activities between them.
What I'm asking for are recommendations for the best Network/Comm Topology to apply to allow for some Supervisory Control, Distributed Control and Data Acquisition between the Arduinos. I will have special purpose shields on each UNO/DUE, so I need to adopt something that I should be able to apply universally to each 'Node' on my 'Network'. Some sort of Peer Networking recommendation, with perhaps an example.
I'm not ready to adopt any Galileo, Yun, Tre, Rpi technologies. Just want to go with what's available in the UNO/DUE community.
SPI has excellent speed and minimal I/O wires - also its non-blocking on the Due. I'm not sure what the top speed for SPI on the Uno is, but 4 MHz should be a match. The longer the interface cables are, the slower you'll need to set the SCLK frequency. The voltage difference on the I/O (5V Uno to 3.3V Due) would require an appropriate level shifter or buffer IC, no matter what communication interface you choose.
You didn't say whether the network was wired or wireless, pretty important aspect.
For wired solutions, I would do ethernet shield and a switch. Each unit assumes a fixed IP address and can exchange info using TCP. Plenty of flexibility.
For wireless solution, you can try xbee series 2. You need arduino wireless shield and xbee radio modules. The radios can be controlled to send to specific arduino.
You can try arduino wif shield too but it's a bit expensive. You will have all wifi shields connect to the same wifi router and assume their own address, outside the router's DHCP IP address range.
Two arduinos have motor shields. one has an lcd shield. one has a GSM shield...
So, I'll have to wrestle with sheild compatability issues if I put an Ethernet or Wireless shield on..
Haven't decided on a wired or wireless solution. Speeds not an issue, so even some kind of multidrop serial network would suffice. Just don't know of any such peer network protocols for Arduino.
(if only the DUEs had implemented the native Ethernet of the SAM3X chip and included a full PHY brought out as a RJ45 header...I'd migrate every Project to a DUE and connect them all via Ethernet.).
Yeah, but it always seems way over complicated and expensive for simple sensor-type nodes. Still maybe by the time you get your async network as reliable it will be just as complicated Still cheaper though.
Not likely, probably more like 1MHz, but that speed is seldom required for simple things, I doubt there's much a Uno could do that required 100MHz. Of course once you have Ethernet you also have the web which can be nice for projects and in fact is becoming more important as everyone wants remote control of their "stuff" over the IoT.
AFAIK with most (all?) small processors you still need a W5100 (or similar) and a magjack, that's a huge area of PCB real estate and not a trivial cost. Although I guess in this thread we floating the possibility of using a Due at each node, so those two points are probably moot.
if only the DUEs had implemented the native Ethernet of the SAM3X chip and included a full PHY brought out as a RJ45 header...I'd migrate every Project to a DUE and connect them all via Ethernet.
Maybe try the Taijuino (sp?) board, they have broken out the EMAC interface and I think have an Ethernet plugin board for it.
Rob,
I was part of the guys that tried with the Tiajuino. Guess, I should pick that effort up again.
I sent two of those boards down under like a year ago I think.
ZoomCat.. Yes I intend one to act as a master and the rest slaves.
I suppose a handful of Ethernet Shields is the way to go.... just need to work out the compatability with a couple of other shields, especially those that need the SPI.
ZoomCat.. Yes I intend one to act as a master and the rest slaves.
You could wire the master and slaves together via the serial pins and start experimenting with communication code. The master could continuously poll the slaves one at a time and retransmit one slaves data to another as needed. The master would control the communication request/response timing so there would be no overlapping data transfers.
I sent two of those boards down under like a year ago I think.
Yes I know, when we were designing the Toucan board. One sat next to my computer for ages but I just never got the time to try it out. BTW just about to get prototypes made for the Toucan's replacement, 8 bits though, not 32.