Can I use serial (TX/RX) to communicate between Arduino UNOs? I could not find any documentation stating otherwise, but also none to prove it works.
When searching it appears alot of people use SPI for the same purposes...
I understand SPI is way more powerfull and performant, but I only need to pass one byte every few seconds. That's whay I wondered whether it might be possible to do serial.write on one side, and serial.read on the other side, connecting TX to RX and vice versa and arranging a common ground. Distance would be about 2,5 meters, using quality twisted signal cable. Dropping the baud rate and having to write some fault tolerance to drop damaged values is no issue as I have plenty of time to get a single byte to the other side.
So, does it work, or does it have major disadvantages I did not think of?
I do not owe 2 arduino's (yet), so I cannot simply test (sorry for that :()
I think the USB/serial mixup does not matter in my case. I use the usb stuff only to upload my sketches and the final devices even have no need for USB at all.
with the use of the NewSoftSerial-library NewSoftSerial | Arduiniana, you can add software-based RX/TX to other digital output pins of your Arduino. So you can even connect multiple Arduinos with each other - or other serial devices, like GPS or a data logger. Works fine.
but remember that you can't use both the serial and USB features simultaneously
not quite true,
you can have N (>0) listeners simultaniously. I often have the USB and a Serial LCD in parallel while debugging.
you can have only one writer at the same time, otherwise the signals interfere. Leaves open a master - slave architecture. The master sends the id of the one allowed to send info to all, and only the slave with id responds (similar to I2C).
Another way to connect multiple Arduino's is a (token) ring, Arduino A sends to B, B sends to C , C to D, .... X to A.
A minimal packet looks like [FROM][TO][PACKETID][size bytes]
The algorithm is in short:
if the datapacket is not for you forward it to the next node in the ring.
The recipient removes the request from the circle and sends (optional) an ACK over the ring to the originator. [TO][FROM][ACK][PACKETID]
The originator removes the ACK from the ring.
To prevent deadlock and starvation one must at least forward one packet before one is allowed to send your packet (REQ/ACK) on the ring.
To prevent dataloss a CTS/RTS (ClearToSend/RTS) handshake is needed between the nodes.
One can also add a broadcast message: [FROM]- [PACKETID][....] to all nodes in the ring, e.g. [F|T|S|n|send sensor data]
It's a nice experiment to build such a network e.g. in the class, were every student has to design and implement one node....
For 2 Arduino's a network ring is overkill but if two arduino's connect there might come more
