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

Groups > comp.arch.embedded > #28886

Re: Multidrop bus on Windows

Show all headers | View raw

On 03/10/2019 09:59, upsidedown@downunder.com wrote:
> On Thu, 3 Oct 2019 09:19:41 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> 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:
>>>

>> 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.
> 
> This is true for most protocols, but not with Modbus RTU, since if the
> start bit gets trough, it calculates the frame length incorrectly and
> tries to locate the CRC from the wrong position.

Modbus requires a break before the start of the telegram - at least 3.5
character times.  A slave that checks this will not be bothered by the
noise.

Failing that, it is not uncommon to avoid address 255 and consider a
start address of 255 as noise.

But it certainly /can/ be an issue, and should be considered when
designing a system.

> 
>> Still, it is /much/ nicer with a device like the FTDI chips that handles
>> the drive enable timing automatically.
> 
> So does some UARTs in a PCI cards.

Yes.  But those are often not directly compatible with standard ports.

> 
>>>> 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.
> 
> The serial number trick works, but requires an unique serial number
> .e.g. with a separate serial number chip or some Flash memory to store
> a (hopefully) unique serial number at first use.

Any USB serial converter you buy should have a unique serial number.  If
they don't, then try buying from a reputable source instead of something
that fell off an eBay truck.

> 
> Relying on device position in a hub tree is a no no thing, since more
> hub levels may have to be added if more USB devices are inserted.

It is a "yes yes" thing for many people in many environments, because it
is obvious and convenient - it's just like plugging your RS-232 line
into "com1" at the back of an ancient PC.

The options are there, and it's up to you to pick the ones that suit best.

> 
>>
>> 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.
> 
> Use fixed IP-addresses in a private address area such as 192.168.x.y.
> 

That can work - or it can lead to complications and conflicts.  And it
either means /very/ expensive converter devices with some way of viewing
and setting the IP addresses, or chicken-and-egg time-wasting for
configuration.

>> 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.)
> 
> For accurate timing, do not use TCP between PC and converter. UDP will
> give a more predictable timing or just raw MAC framing, but this is
> much harder to use on Windows.

Raw MAC framing is out of the question for Windows.  UDP is a better
than TCP/IP for low latency (but loses you the joys of redirecting your
traffic over ssh links, VPNs, the internet, etc.), but it is certainly
far from real-time.

> 
> A converter based on the QUICC co-processor (found on MC68360 and some
> PPC models) should be able to handle a few fast serial lines. But of
> course, these processors are an overkill for such simple task.
> 

Yes, that is overkill.

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