Difference between revisions of "RS-485"

From BoSL Wiki
Jump to navigation Jump to search
Line 66: Line 66:
 
[[File:RS-485 RX.png|thumb|BoSL_Bus_Operation, Left: Sleep, Middle: Active, Right: Upload]]
 
[[File:RS-485 RX.png|thumb|BoSL_Bus_Operation, Left: Sleep, Middle: Active, Right: Upload]]
  
An implementation of the BoSL Bus for a ATmega with complete functionality would look something like this:
+
An implementation of the BoSL Bus for a ATmega with complete functionality would look like this:
 +
 
 +
The SN65HVD75 is the RS-485 transceiver. Resistors R1 and R2 ensure that RE and DE are driven correctly during uploading (send data over RS-485), as when programming pins are in a floating state. When sleeping this does mean that DE will need to be pulled down, however this would draw ~8μA, which is negligible. Introducing more circuitry to reduce this would add unnecessary cost and space requirements. A potential future solution is to update the boot loader however this is not an immediate solution.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Mode !! DE !! RE
 +
|-
 +
| Sleep|| L || H
 +
|-
 +
| Program || H || H
 +
|-
 +
| Active|| H\L || H\L
 +
|}
 +
 
 
[[File:BoSL Bus.png|thumb|BoSL Bus Implementation with complete functionality]]
 
[[File:BoSL Bus.png|thumb|BoSL Bus Implementation with complete functionality]]

Revision as of 10:07, 7 July 2020

Here we will log the development of RS-485 interface onto BoSL sensors.

Requirements:

  • Upload Code
  • Sleep/Wake sensors
  • 3V3 5V interoperable
  • Minimum wires
  • Bus operation


Uploading code is the first issue to be addressed. RS-485 is half-duplex over a single twisted pair. This presents issues during uploading as it requires full duplex operation. The easiest solution is to move to full duplex. This would require 2 twisted pairs thus a full bus likely 8. Ideally less wires would be needed.
Another solution is to modify the uploading program and use another wire to send to the sensor whether it should be receiving or sending data. This would likely require special programmer hardware and software.
It is also possible to update the Arduino bootload to recognise when it needs to be sending and receiving data. This may be possible, but it is uncertain how reliably this would work or if it is feasible.
Additional wires could also be left exposed on the sensors so that uploading remains possible via these. This solution is is difficult as it introduces another entry point for water.

A solution which looks promising is illustrated below. It is a 6 wire system. It enables uploading of code over half duplex RS-485 by utilizing the wake line for the programmer to receive data from the sensor. This allows for the full duplex needed while uploading. It should be noted that this system may have a hard time uploading over very very long cables as the TX from the sensor will not be over RS485. The exact length is yet to be determined however is likely in the range of 10s of meters.

This solution works because the use of TX and WKE are never needed simultaneously. That is that if the sensor is sleeping TX is not being used so WKE is free to be driven high to wake the ATmega. Conversely, when the sensor is being programmed it is already awake and so WKE signals do not need to be sent, freeing the line for TX.

A full list of wires is:

  • 3V3
  • GND
  • RST/5V
  • WKE/TX
  • RS-485 A
  • RS-485 B

Some testing will need to be done on what is the best arrangement of these onto 3 twisted pairs but a first iteration is:

Signal Wire
3V3 Orange
RST/5V Half Orange
GND Green
WKE/TX Half Green
RS-485 A Blue
RS-485 B Half Blue

The option may also be available to use RST as a 5V rail. This is possible if the ATmega reset pin is 5V tolerant. On reading the data sheet it looks like a diode may be nessesary to protect the reset pin.

https://au.element14.com/texas-instruments/sn65hvd75dgk/rs422-rs485-txrx-20mbps-3-6v-vssop/dp/3119111 This transceiver is looking promising. It has 5V tolerant inputs too!

7 June 2020

In thinking about the potential issues with the bus it was decided that and WKE/RX combination offered benefits over a WKE/TX combination. A WKE/RX combination solves the issues of having a very long cable attached to TX permanently which may cause instability or excess current draw if the TX pin needs to drive the large load of this wire. Additionally, if the cable is too long for an upload to work successfully a more powerful driver on the programmer side can be used. This will help extend the range somewhat. Since the cable is connected to RX on the programmer side, when not uploading it can be disconnected and rewired to the WKE line. This prevents the RX signals from being sent across it when not uploading*. * the RS-485 driver will still be electrically connected to the WKE line during normal operation, so a small buffer gate or diode will be needed to stop this. It remains to be tested which is the better solution.

The RS-485 Driver will also need to automatically be put in the transmit state when the upload process begins. This should be achievable through pull up resistors.

With the changes as described the new operating modes of the bus are:

BoSL_Bus_Operation, Left: Sleep, Middle: Active, Right: Upload

An implementation of the BoSL Bus for a ATmega with complete functionality would look like this:

The SN65HVD75 is the RS-485 transceiver. Resistors R1 and R2 ensure that RE and DE are driven correctly during uploading (send data over RS-485), as when programming pins are in a floating state. When sleeping this does mean that DE will need to be pulled down, however this would draw ~8μA, which is negligible. Introducing more circuitry to reduce this would add unnecessary cost and space requirements. A potential future solution is to update the boot loader however this is not an immediate solution.

Mode DE RE
Sleep L H
Program H H
Active H\L H\L
BoSL Bus Implementation with complete functionality