I would like to understand how different busses (serial, sequential, parallel, etc...) work and I want to learn that on hand with Arduinos. I bought 3 Leonardos and when they will be there, I want to put them in series. I want to understand how data can be transmitted from the first one to the master and the Arduino in the middle shall be able to detect, that useable data was sent from #1 to the master and then also trigger an event (and also send data to the master as a next step).
Could you perhaps point me to a tutorial, where I can read into this topic? Would be really nice! I finally want to understand on a simple level how different busses work.
A bus is used for connecting many devices together.
Ironically the USB despite having Bus in its name is not actually a bus because it is a one to one communication protocol.
The difference between serial and parallel is that serial uses "time division multiplexing" to transfer the data where as in a parallel bus each data bit has it's own wire.
What I think you want to learn about is not buses but bus protocols. That is the way data is packaged up to ensure it is transferred correctly. It is probably best to study them from that point of view. As such look up I2C and SPI for a start. Wikipedia has good pages on these.
Grumpy_Mike:
Ironically the USB despite having Bus in its name is not actually a bus because it is a one to one communication protocol.
Actually, the USB is most accurately a "bus", but with a slightly different geometry to the way you are looking at it.
The USB as such primarily exists inside the computer at the root hub, which is quite equivalent to the ISA or PCI bus. It is just that when you extend it, you extend it as a tree - by adding hubs - rather than daisy-chaining as you (can) do for I2C. But without extensions, I2C shares exactly the same limitations - it also is a master-slave protocol whereby transactions occur only between slave and master according to the protocol. I seem to recall RS-422 (which might be the sort of thing of interest to Andreas' concern) is similar.
That is in comparison to Ethernet which is definitively peer-to-peer.
Ah a strange new usage of the word "accurately" to which I was previously unaware.
Oddly enough though the bit that 99.99% of people call the USB, that is the bit that you plug a device into, the bit that appears outside your computer, the bit that is implemented in hardware is not a bus.
Yes sure the concept is a bus, but concepts are not real. Just like the illusion of a desktop being generated on your output screen is not real.
I remember showing my son some experiments I was doing trying to get a user window running on a RISC OS machine. He had only ever used a Mac, since he was about 1 year old, he was 7 at the time. As I dragged my window round the desktop it uncovered part of the image I wanted to display as if this image was fixed behind the desk top and my window was tunneling through it to show what was behind it.
He though it was the best magic trick he had ever seen.
what pages do you advise me to read?
It can be very simple, but should include 3+ arduinos. On youtube I couldn't find videos that are explaining it in a good way.
It can be very simple, but should include 3+ arduinos.
No you will not find examples using three arduinos on line. That is the bit you have to do yourself once you read the Wikipedia page on the buss you want to study next.
holmes4:
All the above are serial. There are no built in parallel buses.
And there would be a reason for that - parallel buses are as you will note, "on the way out" in favour of USB, PCI express and SATA.
It is a matter of just too many connections involved, to say nothing of parallel data slew at the progressively higher transmission speeds.
The limitations of SPI, I2C and TTL serial are the distance between nodes and the possibility of ground differentials. Distance can be compensated to some extent by using lower speeds.
As to master/ slave vs. peer-to-peer, if you understand the protocols that are available, you can adapt them to peer-to-peer. It's a matter of implementing them first in practice, and getting sufficient familiarity with them to work outside of standard libraries and adapt. Research on "packet protocols" or "serial packet protocols".
There is a world beyond YouTube videos. Most of it in fact ...
I just do the first things with "wire" and i2c and my 3 leonardos.
Is it possible to communicate between master and one slave (id2) and the other slave (id3) listens and it can detect when id2 is transmitting to the master and already preparing stuff that is then transmitted to the master when it is his turn? And how do I do that?
I just do the first things with "wire" and i2c and my 3 leonardos.
Is it possible to communicate between master and one slave (id2) and the other slave (id3) listens and it can detect when id2 is transmitting to the master and already preparing stuff that is then transmitted to the master when it is his turn? And how do I do that
Basically not with the wire libary there can only be one master and a slave can only respond to a request from a master. It can not initiate a message sequence.
To do that you need a multi master libary.
You can do the first part but when a slave is not being addressed it does not listen.