MAX485 Software

[last updated: 2025-01-27]
RS485 home page
GMCGUI RS485 software - data packet protocol and data validation

-----

Hardware Control of send/receive:

• MAX modules send on their RO lines (Receiver Output), receive on their DI lines (Driver Input).
• They cannot send and receive at the same time, so you have to tell them what to do, through their hardware "direction control" lines, DE & RE
• DE is Driver Enable (for transmitting), and is active HIGH
• RE is Receive Enable, and is active LOW
• In all my projects so far, DE & RE are tied together and connected to an Arduino output pin. When the Arduino outputs a HIGH, sending is enabled and receiving is disabled; when the Arduino outputs a low to DE&RE, sending is disabled and receiving is enabled.
  • DE-RE-HIGH = send to bus;
    anything coming in to the MAX DI line from the Arduino is echoed out to the A/B bus lines

    DE-RE-LOW = receive from bus

    Whatever comes in to the MAX on its A/B bus lines from the bus is echoed to the Arduino out the MAX RO line
• I saw a forum note that if there are other masters on the same bus, then it might be useful to control these lines separately, but I have not investigated to understand how that might work.

-------------------------------------

SoftwareSerial library (built in to IDE) is used to communicate with the MAX module:

• Basic sketch code:

  • in globals:
    #include <SoftwareSerial.h>
    // Arduino pin definitions:
    const int RxPin = 4; // Serial Receive pin
    const int TxPin = 3; // Serial Transmit pin
    const int TxRxPin = 2; // forRS485 Direction control

    SoftwareSerial RS485(RxPin, TxPin); // Rx, Tx
    baudRate485 = 57600;
    byte byteRcvd;

  • in setup:
    pinMode(TxRxPin, OUTPUT);
    // (setting pinMode for TxPin and RxPin seems to be done in SoftwareSerial instance above)
    // Start the software serial port on RS485 bus
    RS485.begin(baudRate485); // set the data rate
    digitalWrite(TxRxPin, LOW); // Initialize MAX485 module as Receiver
  • convenient functions to define:
    void setTransmitMode () {
        digitalWrite(TxRxPin, HIGH);
    }
    void setReceiveMode () {
        digitalWrite(TxRxPin, LOW);
    }
  • in Loop: (for sending/receiving single bytes of data)
    // to send a byte to the bus:
    setTransmitMode();
    RS485.write(0x44); // send some arbitrary byte

    
    // to receive a byte from the bus:
    setReceiveMode();
    if (RS485.available()) { //Look for data from RS485 bus
        byteRcvd = RS485.read(); // Read received byte
    }

  • NOTE:
    In a real-world application, this minimal code may not work as is.
    Data signal timing considerations, packet design, and data validation protocols
    must also be taken into account to build a working system.

-------------------------------------

Packet configuration and Data Validation protocol:

Designing a working, real-world application requires making some key decisions up-front:
• To begin with, the RS485.write command only sends a single byte at a time.
  You surely can send longer messages (packets) by eg. putting the write command in a for-loop.
• So before you start writing your loop code to do the reads and writes,
  you must decide:
  • how many bytes will be in your message packets?
  • and how will you handle data-handshake/validation. That is:
    How will the sender know that its message was correctly received?
    One scenario:
    if sendDataCommand = true
    fetch/construct data to be sent
    send it
    get echo
    test echo - if bad, re-send x# times
    

• Packet Design/configurations:
  • How many bytes will a message/packet contain?
  • Assuming packets contain several bytes:
    • How will the Slave recognize the start of a packet?
    • How will the Slave recognize the end of a packet?
    • Will the packet contain any CRC or byte-count or other descriptors that can be used to validate the data?

• Data validation:
  Note: All these approaches involve the Slave sending something back to the Master after having received a message.
  As such they all require that the Master switches back to Receive mode after sending a message in order to hear the response/echo from the Slave.
  • One approach might be for the packet to contain some CRC or byte-count fields, and the slave would know the algorithm for computing them,
    and would do so after the packet is received, and compare its calculated parameters with those sent in the original message,
    and respond back to the Master with a simple success/fail code.
    In the Gammon code (link below), error checking is facilitated by having the master create a custom message to send.
    It starts with whatever data is intended to be sent, then processes it (calculates a 2's complement of the message), then adds that to the message.
    All very elegant and clever and presumably robust, but way over my ability to understand.
  • Another approach might be for the slave to wait to receive the entire message (as indicated by a recognized stop byte),
    then echo the entire message back to the Master, who would compare it to what it knows it sent and judge success/fail accordingly.
  • Another approach might be for the Slave to echo back to the Master after every byte in the packet.

  -------------------------------------

• Nominal/proposed Data Packet Configuration:
  • start byte ("\2")
  • destination node address byte
  • sending node address byte
  • message ID long int (?)
  • message size byte (? 255 max num chars?)
  • actual message
  • data check byte (CRC)
  • stop byte ("\3")

---------------------------------------------------

Programming ideas:

• Nominal/proposed program:
  • at default, node 00 owns bus
  • at all times, all nodes are listening:
    remote nodes are also constantly monitoring their sensors
    if they detect sensor activity that they must report,
    then they request bus ownership (how?)
  • the process of listening:
    if start code detected, start recording packet
    if addressee not for this node, stop recording
    if addressee is this node,
    record packet until stop code
    test CRC
    send response

• if a node needs to send a packet to the bus:
  • am I master?
    • if yes:
      listen and wait until bus is quiet
      put warning to bus that traffic is coming
      wait a moment then put your packet onto the bus
    • if no:
      listen and wait until bus is quiet
      send request for bus ownership

---------------------------------------------------

Reference:

• (link to:) wiki: RS485 bus communication Protocol
• github: https://github.com/nickgammon/RS485_protocol

.

.

.

eof