Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, a web toolkit designed to help citizens, conservation practitioners, municipal decision-makers, researchers, educators, and students advance knowledge and stewardship of fresh water. New to EnviroDIY? Start here

Reply To: RS485 without auto direction control

Home Forums Mayfly Data Logger RS485 without auto direction control Reply To: RS485 without auto direction control

#13492
neilh
Participant

Sara sorry about the stomach bug. Life is challenging when the rulers of the internal ecology get distracted with nasty bug invasions.

thanks for the fix ~ I just noticed this conversation today.

I think it was working with the AVR compiler as I had it all working for many months on a Mayfly (except that specific riparian monitoring Mayfly got stolen a couple of months ago). I’ve seen this problem before, that the AVR compiler has some defensive won’t execute a NULL pointer. Which is great. The NULL pointer came up in the ARM context, but I hadn’t regression tested it with the AVR.

I haven’t looked at this AVR Mayfly RS485 DIR management as its a streams based environment. That is where the Auto Direction SOM works very nicely. I had no problems with it.

Apologies if this is repeating something that everyone knows;
Modbus is a packet of information. At the begin of the packet the RS485 driver half duplex goes to transmit, and then only when the complete Modbus msg is sent does the RS485 driver revert to receive.
The reverting to receive is critical hard real time, as the modbus slave starts to respond shortly afterwards and I believe its specified at 3.5Character timings or about 3.5mS. Modbus also specifies for a packet that there should never be a gap between characters of more than 1.5Character timings or about 1.5mS.
The RS485 SOM does this with a simple hardware timing. Resistor, Cap, Diode and buffer(schmitt trigger) I believe.
For a streams based environment I believe its challenging.
I did investigate this for an Ubuntu Linux build and compiled in a different set of drivers for an RS485 mode.
For the streams based environment, turning the driver to transmit is easy and can be done before starting writing to the stream.
However it requires an accurate time to detect, not just when the last byte in the packet is written to the hardware (and how does a stream know its the last byte especially if there is a multibyte FIFO for the Tx UART) but when that byte has completed transmission through the UART. So for a stream based environment, the driver needs to start a timer whenever the UART end of character interrupt is received, and if another character isn’t written into the UART in 1.5character timings (a 1.5mS) then it needs to switch the direction to receive.
In the world of industrial designed systems for Modbus there are a number of potential solutions a) design a packet based interface for the Mega1280 UART- the UART supports end-of-byte transmission, but the driver guarenttees the Rx switch. b) use a MAX1348 driver which also has auto direction, but it requires +5V c) using a processor with UART that supports RS485 like the SAM51

Well Solstice Salutations to everyone, I hope you have a good holiday – and that there is harmony with the anthropogenic masters, the gastric microbial ecology!.