Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #18575 > unrolled thread
| Started by | pozzugno <pozzugno@gmail.com> |
|---|---|
| First post | 2014-10-13 13:58 +0200 |
| Last post | 2014-10-14 20:44 +0200 |
| Articles | 6 on this page of 66 — 16 participants |
Back to article view | Back to comp.arch.embedded
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 4 of 4 — ← Prev page 1 2 3 [4]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2014-10-15 09:09 +0300 |
| Message-ID | <n53s3ala7v59hdkeempk1hklf96ckofus7@4ax.com> |
| In reply to | #18600 |
On Mon, 13 Oct 2014 22:02:33 +0300, 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. An other way of dealing with '550 style UARTs on RS-485 is to use a driver chip that doesn't disable the receiver during your own transmit. Thus the UART Rx pin will hear your transmission and the Rx ISR can do "echo canceling" by monitoring your own transmission. As soon as the Rx interrupt hears your complete final transmitted byte, the Rx ISR can turn off the transmit enable (RTS) and change the Rx mode from echo canceling to normal Rx mode. This makes it possible to do all things in the ISR and you don't have to do anything in normal code (with potentially bad latencies in some OS).
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2014-10-15 14:26 +0000 |
| Message-ID | <m1m06e$nbm$2@reader1.panix.com> |
| In reply to | #18639 |
On 2014-10-15, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
> An other way of dealing with '550 style UARTs on RS-485 is to use a
> driver chip that doesn't disable the receiver during your own
> transmit. Thus the UART Rx pin will hear your transmission and the Rx
> ISR can do "echo canceling" by monitoring your own transmission. As
> soon as the Rx interrupt hears your complete final transmitted byte,
> the Rx ISR can turn off the transmit enable (RTS) and change the Rx
> mode from echo canceling to normal Rx mode.
>
> This makes it possible to do all things in the ISR and you don't have
> to do anything in normal code (with potentially bad latencies in some
> OS).
That works, but you have to disable the RX FIFO so that you get
notified of RX bytes immediatly.
--
Grant Edwards grant.b.edwards Yow! Everybody is going
at somewhere!! It's probably
gmail.com a garage sale or a disaster
Movie!!
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-10-13 20:55 +0000 |
| Message-ID | <m1he8s$lsi$1@speranza.aioe.org> |
| In reply to | #18575 |
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. Ethernet has a minimum time between packets that is independent of most other timing parameters. The suggestion for it is that it is enough time for the receiver to get the data out of its buffer, and get ready to receive again. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| Date | 2014-10-13 16:37 -0500 |
| Message-ID | <2MidnWywjIWd26HJnZ2dnUVZ5ggAAAAA@giganews.com> |
| In reply to | #18575 |
On Mon, 13 Oct 2014 13:58:42 +0200, pozzugno 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.] Unless your processor is very primitive, you should be able to make the serial interrupt the highest priority. Or take David Brown's suggestion and disable all but the serial interrupt when you start to transmit the last byte. > 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. I believe you're going about the last half of this backwards. Do not calculate the worst-case interrupt latency -- specify it, and make it a requirement on the slave boards. This should be easy enough to do if you are in charge of all the software, and still quite doable if you're only in charge of the communications software (assuming a functional group). > 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? In a UART without a FIFO, an easy way to do this would be to send one or more bytes with the transmitter disabled, then turn on the transmitter at the appropriate time. Basically, use the UART as your timed event generator. > > [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.] In my experience, unless you're really using a high baud rate and a slow processor, or if your ISR's are just plain incorrectly written, your interrupt latency will be far lower than a bit interval. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | pozzugno <pozzugno@gmail.com> |
|---|---|
| Date | 2014-10-14 09:37 +0200 |
| Message-ID | <m1ijqv$sdm$1@dont-email.me> |
| In reply to | #18606 |
Il 13/10/2014 23:37, Tim Wescott ha scritto: > On Mon, 13 Oct 2014 13:58:42 +0200, pozzugno 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.] > > Unless your processor is very primitive, you should be able to make the > serial interrupt the highest priority. I'm using AVR8 from Atmel controllers. I can't change interrupt priorities (they are hard-wired in the device). IMHO, anyway it's not a matter of priority, but of the lack of a *nested* interrupt controller: an ISR can't be never interrupted by higher priority interrupts (in this case, transmit complete). > Or take David Brown's suggestion > and disable all but the serial interrupt when you start to transmit the > last byte. This is a good suggestion, even if it isn't simple. I should save the status of all IRQ, disable them and reactive the ones originally active. >> 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. > > I believe you're going about the last half of this backwards. Do not > calculate the worst-case interrupt latency -- specify it, and make it a > requirement on the slave boards. This should be easy enough to do if you > are in charge of all the software, and still quite doable if you're only > in charge of the communications software (assuming a functional group). > >> 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? > > In a UART without a FIFO, an easy way to do this would be to send one or > more bytes with the transmitter disabled, then turn on the transmitter at > the appropriate time. Basically, use the UART as your timed event > generator. >> >> [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.] > > In my experience, unless you're really using a high baud rate and a slow > processor, or if your ISR's are just plain incorrectly written, your > interrupt latency will be far lower than a bit interval. >
[toc] | [prev] | [next] | [standalone]
| From | Arlet Ottens <usenet+5@c-scape.nl> |
|---|---|
| Date | 2014-10-14 20:44 +0200 |
| Message-ID | <543d6f0e$0$2842$e4fe514c@news.xs4all.nl> |
| In reply to | #18575 |
On 10/13/2014 01:58 PM, pozzugno wrote: > 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. Try to reduce the time spent in other ISRs. > > 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. Instead of calculating, you can also build the design, and then measure how long it takes and adjust the timeout value until error rate is sufficiently low. I'm assuming that error rate > 0 is acceptable. > > 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? Use a hardware timer, but it doesn't have to be just for this purpose. Often, you can still use match interrupts on a free running timer, you just have to adjust the match registers after each interrupt. I do this all the time. Keep in mind that the receiver also needs to process the incoming packet, verify checksums, and prepare a response. You can use the dead time for that. > > How do you solve this problem? Use a better microcontroller ?
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.arch.embedded
csiph-web