AVR USART Multi-Processor Mode

decided break out of thread first mentioned (http://arduino.cc/forum/index.php/topic,101823.0.html)

apparently hardware serial port has mode single-master, multiple-slave communication available using filtering system helps slaves ignore incoming i/o destined different slave.

atmega48a/pa/88a/pa/168a/pa/328/p complete datasheet-- http://www.atmel.com/images/doc8271.pdf
page 195 (search "multi-processor communication mode"):

quote

20.9 multi-processor communication mode
setting multi-processor communication mode (mpcmn) bit in ucsrna enables filtering
function of incoming frames received usart receiver. frames not contain
address information ignored , not put receive buffer. reduces
the number of incoming frames has handled cpu, in system multiple
mcus communicate via same serial bus. transmitter unaffected mpcmn
setting, has used differently when part of system utilizing multi-processor
communication mode.
if receiver set receive frames contain 5 8 data bits, first stop bit indicates if frame contains data or address information. if receiver set frames with
nine data bits, ninth bit (rxb8n) used identifying address , data frames. when
the frame type bit (the first stop or ninth bit) one, frame contains address. when the
frame type bit 0 frame data frame.
the multi-processor communication mode enables several slave mcus receive data a
master mcu. done first decoding address frame find out mcu has been
addressed. if particular slave mcu has been addressed, receive following data
frames normal, while other slave mcus ignore received frames until another
address frame received.

20.9.1 using mpcmn
for mcu act master mcu, can use 9-bit character frame format (ucszn = 7). the
ninth bit (txb8n) must set when address frame (txb8n = 1) or cleared when data frame
(txb = 0) being transmitted. slave mcus must in case set use 9-bit character
frame format.
the following procedure should used exchange data in multi-processor communication
mode:
1. slave mcus in multi-processor communication mode (mpcmn in
ucsrna set).
2. master mcu sends address frame, , slaves receive , read frame. in
the slave mcus, rxcn flag in ucsrna set normal.
3. each slave mcu reads udrn register , determines if has been selected. if so,
it clears mpcmn bit in ucsrna, otherwise waits next address byte ,
keeps mpcmn setting.
4. addressed mcu receive data frames until new address frame received.
the other slave mcus, still have mpcmn bit set, ignore data frames.
5. when last data frame received addressed mcu, addressed mcu sets
the mpcmn bit , waits new address frame master. process
repeats 2.
using of 5- 8-bit character frame formats possible, impractical since the
receiver must change between using n , n+1 character frame formats. makes fullduplex operation difficult since transmitter , receiver uses same character size setting. if 5- 8-bit character frames used, transmitter must set use 2 stop bit
(usbsn = 1) since first stop bit used indicating frame type.
do not use read-modify-write instructions (sbi , cbi) set or clear mpcmn bit. the
mpcmn bit shares same i/o location txcn flag , might accidentally be
cleared when using sbi or cbi instructions.

so gather, have master , slaves set use 9-bit serial mode, uppermost bit (bit#8) set indicate address info , cleared indicate data info.  with mpcmx set on slaves, bother taking in data , interpreting if bit#8 set, each slave can read incoming data (meant address frame, multiple bytes guess) , determine if wishes listen rest of data (coming in bit#8 cleared); long mpcmx set, incoming bytes bit#8 cleared ignored.

the intended slave, though, having seen address sent in sequence of bytes bit#8 set, clear mpcmx bit usart take in & notify running sketch/firmware of inbound data.

this continues on indefinitely until address frame (1+ bytes bit#8 set) sent.  seems me useful supporting rs-485 multidrop networks!  but arduino's hardwareserial library doesn't directly support it, although bet wouldn't hard @ work around that...

actually on note, here's brainstorm of how you'd handle master & slave sides while continuing use serial.* functions on atmega328p:
(note have not tested code @ all!! ... might later when i'm @ workbench)

master

code: [select]


void setup() {
 serial.begin(9600);
 ucsr0c |= (1<<ucsz00) | (1<<ucsz01) | (ucsz02);  // character size = 9-bit
}

void loop() {
 // send address frame
 ucsr0b |= (1<<txb80);  // set bit#8
 serial.write(0xf8);  // send address (in example, single-byte 8bit number);
 ucsr0b &= ~(1<<txb80);  // clear bit #8
 // bit#8 cleared, further bytes data , slave not responding address 0xf8 should ignore these
 serial.println("hello world!");
 delay(1000);
}


slave

code: [select]


#define our_address 0xf8

void setup() {
 serial.begin(9600);
 ucsr0c |= (1<<ucsz00) | (1<<ucsz01) | (ucsz02);  // character size = 9-bit
 ucsr0a |= (1<<mpcm0);  // enable multi-processor slave mode; address-frame bytes read
}

void loop() {
 char buf[64];
 int i;

 while (!serial.available())  // waiting call...
   ;
 if (our_address == serial.read()) {
   // we've been called!
   // clear mpcm0 we're listening data bytes
   ucsr0a &= (1<<mpcm0);
   // ordinarily @ point we'd need way determine when master done sending us, can raise mpcm0 again?
   // simple example i'll read whatever comes through on course of 250ms, put mpcm0 up.
   // proper example have "end-of-frame" byte embedded in protocol somehow.
   delay(250);  // give serial library time stuff buffer incoming contents
   i=0;
   while (serial.available())
     buf[i++] = serial.read();
   buf[i] = '\0';  // null-terminate buffer
   // buf (can't print screen, we're using usart!)
   // ...

   // raise mpcm0
   ucsr0a |= (1<<mpcm0);
 }
}


i guess point of ambiguity in datasheet happens slave mpcm0 disabled if master sends address frame (bit#8 set)?  does receive it?  maybe that'd way signify end-of-packet -- address frame sent value 0x00, no slaves respond address "called" slave see signal stop reading & processing data , raise mpcm0, going "waiting called" mode.

to make work reliably need access isrs both tx , rx.

Arduino Forum > Using Arduino > Networking, Protocols, and Devices (Moderator: fabioc84) > AVR USART Multi-Processor Mode

arduino