Svenska ElektronikForumet

ok, detta måste ju vara väldigt enkelt.
dock har jag glömtbort hur koden bör se ut.
och mina google skills är inget att prata om

Multi-processor Communication Mode i databladet kanske? http://www.atmel.com/dyn/resources/prod ... oc2545.pdf

atmel.com/../doc2545.pdf - 8-bit Microcontroller with 8K Bytes In-System Programmable Flash.

Saxat:
17.9 Multi-processor Communication Mode Setting the Multi-processor Communication mode (MPCMn) bit in UCSRnA enables a filtering function of incoming frames received by the USART Receiver. Frames that do not contain address information will be ignored and not put into the receive buffer. This effectively reduces the number of incoming frames that has to be handled by the CPU, in a system with multiple MCUs that communicate via the same serial bus. The Transmitter is unaffected by the MPCMn setting, but has to be used differently when it is a part of a system utilizing the Multi-processor Communication mode. If the Receiver is set up to receive frames that contain 5 to 8 data bits, then the first stop bit indicates if the frame contains data or address information. If the Receiver is set up for frames with nine data bits, then the ninth bit (RXB8n) is used for identifying address and data frames. When the frame type bit (the first stop or the ninth bit) is one, the frame contains an address. When the frame type bit is zero the frame is a data frame. The Multi-processor Communication mode enables several slave MCUs to receive data from a master MCU. This is done by first decoding an address frame to find out which MCU has been addressed. If a particular slave MCU has been addressed, it will receive the following data frames as normal, while the other slave MCUs will ignore the received frames until another address frame is received.

17.9.1 Using MPCMn For an MCU to act as a master MCU, it can use a 9-bit character frame format (UCSZn = 7). The ninth bit (TXB8n) must be set when an address frame (TXB8n = 1) or cleared when a data frame (TXB = 0) is being transmitted. The slave MCUs must in this case be set to use a 9-bit character frame format. The following procedure should be used to exchange data in Multi-processor Communication mode: 1. All Slave MCUs are in Multi-processor Communication mode (MPCMn in UCSRnA is set). 2. The Master MCU sends an address frame, and all slaves receive and read this frame. In the Slave MCUs, the RXCn Flag in UCSRnA will be set as normal. 3. Each Slave MCU reads the UDRn Register and determines if it has been selected. If so, it clears the MPCMn bit in UCSRnA, otherwise it waits for the next address byte and keeps the MPCMn setting. 4. The addressed MCU will receive all data frames until a new address frame is received. The other Slave MCUs, which still have the MPCMn bit set, will ignore the data frames. 5. When the last data frame is received by the addressed MCU, the addressed MCU sets the MPCMn bit and waits for a new address frame from master. The process then repeats from 2. Using any of the 5- to 8-bit character frame formats is possible, but impractical since the Receiver must change between using n and n+1 character frame formats. This makes fullduplex operation difficult since the Transmitter and Receiver uses the same character size setting. If 5- to 8-bit character frames are used, the Transmitter must be set to use two stop bit (USBSn = 1) since the first stop bit is used for indicating the frame type. Do not use Read-Modify-Write instructions (SBI and CBI) to set or clear the MPCMn bit. The MPCMn bit shares the same I/O location as the TXCn Flag and this might accidentally be cleared when using SBI or CBI instructions.

17.10.2 UCSRnA USART Control and Status Register n A
* Bit 0 MPCMn: Multi-processor Communication Mode

Verkar som att det man ska skicka är:
Ett tecken address ; Valfritt antal tecken med data ; Avslut vid nästa address tecken.

Måste det vara just rx/tx (antar att du menar UART)? Annars borde t.ex. I2C fungera bra, du behöver två trådar och två motstånd.

Läs mer på:
http://www.i2c-bus.org/
http://www.nearfuturelaboratory.com/200 ... o-and-twi/
http://hacknmod.com/hack/how-to-connect ... using-i2c/
http://www.robot-electronics.co.uk/htm/ ... amples.htm

(från http://delicious.com/johan.adler/i2c -- du slipper googla)

Om det är på samma kretskort kan I²C-bussen möjligen vara en lösning, är det olika kretskort är den definitivt inte en lösning.

Problemet är (som vanligt) att koppla ihop 2 sändare till en mottagare, detta kan lösas på många sätt och varje scenario har sin lösning.

* Över hur lång sträcka ska denna kommunikation ske?
* Är det en specifik master med 2 slaver eller hur ser det ut?

Icecap skrev:Om det är på samma kretskort kan I²C-bussen möjligen vara en lösning, är det olika kretskort är den definitivt inte en lösning.

Varför skulle det inte fungera med I²C över tråd, mellan flera kretskort? Jag har inte provat själv än, men har uppfattat det som lite av tanken med I²C. Man pratar om TWI, two wire interface, vilket borde betyda just att man kör det över två trådar.

Twowire är lite missledande då du alltid måste ha med även nollan. Mellan kretskorten inom en apparat kommer det nog att fungera bra. Börjar man däremot köra I2C mellan apparater, speciellt med lite längre avstånd emellan, så börjar det bli problem. En fördel med asynkron UART-kommunikation är att det är lätt att öka avståndet med lämpligt gränssnitt, t.ex RS-485.

Varför skulle inte i2c funka på långa avstånd?
Kör man sakta så det inte spelar någon roll om ens fyrkats-kurvor blir rundade och använder 2 optokopplare på varje sida så man kan köra med tex 12V så är inte spänningsfall något problem och processorn blir bättre skyddad.

Edit:
Man får ju föst definiera långa avstånd, snackar vi 2meter eller 10mil?

Jordslingor, störningar och liknande ger ibland allvarliga störningar själv på korta sträckor. I²C är ytterligare med pull-up motstånd vilket gör att den bus är än mindre störokänslig.

Problemet är inte kommunikationssättet, det är termineringen av data och klocka som gör den intensivt olämplig till detta pga. störkänslighet.

RS485 är just till sån kommunikation men man kan även kommunicera i ring: 1 sänder till 2 som sänder till 3 som sänder till 1, på det vis måste data som går från 3 till 2 gå via 1 men det är inget större problem, det är bara lite programmering. Fördelen är att man kan ha multi-master, alla har alltså lika prioritet och varje enhet kan generera meddelanden utan att blockera busssen.

Ett annat förslag är att använda CAN (om processorn har stöd för det), då kan du ha flera enheter som skickar ut meddelanden, alla kan läsa, alla kan skriva. Ett annat alternativ är LIN fungerar väl ung som att du har en master och en el flera slavar. det går bara att skicka data direkt mellan en master och en slav men om man vill att 2 slavar ska prata med varandra måste detta alltid gå genom mastern.