multi-master system

[EVblog1]

As per my understanding, UART is designed for point-to-point communication, with one transmitter and one receiver. If multiple devices try to transmit at exactly the same time, UART itself does not have any mechanism to perform arbitration and decide which transmitter should get access to the communication line.

I think the same is true for SPI. SPI does not define a bus arbitration mechanism for multiple masters. If two or more masters try to communicate with the same slave at the same time, there is no standard SPI mechanism that decides which master should control the bus.

So, directly, I don't see how standard UART or SPI can handle arbitration when multiple devices start communicating at the same time.

However, I have read in some places that this problem can be solved by adding additional hardware logic.

Does this mean that arbitration is not supported by standard UART and SPI, but we can add external hardware logic to control access to the bus and therefore make a UART or SPI-based system behave more like a multi-master system?

Am I understanding this correctly?

[nctnico]

This a though subject. UART can be (and is) used for multi-drop systems where serial data from a UART is transmitted over RS485 (for example). But extra logic (like message acknowledgement) is necessary to make sure a message actually made it to the sender. One trick to detect a collission is to read data back from the bus and if that is different than what is being send, stop. But that doesn't reliable work on long RS485 segments. The series resistance of the wires is high enough for a transmitter on both ends to push it's own data on the bus and reading their own data back without error.

SPI is point to multi-point by design as far as I know.

A CAN bus is much more suitable for multi-drop communication systems.

[pcprogrammer]

SPI makes use of a select line in many cases. That is why you see for instance in the STM32 SPI peripherals the NSS signal besides the SCK, MOSI and MISO signals. This select signal is intended for enabling a slave and multiple of these select signals are needed to address multiple slaves. A lot of the slave devices also make use of the select line to fence of communication boundaries. Like when the select goes low the device state is reset to receive a command word followed by additional data, and as long as select remains low it stays in the data state.

If I remember correctly I have read something about multi master with SPI, but can't recall where and how it is done. Maybe a google or AI search can shed some light here.

UART in its basis is absolute a point to point setup, but like nctnico wrote it can be used in a bus configuration by using for instance RS485, but within the data layer care has to be taken of handshaking and acknowledge.

[Doctorandus_P]

I agree. Bus arbitration is not part of standard uart or spi.

I have set up my own "home network" based on uC's with uart and RS485 drivers and collision detection does indeed not work. Even with about a meter of cable in between, each RS485 driver just reads it's own data back.

Collision avoidance does work, and is what I apply. I have my network setup as a multi master bus and packetized the data (16 bit adresses, 16 bit CRC and some extra bits in the header. When a node wants to send data, the send routine first monitors the RS485 line for a time that is longer then a byte. So if any other node is sending, it detects this and backs off for some time. If nobody is sending, then it enables the RS485 driver and starts sending as quick as possible This way there is around a 100ns period in which there is an opportunity for more then one node to grab the bus, and thus cause a collision. (This may increase for long cable runs as the delay on the cables may become a factor). This works "well enough", but it's not error free. I once did a test by sending over a million packets in around half an hour, and in that time I had nodes backing off a few times (so that part worked), but I also had 3 or 4 damaged packets.

CAN transceivers do have a "dominant" and "passive" state, and with that you can do reliable collision detection. I did not use CAN back then, because I don't like the weird addressing scheme and the small packet size. But you can use CAN transceivers connected to an UART. But a UART does not have collision detection hardware, and thus it would require extra hardware to do this. For example with an XOR port on the CAN transceiver, a filter, and maybe a bit more (Have not thought about details).

My system also does (mostly) automatic resends of packets if no answer is received within a certain timeframe. This mitigates the effect of lost packets, but it also introduces the problem that the response can be damaged, resulting in two valid packets received by the "remote node". Whether this is acceptable depends on how data is formatted. With "turn a relay on" it's not a problem, but with "toggle a relay on/off" it is a bigger problem.

Another software mechanism is to have a node to handles the arbitration. You can implement something like token ring, in which a special packet is passed around, and the node who last received the packet (microphone?) may speak. But this also requires a mechanism for when that special packet is lost. (It can for example respawn after a set amount of time).

A multi master bus is also by definition half duplex. This requires a way to connect RxD and TxD of a uart together (for example with the RS485 driver chip). When the TxD is always active, different nodes can be separated by diodes on the Txd line. This transforms it into a wired or (Or better: wired AND, as TxD is high in idle state) Some uC's have built in options to combine RxD and TxD of the uart into a single signal. (Also look up LIN bus).

--------------------
SPI is another monster.

If you have a multi drop bus, then you don't know which one is master, and who is the slave. So which line is MISO and which is MOSI? And how do you want to handle the slave select line(s)?  Usually SPI leaves a lot of options open (such as clock and data polarity). As it happened I had a chat with one of those AI bots last week about setting up a multi master bus with SPI for STM32. And apparently it can work when you do the programming carefully. The (finally suggested) setup was:

• Ignore MISO. The bus uses effectively only half duplex.
• Everybody shares the slave Select line.
• Everybody is slave by default.
• When a node wishes to become a master, it first checks for the idle SS line. (Backs off if the bus is busy).
• If the bus is free, it grabs the bus by pulling SS low. (It's possible two nodes grab the bus at the same time!)
• When SS is low, it waits a bit of time depending on "node priority".
• During this time (A bunch of us) it polls the SCK and MOSI lines in a tight loop.
• If activity is detected, the node backs off, (also releases SS, the "other master" keeps SS active during the transaction).
• If no other master is detected in this time, the node starts sending.

This scheme is "pretty good", but still not completely fool proof. So adding checksums and resend mechanisms is still advisable.

If you're interested in networking, I also recommend the Tanenbaum book about networking / internet. With a more elaborate network waiting for a response for each packet introduces far to much latency. Therefore the "master" sends multiple packets in a row, and then later sorts out which packets got received and which have to be resend. This also introduces an extra problem of packets getting received out of order.

I2C is also an interesting bus. The specification supports multi master node (And Philips / NXP has nice application notes about the protocol). In practice many implementations of I2C are not complete, and multi master is not always implemented, or leads to faults. I don't have enough experience to know more about details here.

[Unixon]

I have set up my own "home network" based on uC's with uart and RS485 drivers

BTW, is there an implementation of Ethernet like network, but using RS-485/RS-422 P2P links and MCU UIDs (or UID ICs like DS2411) instead of MAC addresses and reduced datagram (shorter) packets suitable for processing by small micros like middle range AVRs.

[nctnico]

I have set up my own "home network" based on uC's with uart and RS485 drivers

BTW, is there an implementation of Ethernet like network, but using RS-485/RS-422 P2P links and MCU UIDs instead of MAC addresses and reduced datagram (shorter) packets suitable for processing by small micros like middle range AVRs.

I made something like that 15+ years ago. Basically ethernet over RS485. Worked OK but the downside is that you really need to filter unwanted traffic. The main problem where Windows machines on the network spitting out tons of broadcasts which then would choke the RS485 network segment. IIRC I used a heavily modified (fortified) uIP stack. I can't share the code though.

[Unixon]

I made something like that 15+ years ago. Basically ethernet over RS485. Worked OK but the downside is that you really need to filter unwanted traffic. The main problem where Windows machines on the network spitting out tons of broadcasts which then would choke the RS485 network segment. IIRC I used a heavily modified (fortified) uIP stack. I can't share the code though.

Well, it's almost like Ethernet over RS485, but I thought it couldn't be compatible with normal Ethrenet and shouldn't be made compatible and I didn't intended to bridge them.
Can you tell in more details about design decisions?

[nctnico]

I made something like that 15+ years ago. Basically ethernet over RS485. Worked OK but the downside is that you really need to filter unwanted traffic. The main problem where Windows machines on the network spitting out tons of broadcasts which then would choke the RS485 network segment. IIRC I used a heavily modified (fortified) uIP stack. I can't share the code though.

Well, it's almost like Ethernet over RS485, but I thought it couldn't be compatible with normal Ethrenet and shouldn't be made compatible and I didn't intended to bridge them.
Can you tell in more details about design decisions?

Basically the idea behind it was to make IoT-ish nodes accessible from an ethernet network without needing a very complicated protocol translator in between. Keep in mind that ethernet defines the packet (frame) layout, not the physical layer. IOW: you can run ethernet on any physical layer you like for as long as you adhere to the packet format. On top you can run whatever protocol can run on top of ethernet.

[Unixon]

Keep in mind that ethernet defines the packet (frame) layout, not the physical layer. IOW: you can run ethernet on any physical layer you like for as long as you adhere to the packet format. On top you can run whatever protocol can run on top of ethernet.

Yeah, I know this. In my view of this communication system the original Ethernet package format was the problem, it's fine overall, but for MCU based system field lengths and content would be different.
I'm stuck at figuring out what parts of IP stack I should implement and how, then I dropped out of the process of thinking it through due to lack of spare time, but I still need to figure out this micro-Ethernet.

[Kilrah]

At this point if you do need a real network any decent MCU can handle real Ethernet directly.
Not an AVR, but you wouldn't want to use an AVR for anything anymore...

And yea one step down if you don't want a master, CAN's easy too. Makes no sense to try to coax UART/SPI into doing stuff it wasn't designed for, enough other options around.

[Unixon]

You're probably was replying to OP, but I forked this thread. 

At this point if you do need a real network any decent MCU can handle real Ethernet directly.

I just remembered one thing about it, one of additional and important reasons for making/leaving my RS485 micro-Ethernet incompatible on packet level intentionally was to isolate it from macro-Ethernet so it could not be discovered and interacted with using standard protocols. Other than this, yeah, just get an MCU with Ethernet and Bob's your uncle.

Not an AVR, but you wouldn't want to use an AVR for anything anymore...

Well, they are still pretty good for controlling relays and reading simple sensors and they are so simple that even Wiring is still passing as a HAL 

And yea one step down if you don't want a master, CAN's easy too.

With CAN everything has to be preprogrammed and this does not fit a network where new devices may pop in and out.
Ethernet is great in this regard as there must be a capability to discover devices and reconfigure network dynamically.

[EVblog1]

SPI is point to multi-point by design as far as I know.

As I said, SPI supports one master and multiple slaves. But if we add additional hardware logic to implement arbitration, can SPI then be used as a multi-master, multi-slave system?

[Psi]

SPI is point to multi-point by design as far as I know.

As I said, SPI supports one master and multiple slaves. But if we add additional hardware logic to implement arbitration, can SPI then be used as a multi-master, multi-slave system?

I think that would be additional software logic to hand-off being the master to another device based on some rules, rather than hardware.

Maybe extra hardware could be used to detect if two devices try to be master at once, but there's no reason that should happen if they all follow the rules. It would be to handle a faulty/corrupt device, or a bad communication link where data is being lost.

There's probably an infinite number of ways to implement a multi-master system in SPI because the core protocol is very simple. So its really down to what tradeoffs you want and that would point you in a particular direction for how to implement it.

You could, for example, join all SPI's in a big daisychain configuration and pass along a token that controls who is the master.
But it's prone to one device taking out the entire loop if it's disconnected, and you need a software mechanism to detect and re-issue a new token if, for any reason, it gets lost. And you have the lag of waiting to get the token, and the constant SPI traffic as the token is passed around. So this way of doing it isn't very good.

For UARTs some MCUs have a multi processor mode where you can use the 9th bit for address info. The MCU can ignore the bus until it gets a special frame that contains address info. It prevents the MCU having to process interrupts for all frames including ones that are for another MCU. It can sleep until it see's an address frame for itself.

[EVblog1]

I think that would be additional software logic to hand-off being the master to another device based on some rules, rather than hardware.

Without any additional hardware, I don't see how this would work. I mean, what happens when two masters start sending data at the same time? How would SPI decide which master gets control of the bus in software?

[Psi]

I think that would be additional software logic to hand-off being the master to another device based on some rules, rather than hardware.

Without any additional hardware, I don't see how this would work. I mean, what happens when two masters start sending data at the same time? How would SPI decide which master gets control of the bus in software?

You don't switch masters until all slaves have received and confirmed the switch is going to happen, or you keep time sync and slice up time so each MCU has a period where it can be active and all others wont be.
I guess it depends exactly what you mean by multi-master.   
Do you actually want to have multiple masters active and transmitting at the same time without interfering with each other?  Or do you just want to change who is the master when needed? 
If the latter then you just have to use a system to make sure everyone else on the bus know about the change and when it will occur.

[westfw]

For a moderate-distance (25m for multi-drop) multi-master system in this day and age, you should probably be looking at the new "Single Pair Ethernet" devices.  Ethernet is, after all, highly standardized and there are all sorts of standard OTS devices (repeaters, bridges, switches, routers) for interconnecting it with ... anything.
Use IP and you can communicate with devices on the other side of the world.  (bare UART to IP bridges are common items, down to the ESP8266 modules that allowed Espressif to catch everyone's attention.  Somewhat more complex devices give you IP over UART (SLIP or PPP)) (and many low-end ethernet Mac+Phy implementations can be accessed via SPI.  Bit of a bottleneck, usually.)

Yes, IP over ethernet is quite a bit of "complexity load", especially at the SW level, but I think you'd be looking at similar comlpexity trying to adapt other technologies (like SPI or I2C) to the sort of topology you seem to be aiming at.  And in those case, it would be your work; likely incompatible with anything else.

[Fire Doger]

I think that would be additional software logic to hand-off being the master to another device based on some rules, rather than hardware.

Without any additional hardware, I don't see how this would work. I mean, what happens when two masters start sending data at the same time? How would SPI decide which master gets control of the bus in software?

@Doctorandus_P way can definitely work, they don't "just start transmitting", they claim the bus via the cs line. If you also add a different hardcoded "time before talk" after cs pulling, then there is no way to collide (if proper separation is maintained). For example IC1 has 10t, IC2 has 20t, IC3 has 30t

If IC1 & IC2 pull the cs line simultaneously, IC1 will wait 10 before start talking, IC2 will wait 20.
Based on that prioritization, IC1 will start talking at 10, then IC2 will detect that someone else is talking and will reschedule it's transmission for later ...

If IC2 pulls the cs line before IC1 then its clear that IC1 has to wait for whoever pulled the cs line (IC2 in this case).
When cs line is free then IC1 will pull it, wait 10, and if no one spoke during that period he must start transmitting.

10, 20, 30 are time units, it depends from the slowest IC how fast it can switch from reading the CS line to pulling it low, you need a robust separation.
Also after t passes for a device its very important to not waste time and start transmitting. In above example, after 10t passes, if IC1 needs plus 50t to start talking, then there is no way for IC2 to detect it amd it will also start talking.

[JPortici]

SPI is point to multi-point by design as far as I know.

As I said, SPI supports one master and multiple slaves. But if we add additional hardware logic to implement arbitration, can SPI then be used as a multi-master, multi-slave system?

why would you do that?
just use something that can be multi-master (like I2C, though it's going to be fun) or drop the "master" thing completely by using CAN, ethernet and whatever other protocol that knows how to share a bus with more than 2 nodes. With CAN, if you implement CAN-TP (it's in the standard.) you can have 4096 bytes packets, or more if you use CAN-FD (and even more for CAN-XL)

[fchk]

For a moderate-distance (25m for multi-drop) multi-master system in this day and age, you should probably be looking at the new "Single Pair Ethernet" devices.  Ethernet is, after all, highly standardized and there are all sorts of standard OTS devices (repeaters, bridges, switches, routers) for interconnecting it with ... anything.

Exactly. And not any SPE since there are many of them. You neeed 10Base-T1S (IEEE 802.3cg). This is the multi-drop variant. All other types are strictly point-to-point and require switches like regular RJ45 Ethernet.

Microchip has NICs and PHYs:
https://www.microchip.com/en-us/products/interface-networking-connectivity/ethernet/single-pair-ethernet/10base-t1s

This is a SPI MAC&PHY:
https://www.microchip.com/en-us/product/lan8651

[rf-fil]

@EVblog1, are you AI? You're just bombarding this forum with weird questions..

[free_electron]

I2C. Hardware collision detection and arbitration. no corruption. whoever drives the bus low wins , the other one backs off.
designed to be multimaster form the get-go

[Psi]

@EVblog1, are you AI? You're just bombarding this forum with weird questions..

Quillbot and Solvely think it's likely AI.  72% and 66%

[JPortici]

@EVblog1, are you AI? You're just bombarding this forum with weird questions..

finally somebody asked. I was always reluctant to reply to this member's threads.

[EVblog1]

I’m a test engineer with 2 years of experience, and I’m working toward moving my career into embedded software development. I’m exploring different embedded topics, buying components and boards, and doing hands-on experiments in my free time because I want to actually learn and practice for interviews.

As I’ve said in my other threads, if you don't want to answer my question or participate in the discussion, that's completely fine. You can simply ignore the thread and move on. You are not required to reply. But repeatedly trolling someone simply because you don't like the question is unnecessary.
I also don't believe there is such a thing as a "good" or "bad" question. A question is a question. Some may be basic, some may be unusual, and some may be poorly framed. If you think mine is technically wrong, then point out what is wrong and I'll be happy to discuss it. That's what a technical forum is supposed to be for.

And honestly, I’ve even seen people in my own threads simply paste AI-generated content as answers. I don't have a problem with people using AI as a tool, but I find it ironic that asking questions and trying to have an actual discussion is being treated as a problem.

Experienced members were beginners once too. If every new person gets mocked for asking questions that someone considers unusual, don't be surprised when new people stop asking questions and stop participating.

[Psi]

AI content isn't the issue directly, neither is users asking beginner questions.

It's that niggling sensation you get when you're just not sure if the thread you're reading and taking time to post in was made by a human or if it's purely an AI bot trying to train on the answers of humans. If it's obviously a bot then it's easy to ignore it, but when it's not obvious it gets under peoples skin when a thread/post makes you feel like there's even a 1% chance the thread is a bot wasting your time.

The sad thing is, people who don't have English as their first language can sometimes say things or type things in odd ways that makes others suspicious that it's a bot when it's not. And obviously a human using AI to reword their thread question has the issue too.