Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #18575 > unrolled thread

Two-wires RS485 and the driver enable problem

Back to article view | Back to comp.arch.embedded

Contents

  Two-wires RS485 and the driver enable problem pozzugno <pozzugno@gmail.com> - 2014-10-13 13:58 +0200
    Re: Two-wires RS485 and the driver enable problem Wouter van Ooijen <wouter@voti.nl> - 2014-10-13 14:29 +0200
      Re: Two-wires RS485 and the driver enable problem pozzugno <pozzugno@gmail.com> - 2014-10-13 14:38 +0200
        Re: Two-wires RS485 and the driver enable problem Wouter van Ooijen <wouter@voti.nl> - 2014-10-13 15:28 +0200
          Re: Two-wires RS485 and the driver enable problem Don Y <this@is.not.me.com> - 2014-10-13 07:21 -0700
            Re: Two-wires RS485 and the driver enable problem Wouter van Ooijen <wouter@voti.nl> - 2014-10-13 16:46 +0200
              Re: Two-wires RS485 and the driver enable problem Don Y <this@is.not.me.com> - 2014-10-13 08:02 -0700
          Re: Two-wires RS485 and the driver enable problem pozzugno <pozzugno@gmail.com> - 2014-10-13 16:59 +0200
            Re: Two-wires RS485 and the driver enable problem Don Y <this@is.not.me.com> - 2014-10-13 08:08 -0700
              Re: Two-wires RS485 and the driver enable problem pozz <pozzugno@gmail.com> - 2014-10-14 07:48 +0200
                Re: Two-wires RS485 and the driver enable problem Don Y <this@is.not.me.com> - 2014-10-13 23:28 -0700
                  Re: Two-wires RS485 and the driver enable problem pozzugno <pozzugno@gmail.com> - 2014-10-14 09:20 +0200
                    Re: Two-wires RS485 and the driver enable problem Don Y <this@is.not.me.com> - 2014-10-14 06:09 -0700
                Re: Two-wires RS485 and the driver enable problem David Brown <david.brown@hesbynett.no> - 2014-10-14 10:36 +0200
            Re: Two-wires RS485 and the driver enable problem Wouter van Ooijen <wouter@voti.nl> - 2014-10-13 18:14 +0200
        Re: Two-wires RS485 and the driver enable problem Tim Wescott <seemywebsite@myfooter.really> - 2014-10-13 16:30 -0500
    Re: Two-wires RS485 and the driver enable problem David Brown <david.brown@hesbynett.no> - 2014-10-13 14:47 +0200
      Re: Two-wires RS485 and the driver enable problem pozzugno <pozzugno@gmail.com> - 2014-10-13 14:56 +0200
        Re: Two-wires RS485 and the driver enable problem David Brown <david.brown@hesbynett.no> - 2014-10-13 16:13 +0200
        Re: Two-wires RS485 and the driver enable problem Don Y <this@is.not.me.com> - 2014-10-13 08:06 -0700
          Re: Two-wires RS485 and the driver enable problem pozzugno <pozzugno@gmail.com> - 2014-10-14 08:50 +0200
            Re: Two-wires RS485 and the driver enable problem Don Y <this@is.not.me.com> - 2014-10-14 14:34 -0700
    Re: Two-wires RS485 and the driver enable problem Richard Damon <Richard@Damon-Family.org> - 2014-10-13 09:11 -0400
    Re: Two-wires RS485 and the driver enable problem rickman <gnuarm@gmail.com> - 2014-10-13 10:53 -0400
      Re: Two-wires RS485 and the driver enable problem pozzugno <pozzugno@gmail.com> - 2014-10-13 17:03 +0200
    Re: Two-wires RS485 and the driver enable problem Grant Edwards <invalid@invalid.invalid> - 2014-10-13 15:20 +0000
      Re: Two-wires RS485 and the driver enable problem pozzugno <pozzugno@gmail.com> - 2014-10-16 09:01 +0200
        Re: Two-wires RS485 and the driver enable problem Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2014-10-16 10:19 +0300
        Re: Two-wires RS485 and the driver enable problem rickman <gnuarm@gmail.com> - 2014-10-16 05:02 -0400
    Re: Two-wires RS485 and the driver enable problem Don Y <this@is.not.me.com> - 2014-10-13 08:17 -0700
      Re: Two-wires RS485 and the driver enable problem Don Y <this@is.not.me.com> - 2014-10-13 08:19 -0700
      Re: Two-wires RS485 and the driver enable problem pozzugno <pozzugno@gmail.com> - 2014-10-14 09:28 +0200
        Re: Two-wires RS485 and the driver enable problem Don Y <this@is.not.me.com> - 2014-10-14 06:09 -0700
          Re: Two-wires RS485 and the driver enable problem rickman <gnuarm@gmail.com> - 2014-10-14 14:28 -0400
      Re: Two-wires RS485 and the driver enable problem rickman <gnuarm@gmail.com> - 2014-10-14 04:36 -0400
    Re: Two-wires RS485 and the driver enable problem Les Cargill <lcargill99@comcast.com> - 2014-10-13 12:35 -0500
      Re: Two-wires RS485 and the driver enable problem langwadt@fonz.dk - 2014-10-13 15:02 -0700
        Re: Two-wires RS485 and the driver enable problem Don Y <this@is.not.me.com> - 2014-10-13 17:36 -0700
          Re: Two-wires RS485 and the driver enable problem Les Cargill <lcargill99@comcast.com> - 2014-10-13 21:53 -0500
            Re: Two-wires RS485 and the driver enable problem Don Y <this@is.not.me.com> - 2014-10-13 20:24 -0700
    Re: Two-wires RS485 and the driver enable problem upsidedown@downunder.com - 2014-10-13 22:02 +0300
      Re: Two-wires RS485 and the driver enable problem Grant Edwards <invalid@invalid.invalid> - 2014-10-13 19:09 +0000
        Re: Two-wires RS485 and the driver enable problem glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-13 20:58 +0000
          Re: Two-wires RS485 and the driver enable problem Grant Edwards <invalid@invalid.invalid> - 2014-10-13 21:08 +0000
            Re: Two-wires RS485 and the driver enable problem langwadt@fonz.dk - 2014-10-13 14:40 -0700
      Re: Two-wires RS485 and the driver enable problem Dave Nadler <drn@nadler.com> - 2014-10-14 09:58 -0700
        Re: Two-wires RS485 and the driver enable problem rickman <gnuarm@gmail.com> - 2014-10-14 14:20 -0400
          Re: Two-wires RS485 and the driver enable problem David Brown <david.brown@hesbynett.no> - 2014-10-14 23:35 +0200
            Re: Two-wires RS485 and the driver enable problem rickman <gnuarm@gmail.com> - 2014-10-15 02:00 -0400
              Re: Two-wires RS485 and the driver enable problem David Brown <david.brown@hesbynett.no> - 2014-10-15 09:47 +0200
                Re: Two-wires RS485 and the driver enable problem rickman <gnuarm@gmail.com> - 2014-10-16 01:30 -0400
                  Re: Two-wires RS485 and the driver enable problem David Brown <david.brown@hesbynett.no> - 2014-10-16 20:46 +0200
                  Re: Two-wires RS485 and the driver enable problem Dave Nadler <drn@nadler.com> - 2014-10-16 12:00 -0700
              Re: Two-wires RS485 and the driver enable problem upsidedown@downunder.com - 2014-10-15 11:01 +0300
              Re: Two-wires RS485 and the driver enable problem Grant Edwards <invalid@invalid.invalid> - 2014-10-15 14:24 +0000
                Re: Two-wires RS485 and the driver enable problem rickman <gnuarm@gmail.com> - 2014-10-16 01:17 -0400
                  Re: Two-wires RS485 and the driver enable problem pozzugno <pozzugno@gmail.com> - 2014-10-16 08:36 +0200
                    Re: Two-wires RS485 and the driver enable problem rickman <gnuarm@gmail.com> - 2014-10-16 05:05 -0400
                      Re: Two-wires RS485 and the driver enable problem pozzugno <pozzugno@gmail.com> - 2014-10-16 12:54 +0200
                  Re: Two-wires RS485 and the driver enable problem Grant Edwards <invalid@invalid.invalid> - 2014-10-16 14:16 +0000
      Re: Two-wires RS485 and the driver enable problem upsidedown@downunder.com - 2014-10-15 09:09 +0300
        Re: Two-wires RS485 and the driver enable problem Grant Edwards <invalid@invalid.invalid> - 2014-10-15 14:26 +0000
    Re: Two-wires RS485 and the driver enable problem glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-13 20:55 +0000
    Re: Two-wires RS485 and the driver enable problem Tim Wescott <seemywebsite@myfooter.really> - 2014-10-13 16:37 -0500
      Re: Two-wires RS485 and the driver enable problem pozzugno <pozzugno@gmail.com> - 2014-10-14 09:37 +0200
    Re: Two-wires RS485 and the driver enable problem Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-14 20:44 +0200

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#18600

On Mon, 13 Oct 2014 13:58:42 +0200, pozzugno <pozzugno@gmail.com>
wrote:

>I have a multi-drop two-wires RS485 bus.  One node is the master and all 
>the others are slaves.  The master is the only node that is authorized 
>to initiate a transmission, addressing one slave.  The addressed slave 
>usually answers to the master.
>
>The bus is half-duplex, so every node disables the driver.  Only THE 
>node that transmits data on the bus enables the driver and disables it 
>as soon as it can, just after the last byte.  An interrupt (transmit 
>complete) usually triggers when the last byte is totally shifted out, so 
>the driver can be disabled immediately.
>
>Of course, other interrupts can be triggered.  What happens when 
>interrupt X (whatever) triggers just before the "transmit complete" 
>interrupt?  The result is the ISR X is called, postponing the execution 
>of "transmit complete" ISR.  The RS485 driver will be disabled with a 
>certain amount of delay.  In the worst case, the driver could be 
>disabled with a delay that is the sum of the duration of all ISRs that 
>could trigger.
>[In this scenario, I think of ISRs that can't be interrupted by a higher 
>priority interrupt.]
>
>If a node on the bus is very fast and starts transmitting (the master) 
>or answering (one slave) immediately after receving the last byte, but 
>when the previous transmitting node is executing other ISRs, the final 
>result is a corrupted transmission.
>
>What is the solution? I think the only solution is to define, at the 
>design time, a minimum interval between the receiving of the last byte 
>from one node and the transmission of the first byte.  This interval 
>could be in the range of 100 microseconds and should be calibrated on 
>the sum of duration of *all* ISRs of *all* nodes on the bus.  It isn't a 
>simple calculation.
>
>Moreover, implementing a short "software" delay in the range of some 
>microseconds isn't a simple task.  An empty loop on a decreasing 
>volatile variable is a solution, but the final delay isn't simple to 
>calculate at the design time, and it could depend on the compiler, 
>compiler settings, clock frequency and so on.  Use an hw timer only for 
>this pause?
>
>How do you solve this problem?
>
>[I know there are some microcontrollers that automatically (at the 
>hw-level) toggle an output pin when the last byte is totally shifted 
>out, but I'm not using one of the them and they aren't so common.]

You must be quite desperate, if you intend to use 1x550 style chips on
RS-485 :-). That chip family is useless for any high speed half duplex
communication.

You can get an interrupt when you load the last character into the Tx
shift register, but you can't get an interrupt, when the last bit of
the last character is actually shifted out of the Tx shift register.

In real word, some high priority code will have to poll, when the last
bit of your transmission has actually sent the last stop bit of your
last byte into the line.

[toc] | [prev] | [next] | [standalone]

#18601

On 2014-10-13, upsidedown@downunder.com <upsidedown@downunder.com> wrote:

> You must be quite desperate, if you intend to use 1x550 style chips on
> RS-485 :-). That chip family is useless for any high speed half duplex
> communication.
>
> You can get an interrupt when you load the last character into the Tx
> shift register, but you can't get an interrupt, when the last bit of
> the last character is actually shifted out of the Tx shift register.
>
> In real word, some high priority code will have to poll, when the
> last bit of your transmission has actually sent the last stop bit of
> your last byte into the line.

And (in my experience) figuring out when that stop bit has been sent
can be problematic.  Not all '550 "compatible" UARTs wait until the
end of the stop bit to set the "transmit shift register empty" status
bit.  Some I've used set it as soon as the last data bit has been
sent, and if you turn of the driver at that point, you canse lose the
stop bit and create a framing error.

-- 
Grant Edwards               grant.b.edwards        Yow! My polyvinyl cowboy
                                  at               wallet was made in Hong
                              gmail.com            Kong by Montgomery Clift!

[toc] | [prev] | [next] | [standalone]

#18603

Grant Edwards <invalid@invalid.invalid> wrote:

(snip, someone wrote)
>> In real word, some high priority code will have to poll, when the
>> last bit of your transmission has actually sent the last stop bit of
>> your last byte into the line.
 
> And (in my experience) figuring out when that stop bit has been sent
> can be problematic.  Not all '550 "compatible" UARTs wait until the
> end of the stop bit to set the "transmit shift register empty" status
> bit.  Some I've used set it as soon as the last data bit has been
> sent, and if you turn of the driver at that point, you canse lose the
> stop bit and create a framing error.

For the usual asynchronous serial systems, the stop bit is the
same level as the inactive state of the line. As long as you don't
start the next character too soon, you are safe.

If you are using it for a multiple driver line, seems to me that
you are using it for something that it wasn't designed to do.

-- glen

[toc] | [prev] | [next] | [standalone]

#18604

On 2014-10-13, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Grant Edwards <invalid@invalid.invalid> wrote:
>
> (snip, someone wrote)
>>> In real word, some high priority code will have to poll, when the
>>> last bit of your transmission has actually sent the last stop bit of
>>> your last byte into the line.
>  
>> And (in my experience) figuring out when that stop bit has been sent
>> can be problematic.  Not all '550 "compatible" UARTs wait until the
>> end of the stop bit to set the "transmit shift register empty" status
>> bit.  Some I've used set it as soon as the last data bit has been
>> sent, and if you turn of the driver at that point, you canse lose the
>> stop bit and create a framing error.
>
> For the usual asynchronous serial systems, the stop bit is the
> same level as the inactive state of the line.

That's true, but I don't know why it's relevent.  We're talking about
knowing when to turn off RTS at the end of the last byte in the
message. If you turn it off immediately after the last data bit, and
the level of the last data bit is opposite from the required stop-bit
(idle) state, then you end up with problems unless the line is biased
stringly enough to return the line to it's idle state in less than
about 1/8 of a bit time.  In my experience, a lot of installations end
up with no bias resistors at all...

> As long as you don't start the next character too soon, you are safe.

There is no next character.  We're talking about the last byte in a
message.

> If you are using it for a multiple driver line, seems to me that
> you are using it for something that it wasn't designed to do.

That's exactly what RS485 is designed to do, but for it to work
reliably, you have to leave RTS on during a good portion of the stop
bit so that the driver can actively force the line back to the idle
state.

-- 
Grant Edwards               grant.b.edwards        Yow! ... the MYSTERIANS are
                                  at               in here with my CORDUROY
                              gmail.com            SOAP DISH!!

[toc] | [prev] | [next] | [standalone]

#18607

Den mandag den 13. oktober 2014 23.08.45 UTC+2 skrev Grant Edwards:
> On 2014-10-13, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> 
> > Grant Edwards <invalid@invalid.invalid> wrote:
> 
> >
> 
> > (snip, someone wrote)
> 
> >>> In real word, some high priority code will have to poll, when the
> 
> >>> last bit of your transmission has actually sent the last stop bit of
> 
> >>> your last byte into the line.
> 
> >  
> 
> >> And (in my experience) figuring out when that stop bit has been sent
> 
> >> can be problematic.  Not all '550 "compatible" UARTs wait until the
> 
> >> end of the stop bit to set the "transmit shift register empty" status
> 
> >> bit.  Some I've used set it as soon as the last data bit has been
> 
> >> sent, and if you turn of the driver at that point, you canse lose the
> 
> >> stop bit and create a framing error.
> 
> >
> 
> > For the usual asynchronous serial systems, the stop bit is the
> 
> > same level as the inactive state of the line.
> 
> 
> 
> That's true, but I don't know why it's relevent.  We're talking about
> 
> knowing when to turn off RTS at the end of the last byte in the
> 
> message. If you turn it off immediately after the last data bit, and
> 
> the level of the last data bit is opposite from the required stop-bit
> 
> (idle) state, then you end up with problems unless the line is biased
> 
> stringly enough to return the line to it's idle state in less than
> 
> about 1/8 of a bit time.  In my experience, a lot of installations end
> 
> up with no bias resistors at all...
> 
> 
> 
> > As long as you don't start the next character too soon, you are safe.
> 
> 
> 
> There is no next character.  We're talking about the last byte in a
> 
> message.
> 
> 
> 
> > If you are using it for a multiple driver line, seems to me that
> 
> > you are using it for something that it wasn't designed to do.
> 
> 
> 
> That's exactly what RS485 is designed to do, but for it to work
> 
> reliably, you have to leave RTS on during a good portion of the stop
> 
> bit so that the driver can actively force the line back to the idle
> 
> state.
> 


I've never had much luck running with out bias (or failsafe as they call them)
too many false start bits

unless the wires are very long the ~600R or so recommended pull-up/down I'd think if would be fast enough even if you turn off the transmitter   

-Lasse

[toc] | [prev] | [next] | [standalone]

#18627

On Monday, October 13, 2014 9:02:33 PM UTC+2, upsid...@downunder.com wrote:
> ...you can't get an interrupt, when the last bit of
> the last character is actually shifted out of the Tx shift register.

Sure you can, just append N dummy TX bytes where "N" is the TX FIFO depth.

But check it on the scope!!

Hope that helps,
Best Regards, Dave

[toc] | [prev] | [next] | [standalone]

#18629

On 10/14/2014 12:58 PM, Dave Nadler wrote:
> On Monday, October 13, 2014 9:02:33 PM UTC+2, upsid...@downunder.com wrote:
>> ...you can't get an interrupt, when the last bit of
>> the last character is actually shifted out of the Tx shift register.
>
> Sure you can, just append N dummy TX bytes where "N" is the TX FIFO depth.
>
> But check it on the scope!!

That is a very dangerous way to control the driver enable.  Most likely 
the interrupt will happen when the start bit is sent which means the 
output will already be sending the start bit when the driver is disabled.

I think you are worrying about the wrong end of the message.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#18635

On 14/10/14 20:20, rickman wrote:
> On 10/14/2014 12:58 PM, Dave Nadler wrote:
>> On Monday, October 13, 2014 9:02:33 PM UTC+2, upsid...@downunder.com
>> wrote:
>>> ...you can't get an interrupt, when the last bit of
>>> the last character is actually shifted out of the Tx shift register.
>>
>> Sure you can, just append N dummy TX bytes where "N" is the TX FIFO
>> depth.
>>
>> But check it on the scope!!
>
> That is a very dangerous way to control the driver enable.  Most likely
> the interrupt will happen when the start bit is sent which means the
> output will already be sending the start bit when the driver is disabled.
>

It can often work fine - at worst, the receiver sees a brief noise at 
the end of the telegram itself, and that is easily ignored.

However, if you are worried that the "transmission complete" interrupt 
might be delayed too long, then clearly the same thing will apply to the 
final "transmit character" interrupt for your extra character.  So it is 
a useful trick if you don't have a "transmission complete" interrupt 
signal, but not for the problem at hand here.


> I think you are worrying about the wrong end of the message.
>

[toc] | [prev] | [next] | [standalone]

#18638

On 10/14/2014 5:35 PM, David Brown wrote:
> On 14/10/14 20:20, rickman wrote:
>> On 10/14/2014 12:58 PM, Dave Nadler wrote:
>>> On Monday, October 13, 2014 9:02:33 PM UTC+2, upsid...@downunder.com
>>> wrote:
>>>> ...you can't get an interrupt, when the last bit of
>>>> the last character is actually shifted out of the Tx shift register.
>>>
>>> Sure you can, just append N dummy TX bytes where "N" is the TX FIFO
>>> depth.
>>>
>>> But check it on the scope!!
>>
>> That is a very dangerous way to control the driver enable.  Most likely
>> the interrupt will happen when the start bit is sent which means the
>> output will already be sending the start bit when the driver is disabled.
>>
>
> It can often work fine - at worst, the receiver sees a brief noise at
> the end of the telegram itself, and that is easily ignored.
>
> However, if you are worried that the "transmission complete" interrupt
> might be delayed too long, then clearly the same thing will apply to the
> final "transmit character" interrupt for your extra character.  So it is
> a useful trick if you don't have a "transmission complete" interrupt
> signal, but not for the problem at hand here.

Is all of this based on the idea that the transmitter empty interrupt is 
not valid in some way?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#18641

On 15/10/14 08:00, rickman wrote:
> On 10/14/2014 5:35 PM, David Brown wrote:
>> On 14/10/14 20:20, rickman wrote:
>>> On 10/14/2014 12:58 PM, Dave Nadler wrote:
>>>> On Monday, October 13, 2014 9:02:33 PM UTC+2, upsid...@downunder.com
>>>> wrote:
>>>>> ...you can't get an interrupt, when the last bit of
>>>>> the last character is actually shifted out of the Tx shift register.
>>>>
>>>> Sure you can, just append N dummy TX bytes where "N" is the TX FIFO
>>>> depth.
>>>>
>>>> But check it on the scope!!
>>>
>>> That is a very dangerous way to control the driver enable.  Most likely
>>> the interrupt will happen when the start bit is sent which means the
>>> output will already be sending the start bit when the driver is
>>> disabled.
>>>
>>
>> It can often work fine - at worst, the receiver sees a brief noise at
>> the end of the telegram itself, and that is easily ignored.
>>
>> However, if you are worried that the "transmission complete" interrupt
>> might be delayed too long, then clearly the same thing will apply to the
>> final "transmit character" interrupt for your extra character.  So it is
>> a useful trick if you don't have a "transmission complete" interrupt
>> signal, but not for the problem at hand here.
> 
> Is all of this based on the idea that the transmitter empty interrupt is
> not valid in some way?
> 

No, my point was that Dave's suggestion of sending an extra byte is not
"very dangerous" as you suggest, and can be a useful trick.  It is not
needed here as the OP has a "transmission complete" interrupt which
triggers when the final send is complete.  Many other microcontrollers
and UARTs don't have a suitable interrupt on the final character (or
have flaws with it, such as an interrupt that triggers at the start of
the stop bit - turning off the driver at that point can cause
hard-to-trace problems).  For such micros, sending an extra byte can be
a good solution.

But as far as I can remember (it's a long time since I used an AVR), the
AVR's "transmission complete" interrupt works fine.

[toc] | [prev] | [next] | [standalone]

#18673

On 10/15/2014 3:47 AM, David Brown wrote:
> On 15/10/14 08:00, rickman wrote:
>> On 10/14/2014 5:35 PM, David Brown wrote:
>>> On 14/10/14 20:20, rickman wrote:
>>>> On 10/14/2014 12:58 PM, Dave Nadler wrote:
>>>>> On Monday, October 13, 2014 9:02:33 PM UTC+2, upsid...@downunder.com
>>>>> wrote:
>>>>>> ...you can't get an interrupt, when the last bit of
>>>>>> the last character is actually shifted out of the Tx shift register.
>>>>>
>>>>> Sure you can, just append N dummy TX bytes where "N" is the TX FIFO
>>>>> depth.
>>>>>
>>>>> But check it on the scope!!
>>>>
>>>> That is a very dangerous way to control the driver enable.  Most likely
>>>> the interrupt will happen when the start bit is sent which means the
>>>> output will already be sending the start bit when the driver is
>>>> disabled.
>>>>
>>>
>>> It can often work fine - at worst, the receiver sees a brief noise at
>>> the end of the telegram itself, and that is easily ignored.
>>>
>>> However, if you are worried that the "transmission complete" interrupt
>>> might be delayed too long, then clearly the same thing will apply to the
>>> final "transmit character" interrupt for your extra character.  So it is
>>> a useful trick if you don't have a "transmission complete" interrupt
>>> signal, but not for the problem at hand here.
>>
>> Is all of this based on the idea that the transmitter empty interrupt is
>> not valid in some way?
>>
>
> No, my point was that Dave's suggestion of sending an extra byte is not
> "very dangerous" as you suggest, and can be a useful trick.  It is not
> needed here as the OP has a "transmission complete" interrupt which
> triggers when the final send is complete.  Many other microcontrollers
> and UARTs don't have a suitable interrupt on the final character (or
> have flaws with it, such as an interrupt that triggers at the start of
> the stop bit - turning off the driver at that point can cause
> hard-to-trace problems).  For such micros, sending an extra byte can be
> a good solution.

I just don't know that putting the glitch on the bus is a good idea. 
Minimizing the glitch depends on a fast response to the interrupt which 
is most of what this thread has been discussing.  A slow response puts a 
larger glitch on the bus.

Personally I prefer to use hardware which is designed for the job and 
will handle the driver enable properly.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#18689

On 16/10/14 07:30, rickman wrote:

>
> Personally I prefer to use hardware which is designed for the job and
> will handle the driver enable properly.
>

You'll get no arguments on that point.  The trick of sending an extra 
byte is a way to make things work with non-ideal hardware - but better 
hardware is always nicer.

[toc] | [prev] | [next] | [standalone]

#18691

On Thursday, October 16, 2014 7:30:32 AM UTC+2, rickman wrote:
> Personally I prefer to use hardware which is designed for the job and 
> will handle the driver enable properly.

Me too. And I prefer datasheets that match the hardware,
and so forth. Then, I wake up from that nice dream, and
deal with reality ;-)

[toc] | [prev] | [next] | [standalone]

#18642

On Wed, 15 Oct 2014 02:00:20 -0400, rickman <gnuarm@gmail.com> wrote:

>On 10/14/2014 5:35 PM, David Brown wrote:
>> On 14/10/14 20:20, rickman wrote:
>>> On 10/14/2014 12:58 PM, Dave Nadler wrote:
>>>> On Monday, October 13, 2014 9:02:33 PM UTC+2, upsid...@downunder.com
>>>> wrote:
>>>>> ...you can't get an interrupt, when the last bit of
>>>>> the last character is actually shifted out of the Tx shift register.
>>>>
>>>> Sure you can, just append N dummy TX bytes where "N" is the TX FIFO
>>>> depth.
>>>>
>>>> But check it on the scope!!
>>>
>>> That is a very dangerous way to control the driver enable.  Most likely
>>> the interrupt will happen when the start bit is sent which means the
>>> output will already be sending the start bit when the driver is disabled.
>>>
>>
>> It can often work fine - at worst, the receiver sees a brief noise at
>> the end of the telegram itself, and that is easily ignored.
>>
>> However, if you are worried that the "transmission complete" interrupt
>> might be delayed too long, then clearly the same thing will apply to the
>> final "transmit character" interrupt for your extra character.  So it is
>> a useful trick if you don't have a "transmission complete" interrupt
>> signal, but not for the problem at hand here.
>
>Is all of this based on the idea that the transmitter empty interrupt is 
>not valid in some way?

Please tell us, how to get transmitter [shift register] empty
interrupt on the '550 style UARTs ? 

You can get last byte loaded into the transmit SR interrupt, but you
need to poll some status bits to know, when the last byte has been
shifted out of the SR.

There has been claims that dropping the SR empty status at the end of
last bit but before the stop bit(s) might be a problem, However, with
standard "fail-safe" termination, the line is in the idle state during
the stop bit times anyway.

Turning the transmitter a few bit times too late is usually not a
problem, except for extremely low line rates. A character delay can be
catastrophic, if the other station responds rapidly.

In practice (I have seen several examples) is the stupid
implementation in many devices, in which the designer relies on the
"last byte moved to the SR" interrupt and prematurely turns off the
transmitter and the line floats to the idle "1" state. Since the UART
sends LSB bits first, the premature Tx disable will set the MSB bit(s)
to 1, so 0x0? is received as 0x8?, 0xC?, 0xE?, 0xF? of even as 0xFF.

Since many protocols put BCC/CRC into the last byte, the received and
calculated value differ by those high bits, which is a clear sign of
premature Tx disabling.

This problem becomes worse as the line speed is dropped. Some devices
can't be used below 9600 bit/s rates due to this problem.
   

[toc] | [prev] | [next] | [standalone]

#18649

On 2014-10-15, rickman <gnuarm@gmail.com> wrote:
> On 10/14/2014 5:35 PM, David Brown wrote:
>
>> It can often work fine - at worst, the receiver sees a brief noise at
>> the end of the telegram itself, and that is easily ignored.
>>
>> However, if you are worried that the "transmission complete" interrupt
>> might be delayed too long, then clearly the same thing will apply to the
>> final "transmit character" interrupt for your extra character.  So it is
>> a useful trick if you don't have a "transmission complete" interrupt
>> signal, but not for the problem at hand here.
>
> Is all of this based on the idea that the transmitter empty interrupt is 
> not valid in some way?

We're talking about a 16550.  There _is_no_ transmitter empty
interrupt.  There is a transmit holding register empty interrupt, but
that happens _before_ transmission of the last byte has begun.

There is a transmit shift register empty status bit (no interrupt). In
my experience that status bit isn't reliable either and on some
implementations goes active before the final stop bit has been sent.

-- 
Grant Edwards               grant.b.edwards        Yow! Used staples are good
                                  at               with SOY SAUCE!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#18672

On 10/15/2014 10:24 AM, Grant Edwards wrote:
> On 2014-10-15, rickman <gnuarm@gmail.com> wrote:
>> On 10/14/2014 5:35 PM, David Brown wrote:
>>
>>> It can often work fine - at worst, the receiver sees a brief noise at
>>> the end of the telegram itself, and that is easily ignored.
>>>
>>> However, if you are worried that the "transmission complete" interrupt
>>> might be delayed too long, then clearly the same thing will apply to the
>>> final "transmit character" interrupt for your extra character.  So it is
>>> a useful trick if you don't have a "transmission complete" interrupt
>>> signal, but not for the problem at hand here.
>>
>> Is all of this based on the idea that the transmitter empty interrupt is
>> not valid in some way?
>
> We're talking about a 16550.  There _is_no_ transmitter empty
> interrupt.  There is a transmit holding register empty interrupt, but
> that happens _before_ transmission of the last byte has begun.

I don't know who "we" is, but the OP never said what UART he is using. 
I had the impression it was a UART within an MCU from his initial post 
where he refers to "some microcontrollers" toggling an output.  Did he 
say he is using a '550' type UART?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#18675

Il 16/10/2014 07:17, rickman ha scritto:
> On 10/15/2014 10:24 AM, Grant Edwards wrote:
>> On 2014-10-15, rickman <gnuarm@gmail.com> wrote:
>>> On 10/14/2014 5:35 PM, David Brown wrote:
>>>
>>>> It can often work fine - at worst, the receiver sees a brief noise at
>>>> the end of the telegram itself, and that is easily ignored.
>>>>
>>>> However, if you are worried that the "transmission complete" interrupt
>>>> might be delayed too long, then clearly the same thing will apply to
>>>> the
>>>> final "transmit character" interrupt for your extra character.  So
>>>> it is
>>>> a useful trick if you don't have a "transmission complete" interrupt
>>>> signal, but not for the problem at hand here.
>>>
>>> Is all of this based on the idea that the transmitter empty interrupt is
>>> not valid in some way?
>>
>> We're talking about a 16550.  There _is_no_ transmitter empty
>> interrupt.  There is a transmit holding register empty interrupt, but
>> that happens _before_ transmission of the last byte has begun.
>
> I don't know who "we" is, but the OP never said what UART he is using. I
> had the impression it was a UART within an MCU from his initial post
> where he refers to "some microcontrollers" toggling an output.  Did he
> say he is using a '550' type UART?

Yes, I'm using a UART peripheral integrated in microcontrollers, like 
PICs from Microchip or AVRs from Atmel.

[toc] | [prev] | [next] | [standalone]

#18682

On 10/16/2014 2:36 AM, pozzugno wrote:
> Il 16/10/2014 07:17, rickman ha scritto:
>> On 10/15/2014 10:24 AM, Grant Edwards wrote:
>>> On 2014-10-15, rickman <gnuarm@gmail.com> wrote:
>>>>
>>>> Is all of this based on the idea that the transmitter empty
>>>> interrupt is
>>>> not valid in some way?
>>>
>>> We're talking about a 16550.  There _is_no_ transmitter empty
>>> interrupt.  There is a transmit holding register empty interrupt, but
>>> that happens _before_ transmission of the last byte has begun.
>>
>> I don't know who "we" is, but the OP never said what UART he is using. I
>> had the impression it was a UART within an MCU from his initial post
>> where he refers to "some microcontrollers" toggling an output.  Did he
>> say he is using a '550' type UART?
>
> Yes, I'm using a UART peripheral integrated in microcontrollers, like
> PICs from Microchip or AVRs from Atmel.

Do you know if your transmitter empty interrupt works properly or is 
this what prompted the entire thread?

I was looking at some of the USB dongles for RS-485 a while back and 
some of them make it clear that the driver is controlled directly by the 
transmitter empty and so the last char gets out of the module correctly.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#18684

Il 16/10/2014 11:05, rickman ha scritto:
> On 10/16/2014 2:36 AM, pozzugno wrote:

> Do you know if your transmitter empty interrupt works properly or is
> this what prompted the entire thread?

AVR micros have two transmitter interrupts: register empty and transmit 
complete.  The transmit complete interrupt should disable the RS485 
driver and it seems work well.


> I was looking at some of the USB dongles for RS-485 a while back and
> some of them make it clear that the driver is controlled directly by the
> transmitter empty and so the last char gets out of the module correctly.

No, AVRs (and many many micros smaller and bigger) can't directly 
control the RS485 driver/direction.

[toc] | [prev] | [next] | [standalone]

#18685

On 2014-10-16, rickman <gnuarm@gmail.com> wrote:
> On 10/15/2014 10:24 AM, Grant Edwards wrote:
>> On 2014-10-15, rickman <gnuarm@gmail.com> wrote:
>>> On 10/14/2014 5:35 PM, David Brown wrote:
>>>
>>>> It can often work fine - at worst, the receiver sees a brief noise at
>>>> the end of the telegram itself, and that is easily ignored.
>>>>
>>>> However, if you are worried that the "transmission complete" interrupt
>>>> might be delayed too long, then clearly the same thing will apply to the
>>>> final "transmit character" interrupt for your extra character.  So it is
>>>> a useful trick if you don't have a "transmission complete" interrupt
>>>> signal, but not for the problem at hand here.
>>>
>>> Is all of this based on the idea that the transmitter empty interrupt is
>>> not valid in some way?
>>
>> We're talking about a 16550.  There _is_no_ transmitter empty
>> interrupt.  There is a transmit holding register empty interrupt, but
>> that happens _before_ transmission of the last byte has begun.
>
> I don't know who "we" is, but the OP never said what UART he is using. 
> I had the impression it was a UART within an MCU from his initial post 
> where he refers to "some microcontrollers" toggling an output.  Did he 
> say he is using a '550' type UART?

Sorry, I must have gotten this confused with a different thread.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm ZIPPY the PINHEAD
                                  at               and I'm totally committed
                              gmail.com            to the festive mode.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web