Message Oriented Transmission

With version V2.0 support has been added for message oriented transmission through a transaction mechanism. To this purpose two new methods have been added to the HardwareSerialRS485 class. Note that these method calls have no effect if the RS485 transmission mode is not active.

void startTransaction(unsigned char priority=0x1f);
unsigned char endTransaction();

The method startTransaction() will: a) flush the transmission buffer, b) reset the buffer pointer and c) set the priority based minimum RS485 bus idle time needed before the next message may be transmitted. The method endTransaction() will flush the transmission buffer and return the completion status of the transaction.

If during a transaction, a call to write(), print() or flush() produces an error of any kind, then the complete message transmission is interrupted and retried sometimes later. Message retransmission is possible, provided that the full message is still inside the buffer. If the accumulated message length has exceeded the HardwareSerialRS485 transmit buffer size, the message can no longer be retried and subsequent message data will be discarded. The user is informed in this case through the return status of endTransaction() method, leaving it up to the user to decide whether to recreate and resend the message or not.

These two methods may be used by a more message oriented approach as demonstrated in the demo sketch. (n.b. the following code, extracted from the RS485CommandResponse demo sketch, has been simplified to better illustrate the idea)

inline void startMessage(unsigned char aPriority=0xff)
{
  if(isRS232Mode()) return;   // do not bother with message dressing-up if we are in 232 mode
  Serial.startTransaction(aPriority!=0xff ? aPriority:  myDefaultPriority);
  Serial.print('{');          // add start of message
  Serial.print(theHeader);    //
}
inline unsigned char endMessage()
{
  if(isRS232Mode()) { Serial.println(); return 0; } // do not bother with message dressing-up if we are in 232 mode
  Serial.println('}'); // add end of message
  return Serial.endTransaction();
}
//

On priority control: The above implementation allows a slave to control its message priority on a per message basis. This opens the possibility to boost its priority to the highest value (zero) in reply to a directly addressed request from a master. For unsolicited messages, the slave should still use is assigned priority. Note, to avoid possible collisions between slave replies, a master should always leave some idle time between two directly addressed (i.e. non broadcast) messages requests to different slaves.