So these past couple weeks, I've been playing around with using my single Arduino to mess around with multiple little projects (Relay lighting control, 4bitLCD, 3x3x3 LED cube, etc), but the issue I'm somewhat running into is that most of these things require a serial connection to my PC to be of use (with what I want to do anyways)
So I've been considering getting some RBBB's, assembling a project on each, then somehow connecting them together via the serial pins.
Ideally, I would have some form of code on each arduino that sets an address, and a Processing script that will accept input from LCD Smartie as well as OSC commands(TouchOSC based lighting), as well as whatever else I end up running, sorting out the data into a single serial feed but with an address before each packet the designates which arduino it would go to.
The physical hardware arduino's would somehow be daisychained via the RX/TX pins and would only actually read/respond to packets designated for them.
I don't think that this is possible though.
The only logical way I've come up with to do this would be to have a separate "master" Arduino with 2-3 instances of SoftwareSerial running which accepts the serial data from the computer and forwards it to pins _ and _ (each "slave" Arduino getting it's own two digital IO pins)
Possible issues I see would be something like LCD smartie eating up the serial bus so traffic would somehow need to be managed... (The other applications I would use only send a single byte at a time) and I'm not sure if it's possible to define multiple virtual serial ports from within Processing, would probably need to find some form of library+driver combo.
Any suggestions or advice would be appreciated. This is still in an "early thoughts" stage and I'm not sure if I'm going to actually go for it, but it's an interesting thought.
You have run into the general network topology problem (that in fact was solved some twenty years ago, by many creative concepts) Read about networks, bus topology, token passing, layered network architecture, routing .....
Of course can you use a closed daisy chained ring! In fact I think this is the simplest solution; of course each node has to react to the input within 9600/bitrate *128 ms, if you do not change the buffersize of Seriasl. The main issue is, that one bad node will completely stop all communication.
You can also use I2C, or use its concept with the Serial lines, electrically however needing a tri-state option... This can be tricky... I should propose you take NewSoftSerial and change the two spots with the digitalWrite...
You will need (best) collision avoidance, or at least collision detection, depending on the amount of traffic you have. CD does not work well with a load>10%
The nodes will be spaced around my room(and probably all powered from the same supply), so if one goes down, rebooting shouldn't be too much a hassle.
Has this ever been done before with the Arduino? Is there any sample code/hardware layout that can be found anywhere?
I bought a large spool of 4-conductor solid core "security cable" for a different project, it's unshielded, but would it be able to sustain a 9600baud signal over 5-10 feet? or would the interference kill it?
But don't underestimate your project.. as far as I can see there are at least 7 hardware and software aspects you will have to study thoroughly before success
I think the simplest implementation would be to just have processing add a byte to the beginning of every packet that acts as the address that it's being sent to.
Then have each arduino do a Serial.read() and if the first byte is its ID on the chain, then it passes on the rest of the code to the actual program. If not it ignores it.
Would it be possible to just literally tie all the RX lines on the arduino's together, with the FTDI chip/computer being the only transmitter? Or would there be an issue of the signal being stretched out too much? The applications I'm currently thinking of only require one-way communication.
The alternative would be to have the FTDI send data to the hardware serial on the first arduino, then define a software serial to forward the data to the next one down the line.
Then have each arduino do a Serial.read() and if the first byte is its ID on the chain, then it passes on the rest of the code to the actual program. If not it ignores it.
You should be able to do some simple testing if you have another arduino. You might have one arduino act as the master/repeater for the other arduinos and the pc, or have the pc act as command and control for all arduinos. Using something as a command starter with *0, *1, *2, etc that is an identifier for each arduino. 5v has has its transmission limitations, but you should be able to connect several slave arduino rx pins in parallel to the master tx, and the master rx connected in parallel to the slave tx pins. The master could broadcast a command and then wait for the appropriate slave response. Would be something interesting to tinker with.
Then have each arduino do a Serial.read() and if the first byte is its ID on the chain, then it passes on the rest of the code to the actual program. If not it ignores it.
You should be able to do some simple testing if you have another arduino. You might have one arduino act as the master/repeater for the other arduinos and the pc, or have the pc act as command and control for all arduinos. Using something as a command starter with *0, *1, *2, etc that is an identifier for each arduino. 5v has has its transmission limitations, but you should be able to connect several slave arduino rx pins in parallel to the master tx, and the master rx connected in parallel to the slave tx pins. The master could broadcast a command and then wait for the appropriate slave response. Would be something interesting to tinker with.
If the FTDI chip doesn't put out enough power, I'm sure the pins could just be run through a transistor to amplify the signal.
The only issue I see with daisychaining like this is that data collisions of some sort are more than likely. Diodes would also need to be placed so you don't accidentally pump the signal from an TX pin of one Arduino into the TX of another.
Does anybody have any form of estimate on the range of a TTL serial feed if I'm running it through cheap 4-conductor security cable? It has zero EMF shielding.
Unfortunately, I only have the one Arduino for the time being.
I might go out and get another ATMega chip and put it on a breadboard just to see if I can get the communication working, but being a broke student I'm not sure when I'll be able to do it.
I'll be sure to document the project when I get around to it, this is definitely something that would be interesting for me to do. My current experience with the Arduino is just taking other people's code and mildly modifying it for my own use.
EDIT: I haven't looked into I2C, I'll look up some information on it and post back in a bit.
It uses one less wire for the coms, but from what I'm understanding looking at tutorials and stuff, you have to tie all the 5v and the grounds together anyways.
That's the problem I'm seeing with the idea of i2C, is that the master Arduino would need to process and convert the serial data from the computer to i2C. Which may cause problems with the LCD control library I'm using.
Sticking with UART might take a bit more coding up-front, but I think it'll make it easier to add nodes as the code on them won't have to be modified as much.
I think he means to say that you are not required to tie the grounds together, but every tutorial I've seen says tie the ground and +5 together regardless so I'm not sure.
