RS485 guard-time

I just noticed a nice feature of SAM C2x microcontrollers from Atmel. It is the RS485 support, i.e. one pin (TE) goes high when the UART is transmitting and goes immediately low when the last byte was really shifted out, including stop bits.

There is an additional feature that Atmel named "guard time".

" For RS485 mode, the guard time is programmable from 0-7 bit times and defines the time that the transmit enable pin (TE) remains high after the last stop bit is transmitted and there is no remaining data to be transmitted. "

When the guard time could be useful? I think it's better to disable the transmitter as soon as possible to avoid corrupting the next message from another node on the bus.

Maybe it is desirable another *different* feature, a guard time *before* starting the transmission of a packet. This would give some time to the node that has just finished the transmission that needs to disable its transmitter (...and doesn't have the hardware control of TE pin).

Reply to
Loading thread data ...

Really good feature compared to dumb 14550 UARTs.

Those stupid UARTs generate an interrupt, when the last byte is _moved_ into the shift register, not when the last stop bit is shifted out causing a huge amount of problems.

Modbus RTU requires 1.5 and 3.5 character idle times between messages i.e. 15 to 35 bit times so the 0-7 bit "guard time" is too little :-(.

Fortunately only 0 bit guard time is sufficient assuming "fail safe" (as written in the RS-485 standard with quotes-) termination, i.e.

100-120 ohm termination with proper line pull up/down resistors.

Would be useful for Modbus RTU, but the guard time is too short.

Modbus RTU also requires putting the transmitter into the actively driven idle "1" state, 1.5 character times (15 bit times) before starting to send the actual message.

Apparently Atmel designers have heard some protocol specifications, but unfortunately have not understood the requirements of the most common industrial protocol (Modbus RTU) but have not understood the real timing requirement of 1.5 and 3.5 character times.

Fortunately, in practice, you can be a bit sloppy with these requirements in some spacial cases, especially with "fail safe" termination".

Reply to

1.5 is "inter-character" time inside a message. This is the max. idle time between characters (not messages) inside a valid message. 3.5 is the "inter-message" idle time.

I didn't heard of that until now. Please give a reference.

Reply to



I was just trying to point that the 0-7 bit time is too little.

The inter-character time and the preamble times are closely related. In the time when the original RS-485 standard was written, "fail safe" termination was apparently just an option. Many systems did not have any terminations or pull up/down resistors.

In such a system, when a station turned the transmitter off, the line was in a very high impedance state, floating anywhere and sensitive to noise coupled asymmetrically to the both lines. This could cause some false start bit generations, i.e. a sufficiently long (a half bit time at least "0" state, which is interpreted as a start bit. The UART would then often capture 0xFF, 0xFE or even 0xF0 depending of the width of the spurious "0" pulse (remember LSBs is sent first immediately after the start bit).

The 1.5 inter-character limit helps separate spurious noise from the actual start of the message. Turning the transmitter on 1.5 character times before the actual frame puts the line into a low impedance idle "1" state, eliminating most of the spurious start bits 1.5 character times before the actual frame reception.

Having a false start bit less than 1.5 character times before the actual frame, will put a spurious prefix character in front of the received Modbus message and if less than 1 character times before the actual frame will even destroy the bit synch of the whole frame.

Thus, it is a good idea to stabilize the line with a low impedance idle state just before the actual message frame.

Reply to

While this is a very nice theory (I never worked with completely "open" rs485 nets, they have at least puyl-ups and pull-downs, so I didn't encounter such problems, nor I needed that 1.5 character time idle rs485 driving) you said: "Modbus RTU also requires..." This sounds like the modbus standard specifies this. That's why I asked for a reference. If this is not actually "required" by the standard, please specify so.

Reply to

m ha scritto:

well, I'using a AVR32 that has a "timer" embedded in the usart module that trigger an interrupt some time (that you can set) after a byte is received, and is long enough for the 3.5 char time, very useful for modbus rtu.

as for the guard-time: boh.

Bye Jack

Reply to

I have been using the QUICC coprosessors on MC68360 an later PPC models.

The character time based timing of QUICC is quite sufficient for Modbus (done myself), but still violates the Modbus standard bit oriented standards quite violently.

Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.