Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RS485 guard-time
147 views
Skip to first unread message
pozz
Jul 15, 2016, 7:04:49 AM7/15/16
to
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).
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).
upsid...@downunder.com
Jul 15, 2016, 4:02:12 PM7/15/16
to
On Fri, 15 Jul 2016 13:04:47 +0200, pozz <pozz...@gmail.com> wrote:
>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.
Really good feature compared to dumb 14550 UARTs.
>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.
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.
>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.
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.
>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).
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".
raimond....@gmail.com
Jul 16, 2016, 12:31:06 AM7/16/16
to
> 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 :-(.
>
1.5 is "inter-character" time inside a message. This is the max. idle time between
> i.e. 15 to 35 bit times so the 0-7 bit "guard time" is too little :-(.
>
characters (not messages) inside a valid message.
3.5 is the "inter-message" idle time.
> 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.
>
upsid...@downunder.com
Jul 16, 2016, 6:08:43 AM7/16/16
to
On Fri, 15 Jul 2016 21:30:46 -0700 (PDT), raimond....@gmail.com
wrote:
>> 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 :-(.
>>
>1.5 is "inter-character" time inside a message. This is the max. idle time between
>characters (not messages) inside a valid message.
Yes
>3.5 is the "inter-message" idle time.
Yes
I was just trying to point that the 0-7 bit time is too little.
>> 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.
>>
>I didn't heard of that until now. Please give a reference.
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.
wrote:
>> 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 :-(.
>>
>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 was just trying to point that the 0-7 bit time is too little.
>> 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.
>>
>I didn't heard of that until now. Please give a reference.
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.
raimond....@gmail.com
Jul 16, 2016, 11:44:19 AM7/16/16
to
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.
Jack
Jul 19, 2016, 5:18:27 AM7/19/16
to
Il giorno venerdì 15 luglio 2016 22:02:12 UTC+2, upsid...@downunder.com ha scritto:
> 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.
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.
> 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.
as for the guard-time: boh.
Bye Jack
upsid...@downunder.com
Jul 19, 2016, 7:25:32 AM7/19/16
to
On Tue, 19 Jul 2016 02:18:23 -0700 (PDT), Jack <jack...@gmail.com>
wrote:
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.
wrote:
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.
0 new messages