Look for an RS485 tutorial

Hello,

I am working on a multiple-Arduino project, using a two-wire RS485 network. One Arduino will function as the master; the rest (as many as 10) as slaves. I have the hardware side of it set up with no issues, and I have a very primitive protocol in place to send data to the slaves. Ultimately, the master will send simple commands consisting of an address, a function, and presumably a checksum. The slave which recognizes its address will send an acknowledgement to the master, which will in turn send a trigger to process the initial command.

Are there any good tutorials out there which explain the fundamentals of this sort of protocol? I don't know where to begin on the checksum concept. Is there a standard method to go about this?

Thanks.

I did a bit of work on RS485 and a protocol here:

http://www.gammon.com.au/forum/?id=11428

Thanks, Nick... that looks incredibly helpful. I might hit you with some questions after I ingest it for a while.

Hmm another thing to think about is the Arduino's serial port support Parity bits, although the Serial library doesn't seem to let you set that up. Maybe one of the USART registers can be tweaked after "Serial.begin(xxx)" is run.

It also supports a fancy packet mode where one master can send messages to many slaves and slave Arduinos only report bytes if the address header matches their slave address. Doubt the Serial library supports that but who knows.

You’re not thinking of I2C are you? If not, link please?

Nope, USART...

ATmega48A/PA/88A/PA/168A/PA/328/P complete datasheet-- http://www.atmel.com/Images/doc8271.pdf

Page 204 (search "Bits 5:4 – UPMn1:0: Parity Mode") shows the register for adjusting Parity mode

Page 195 (search "Multi-processor Communication Mode") shows the packetized system I was talking about...

20.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.

20.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.

After reading that, I think it's time to play soon... and maybe extend the built-in HardwareSerial lib to support it...

Sounds like an interesting project. What they describe sounds similar to the I2C hardware ... the first thing it does is check the device address in the first byte.

However there is nothing stopping you having a protocol yourself where you send an address followed by data, with something like address 0 being "all do this".

In fact if you use the packet structure I described in my link, just make the first byte of the packet the address. Each device decodes the packet, and if not addressed to itself, ignores it.

I know this thread is a year old but the USART discussion sounded really interesting. Did anyone get anywhere with that?

Thanks,

Ad