RS-485 Library

Here is a page devoted to the RS-485 BoSL implementation library.

The BoSL RS-485 Bus library creates utilities to abstract the use of the RS-485 Bus hardware RS-485 It facilitates the communication of use of multiple sensors over one RS-485 line to ensure that clear communication is achieved and no bus collisions occur. The library is set up to be easily added to an existing sketch code see the annotate examples for inspiration. A fundamental idea of the library are that sensors should only be awake when in use and should otherwise be asleep in a minimal power mode, hence it has been optimized to use minimal power with a proper implementation drawing <5μA when in sleep mode. It enables both high and low level interfacing with the RS-485 sensor, so if you want to forget about the nuances RS-485 and have that manged automatically that is possible and so is getting down to control the specific pins to interface with the RS-485 line driver directly.

Implementation

Extract the src folder from the downloaded .zip file.
Place the src folder in the same folder as your arduino .ino sketch.
Edit RS485args.h (located inside the src folder) to fit setup.

Downloads

Library

Revision 1.0.0 (2020-09-18) : File:BoSL RS485 Bus Library rev 1.0.0.zip

Annotated Examples

Host Sketch (rev 1.0.0 | 2020-09-18) : File:Host.zip
Sensor Sketch (rev 1.0.0 | 2020-09-18) : File:Sensor.zip

Documentation

Command Packet

A command packet is an easy and safe way to send commands from the host to a sensor. It is implemented to automatically take care of waking of sensors, and only a small about of user code is needed to handle the auto-sleep after a command is issued.

The structure of a command packet is a wake even followed by 4-bytes of data. The wake events consists of a 1 μS pulse of the WKE line low. This is sufficient to wake up the ATmega328p microcontroller. Following this 9 mS is waited for the sensors to have sufficient time to wake from sleep. 4 bytes of data are then sent over the bus. The first byte, addr, signifies the device address, after this byte has been received it is allowed to send all the sensors which do not have this address back to sleep. The 2nd byte, opp, signifies the intended operation for the sensor. The operations are to implemented on a sensor to sensor level however preferred names of standard operations are defined below. The 3rd and 4th bytes are named parA and parB. These are two bytes which can carry additional information about the operation. They have no specific defined use and can be used for however useful.

In fact the command packet is not only able to be used over RS-485. The library should be flexible enough to have this work over plain Serial. So this may still be a useful protocol to use if you want a quick way to transfer data from a non-rs485 sensor that you are prototyping.

Device Address

The device address may take any value from 0x00 - 0xFE inclusive. The 0x00 device address shall be reserved for the host bus. 0xFF is reserved as an internal error and so shall not be used as a device address. device addresses are defined in software at runtime. A define may change its address during operation however this is unadvised.

A table of currently used addresses is included below to help with address space management.

Address	Use
0x00	Host
0x01	testing use
0xFF	Reserved

Suggested Operation Names

The table below lists sensible names for operations that would be universal to different sensors. They are not necessary to be adhered to.

Operation Name	Function
P	Poll sensor measurement
S	Sleep (if not automatic)
I	Get sensor info