On Fri, 13 Feb 2009 21:28:33 -0500, CBFalconer <cbfalconer@yahoo.com> wrote:>Paul Keinanen wrote: >> CBFalconer <cbfalconer@yahoo.com> wrote: >>> rickman wrote: >>>> CBFalconer wrote: >>>> >... snip ... >>>> >>>>> Raise rts, await cts, send data, lower rts. You never send >>>>> data without cts being asserted by the receiver. Those >>>>> acronyms stand for request/clear to send. >>>> >>>> I thought this was an RS-485 interface. That only has tri-state >>>> data signals between the two devices. The RTS signal is used to >>>> enable the driver for transmission. I'm sure you know about >>>> this. I expect you just didn't get the context. >>> >>> Yes, but you need to connect the interface to the line to send. >>> rts does this. cts announces that the connection has been made. >> >> That CTS connection is only required for the RS-232 port and SW >> driver. In practice, the CTS is simply connected to the RTS line >> at the converter or the CTS could also be connected to the RTS >> line (which going to the transceiver) at the RS-232 D9 connector >> at the PC etc. > >You are making unnecessary assumptions. For example, when you >assert rts the line is busy. The interface cannot connect. When >it can, it does so, and returns cts. Now you can sendYour description fits to the 10BASE5 Ethernet AUI interface (looks like RS-422) between the Ethernet card and the vampire transceiver puncturing the thick yellow ethernet cable. Those control signals carried the carrier sense and collision detect signal to the actual Ethernet card. Other than that, I have never seen a protocol using the RS-485 hardware to rely on the media access unit monitoring the bus for bus access. The access is typically controlled in software either by the master/slave relationship or token ring/bus systems. OK, there is one historical curiosity, before actual CAN bus transceivers were widely available, ordinary RS-485 transceivers were used by controlling the TxEnable pin with the dominant/recessive information. The bus arbitration was handled by the controller by listening at the traffic on the bus on a bit by bit basis, but this did not use the RTS/CTS control. Paul
2 wire rs485
Started by ●February 10, 2009
Reply by ●February 13, 20092009-02-13
Reply by ●February 14, 20092009-02-14
On Feb 13, 9:28=A0pm, CBFalconer <cbfalco...@yahoo.com> wrote:> > You are making unnecessary assumptions. =A0For example, when you > assert rts the line is busy. =A0The interface cannot connect. =A0When > it can, it does so, and returns cts. =A0Now you can sendOk, now I understand. You are thinking of something other than RS-485. I don't what protocol you are thinking of, but RS-485 does not provide any mechanism for knowing when someone else is driving the bus. That has to be done in a higher level protocol. Typically it is handled at the message level using a single master and multiple slaves. So there is no CTS provided by the interface when using a standard RS-485 chip. Rick
Reply by ●February 14, 20092009-02-14
rickman wrote:> CBFalconer <cbfalco...@yahoo.com> wrote: > >> You are making unnecessary assumptions. For example, when you >> assert rts the line is busy. The interface cannot connect. >> When it can, it does so, and returns cts. Now you can send. > > Ok, now I understand. You are thinking of something other than > RS-485. I don't what protocol you are thinking of, but RS-485 > does not provide any mechanism for knowing when someone else is > driving the bus. That has to be done in a higher level protocol. > Typically it is handled at the message level using a single > master and multiple slaves. So there is no CTS provided by the > interface when using a standard RS-485 chip.Yes, it has a mechanism. Is there an active signal on the bus. If so, set a protective delay (1 bit time for ASCII) before seizing the buss. RS-485 IS NOT a protocol. It is a hardware spec. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section.
Reply by ●February 14, 20092009-02-14
On Feb 14, 12:10=A0am, CBFalconer <cbfalco...@yahoo.com> wrote:> rickman wrote: > > CBFalconer <cbfalco...@yahoo.com> wrote: > > >> You are making unnecessary assumptions. =A0For example, when you > >> assert rts the line is busy. =A0The interface cannot connect. > >> When it can, it does so, and returns cts. =A0Now you can send. > > > Ok, now I understand. =A0You are thinking of something other than > > RS-485. =A0I don't what protocol you are thinking of, but RS-485 > > does not provide any mechanism for knowing when someone else is > > driving the bus. =A0That has to be done in a higher level protocol. > > Typically it is handled at the message level using a single > > master and multiple slaves. =A0So there is no CTS provided by the > > interface when using a standard RS-485 chip. > > Yes, it has a mechanism. =A0Is there an active signal on the bus. =A0If > so, set a protective delay (1 bit time for ASCII) before seizing > the buss. > > RS-485 IS NOT a protocol. =A0It is a hardware spec.Exactly! There is nothing in RS-485 to provide for this CTS function. There is no CTS function in any RS-485 chip I have ever seen. What hardware have you seen that generates a CTS signal from the RS-485 bus? Rick
Reply by ●February 14, 20092009-02-14
"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote in message news:d6qdnXU_zZkekgvUnZ2dnUVZ8tLinZ2d@pipex.net...> "Paul Keinanen" <keinanen@sci.fi> wrote in message > news:5pm6p49v0r3naacq0g1bqci518nb1tg367@4ax.com... >> >> On RS-485, use one end with active fail safe termination (typically >> the master) as a reference and check the RxData LED on all slaves when >> the bus is idle. If the RxData LED is constantly lit on a specific >> slave only, just reverse the D+ and D- connections on that slave. > > Paul, I've never seen an RS-485 system with LEDs (and I have dealt with > more than a few). Luxury ;). > > Also, I've rarely (until fairly recently) seen fail-safe termination *as > standard*. (I include it in my designs, but hey... in my industry there > seems to be an awful lot of broken RS-485 implementations out there...) > > And from other posts re power consumption when both termination and > biasing are involved: there's a trick. AC-couple the termination > resistor/s with e.g. 0.1uF. Works a treat ;).Could you share how you do failsafe biasing, R values etc. I'm designing something with RS485 now... Thanks. Peter
Reply by ●February 14, 20092009-02-14
rickman wrote:> CBFalconer <cbfalco...@yahoo.com> wrote: >... snip ...> >> Yes, it has a mechanism. Is there an active signal on the bus. >> If so, set a protective delay (1 bit time for ASCII) before >> seizing the buss. >> >> RS-485 IS NOT a protocol. It is a hardware spec. > > Exactly! There is nothing in RS-485 to provide for this CTS > function. There is no CTS function in any RS-485 chip I have > ever seen. What hardware have you seen that generates a CTS > signal from the RS-485 bus?That's what you build, or select a chip (or chips) to do. RTS/CTS is a provision for communicating with that hardware, not the other end of the hardware connection. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section.
Reply by ●February 14, 20092009-02-14
On Feb 14, 8:34=A0pm, CBFalconer <cbfalco...@yahoo.com> wrote:> rickman wrote: > > CBFalconer <cbfalco...@yahoo.com> wrote: > > ... snip ... > > >> Yes, it has a mechanism. =A0Is there an active signal on the bus. > >> If so, set a protective delay (1 bit time for ASCII) before > >> seizing the buss. > > >> RS-485 IS NOT a protocol. =A0It is a hardware spec. > > > Exactly! =A0There is nothing in RS-485 to provide for this CTS > > function. =A0There is no CTS function in any RS-485 chip I have > > ever seen. =A0What hardware have you seen that generates a CTS > > signal from the RS-485 bus? > > That's what you build, or select a chip (or chips) to do. =A0RTS/CTS > is a provision for communicating with that hardware, not the other > end of the hardware connection.I am trying to understand where you got the idea that this is supported in either the hardware or the standard. Have you seen an implementation of RS-485 that provides a CTS that tells the sender that they are on the bus without contention? I have never seen this either in any RS-485 interface chips or in any design using RS-485. Thinking about how this might would seems like it would be a messy addition to any of the currently available RS-485 interface devices. It would require at a minimum two opamps or threshold comparators to detect the small difference in voltage when the bus is in idle state vs. when it is being driven. Even then I don't see a way to tell if your driver is the only driver on the bus. What if another driver is enabled onto the bus at the same time your driver is enabled. The bus voltage would go from idle state to driven state and neither of you would know the difference. The only way of detecting a bus collision is to detect the abnormal voltage from drivers driving to opposite states. I can do that much more easily by just monitoring the data at the receiver to see if what I am sending is what the bus is showing. No need at all for a CTS signal and no practical way that I can see to invent one. Rick
Reply by ●February 15, 20092009-02-15
rickman wrote:> CBFalconer <cbfalco...@yahoo.com> wrote: >... snip ...> >> That's what you build, or select a chip (or chips) to do. RTS/CTS >> is a provision for communicating with that hardware, not the other >> end of the hardware connection. > > I am trying to understand where you got the idea that this is > supported in either the hardware or the standard. Have you seen an > implementation of RS-485 that provides a CTS that tells the sender > that they are on the bus without contention? I have never seen this > either in any RS-485 interface chips or in any design using RS-485.Once more, this has nothing to do with the RS-485 standard, which deals only with hardware. This is about communication between your system and the i/o module that puts the signal on the RS-485 lines. You need this to use the system intelligently. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section.
Reply by ●February 15, 20092009-02-15
On Feb 14, 11:16=A0pm, CBFalconer <cbfalco...@yahoo.com> wrote:> rickman wrote: > > CBFalconer <cbfalco...@yahoo.com> wrote: > > ... snip ... > > >> That's what you build, or select a chip (or chips) to do. =A0RTS/CTS > >> is a provision for communicating with that hardware, not the other > >> end of the hardware connection. > > > I am trying to understand where you got the idea that this is > > supported in either the hardware or the standard. =A0Have you seen an > > implementation of RS-485 that provides a CTS that tells the sender > > that they are on the bus without contention? =A0I have never seen this > > either in any RS-485 interface chips or in any design using RS-485. > > Once more, this has nothing to do with the RS-485 standard, which > deals only with hardware. =A0This is about communication between your > system and the i/o module that puts the signal on the RS-485 > lines. =A0You need this to use the system intelligently.So does that mean that you don't have any examples of hardware that implement this protocol? But the real point is that, as you say, there is nothing in RS-485 that indicates a function that you describe. That is likely why it has not been seen in the wild. Rick
Reply by ●February 15, 20092009-02-15
On Sat, 14 Feb 2009 18:05:51 -0800 (PST), rickman <gnuarm@gmail.com> wrote:>Thinking about how this might would seems like it would be a messy >addition to any of the currently available RS-485 interface devices. >It would require at a minimum two opamps or threshold comparators to >detect the small difference in voltage when the bus is in idle state >vs. when it is being driven. Even then I don't see a way to tell if >your driver is the only driver on the bus. What if another driver is >enabled onto the bus at the same time your driver is enabled. The bus >voltage would go from idle state to driven state and neither of you >would know the difference.While I have never seen such circuit, the other way to implement such "bus available" signal would be with a retriggable monostable, which is restarted each time a "0" bit is detected (either start bit or a genuine 0 data bit) and when the monostable expires after one character time, the RTS signal could be gated back to CTS and the actual message could be sent. However, this does not detect the situation, in which two stations start to transmit simultaneously (or within the propagation delay of the cable). Also the monostable delay would have to be configured for the line speed used. Paul
