Electron RS485 Timing Troubles


I currently have a system of 4 boards all connected through a half duplex RS485 network. The board containing the Electron is the master device and the other three are all slave devices.

I am using MAX485 chips and Serial5 for the Electron’s communication. I am also regularly requesting data from the slave boards every 250 milliseconds.

When the electron sends a command to a slave device, it must toggle the DE/RE pin on the MAX485 high, send serial data and toggle the pin low again to wait for a response. This all works perfectly while the Electron is connected to the cloud, but fails randomly when the Electron is disconnected and flashing green.

From what I have seen, with the help of an oscilloscope, the data transmits fine, but there is a delay before the DE/RE pin is set low again. The delay is long enough for the slave device to do its work and start sending a response. By the time the pin is set low, the Electron has missed data, which the a big problem.

The delay I am seeing is only present when the Electron is looking for cloud connection. My assumption is that the Serial commands have a high priority in the Electron’s multi-threading, but the digitalWrite does not, so some cloud functionality is taking place between the commands and causing a delay.

I have tried running the rs485 communication in a SINGLE_THREADED_BLOCK(), which fixes the communication issue, but never allows the Electron to connect to the cloud.

My current solution was to alter the slave’s code to add a delay between receiving a command and sending the response, but this is causing the communication to take too long.

Does anyone have any suggestions or ideas on how to fix this?
Hopefully this is clear enough and makes some sense.

You can give pinSetFast()/pinResetFast() a try.

Thank you for the suggestion. I wasn’t aware of these functions.

This didn’t completely fix my issue, but it did speed things up enough to be tolerable. I went from needing a 10 millisecond delay to a 200 microsecond delay, which is fast enough for what I need.

Thanks again.