All AVRs (that i know of) have "Multi-processor Communication Mode" which is a hardware feature so the MCU can ignore serial data not intended for it when there are many serial devices on the same bus.
It uses an extra bit to indicate if a frame is an "address frame" or not. If the address matches the MCU it will receive all bytes until a new address frame comes along.
I've never actually used this feature but it looks quite useful for multi-node communications.
So to answer your question yes, you can have multiple serial devices connected together.
There's a few different ways to do it though....
If you plan to do multihost communications one of the first things you must specify is what they call the "access method". Put in simple terms, there are at least these simple alternatives:
- point-to-point where A and B communicate using separate data lines A -> B and B -> A
- single master, multiple slave where Master A communicates with a number of slaves 1...n. There is one transmit line from A -> 1...n and one receive line from 1...n -> A. This means that only A can hear 1...n and 1...n can only hear A. There must be a way to tell which of 1...n is the intended recipient. It can be done in hardware (chip select type thing) or an adress field in the frame header data. The latter means that all slaves must lift every frame at least until the address frame is received, to see if they must bother further.
- peer-to-peer partyline access method. Stations A...N communicate using a shared transmit/receive line (often RS485). There is no master/slave relationship. This option requires the use of a _media access protocol_. It can be implemented either in software or supported by hardware. I2C is a typical example. The idea is that any station is free to communicate with any other station. To do so it must somehow check that the media (line) is available an nobody else is transmitting. To do this you need some kind of _collision detection_ because it is always possible that 2 stations start a frame exactly at the same time. Usually the collision detection selects one station as the collision arbitration winner and it can continue while the loser withdraws and starts a resend delay. Classical Ethernet works this way as do many other shared media protocols. You probably do not wish to start from this alternative nor should it be necessary.
The human interface CLI is clearly point-to-point.
The inter-MCU link is most likely master/slave but reading your earlier posts it looks like you need to build in a master status renegotiation protocol in case you ever actually switch the roles. Or else plan how to restore the initial status outside the protocols. To clarify, the problem is this:
- somehow the 2 MCUs have been started "normally" and one is master, the other slave.
- the master crashes or something. The slave is supposed to be alerted by some mechanism and it assumes the role of master (doing the stuff the master did earlier)
- when the orignal master is restored there is a potential point of conflict. There is a new master in operation and the restored one should not barge in just like that because there will be issues. Instead the 2 MCUs should negotiate their new status somehow. I have been there and the strategy i suggest is to minimize the role changes. It works like this:
-- the unit that is master, stays master until it is shut off or crashes.
-- when a unit boots, it opens a link with its partner and arbitrates the startup role. If the partner is running it will indicate status of active master which would make the booting unit a slave. But if there is no response from the partner or it indicates problems, the starting unit assumes the role of master and communicates this to the partner. It is then supposed to revert to slave status.
Home
Help
Search
Login
Register
