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

Groups > comp.arch.embedded > #28883

Re: Multidrop bus on Windows

Show all headers | View raw

On 03/10/2019 00:11, upsidedown@downunder.com wrote:
> On Wed, 2 Oct 2019 12:12:06 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 02/10/2019 10:33, upsidedown@downunder.com wrote:
>>> On Wed, 2 Oct 2019 09:04:31 +0200, pozz <pozzugno@gmail.com> wrote:
>>>
>> <snip>
>>>> I sometimes need to connect a simulator to a real device, so I need to 
>>>> use COM port.
>>>
>>> If you intend to use a typical 14500 compatible UART on a PC, there
>>> are issues with Tx/Rx switching in half duplex multidrop RS-485.
> 
> Should be 16450. Those do not have an interrupt when the last stop bit
> of the last character has actually shifted out of the UART shift
> register, only when he last character has been moved from the Tx FIFO
> to the shift register. It still takes a full character time before the
> character has actually been shifted out and the transmitter can be
> disabled and set to tri-state.  
> 
> Some implementations put the Tx into tri-state some bit times too
> early and the last character is corrupted, typically having the last
> bits (most significant bits set eg. 0xFx, 0xEx etc due to 'fail safe'
> termination) . Others turn off the Tx too late, when the opposite end
> has already started to send the reply and the first character is lost
> or the whole message is garbled (start bit missing).

There was a common trick of sending an extra 0xff character beyond the
telegram you wanted to send, and when you got the interrupt as that
moved into the transmit register, you turned off the RS-485 driver.
This had a risk of letting a start bit, or part of a start bit, get
through - but for most protocols that was not an issue as it would be
ignored by the receiver.

Still, it is /much/ nicer with a device like the FTDI chips that handles
the drive enable timing automatically.

>  
>> It is a /long/ time since I have used "real" UART devices on a PC.  I
>> almost invariably use FTDI chip's USB UART cables and converters.  These
>> have no problem with RS-485 direction switching - I've run them at 3 MB.
>> (As usual, life is much easier with Linux than with Windows for such
>> things - in particular, you have no messing about with drivers, and no
>> run-away comms port numbering.)
> 
> I once tried some USB to serial converters, one crashed the Windows.
> 
> An other mixed the enumeration when two or more such converters were
> plugged into USB ports in different order, sending communication to
> wrong serial lines with potentially lethal consequences.

There is a big challenge with these kinds of devices and serial port
numbers in Windows.  Windows gives a new comms port to each new device
it sees, and sometimes to the same device on a different USB bus.  It
should not mix up the numbers - but it is very easy for users to do so -
if you have two devices and they are on comms port numbers 45 and 57,
which is which?

Programs that are aware of the USB nature of the ports can make this a
lot easier - it's not hard to use Win32 calls or the FTDI DLL's to
identify serial numbers of devices or the physical placement on bus and
hub trees.

Or you can use Linux, which makes it a lot easier to do that kind of thing.

> 
> These days I prefer ethernet to serial converters with proper Rx/Tx
> hardware switching. These work fine and you get 100 m range and
> galvanic isolation for 'free'.

Ethernet to serial converters can be useful, but have their own
complications - you have a lot more jitter in timings, and you have
challenges about identifying and addressing them on the network.

The RS-485 driving issue is no different from what you get with USB
RS-485 converters - the bus driver is enabled if and only if you are
transmitting.

> 
> Some early ethernet to serial converters waited  a looong time before
> forwarding the last Rx character to ethernet. Some had adjustable time
> settings with minimum settings of 10 ms :-(. This did make these
> devices useless for high speed half duplex traffic. Modern versions
> forwards the last character after one or few character time idle
> period detected on the Rx serial line.
> 

This is always going to be an issue.  It is an issue with USB too, but
less so than with Ethernet.

I have run USB serial ports at 3 Mbaud.  No Ethernet to serial converter
is going to send the last character within one or two character time
periods at these speeds.  (Nor will USB devices, but they'll be closer
and less varied.)

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Multidrop bus on Windows pozz <pozzugno@gmail.com> - 2019-10-01 16:02 +0200
  Re: Multidrop bus on Windows Dave Nadler <drn@nadler.com> - 2019-10-01 08:01 -0700
    Re: Multidrop bus on Windows pozz <pozzugno@gmail.com> - 2019-10-02 09:04 +0200
      Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-02 11:33 +0300
        Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-02 12:12 +0200
          Re: Multidrop bus on Windows Dave Nadler <drn@nadler.com> - 2019-10-02 04:59 -0700
          Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-03 01:11 +0300
            Re: Multidrop bus on Windows Rick C <gnuarm.deletethisbit@gmail.com> - 2019-10-02 19:06 -0700
              Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-03 07:39 +0300
                Re: Multidrop bus on Windows Rick C <gnuarm.deletethisbit@gmail.com> - 2019-10-02 22:16 -0700
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-03 09:10 +0300
                Re: Multidrop bus on Windows Rick C <gnuarm.deletethisbit@gmail.com> - 2019-10-03 07:53 -0700
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 08:54 +0200
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-04 12:44 +0300
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 13:00 +0200
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-04 15:54 +0300
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 15:13 +0200
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-04 16:40 +0300
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 16:49 +0200
                Re: Multidrop bus on Windows Grant Edwards <invalid@invalid.invalid> - 2019-10-04 16:14 +0000
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-05 14:24 +0300
              Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-03 09:35 +0200
                Re: Multidrop bus on Windows Grant Edwards <invalid@invalid.invalid> - 2019-10-03 14:08 +0000
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 08:59 +0200
                Re: Multidrop bus on Windows Rick C <gnuarm.deletethisbit@gmail.com> - 2019-10-03 08:04 -0700
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 09:43 +0200
                Re: Multidrop bus on Windows Rick C <gnuarm.deletethisbit@gmail.com> - 2019-10-04 03:16 -0700
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 13:10 +0200
              Re: Multidrop bus on Windows Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-10-03 22:12 +0200
            Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-03 09:19 +0200
              Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-03 10:59 +0300
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-03 11:12 +0200
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-03 20:15 +0300
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 09:45 +0200
                Re: Multidrop bus on Windows upsidedown@downunder.com - 2019-10-04 12:58 +0300
              Re: Multidrop bus on Windows Grant Edwards <invalid@invalid.invalid> - 2019-10-03 14:04 +0000
                Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-04 09:47 +0200
  Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-01 20:44 +0200
    Re: Multidrop bus on Windows pozz <pozzugno@gmail.com> - 2019-10-02 09:03 +0200
      Re: Multidrop bus on Windows David Brown <david.brown@hesbynett.no> - 2019-10-02 12:14 +0200

csiph-web