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

Groups > comp.arch.embedded > #28884

Re: Multidrop bus on Windows

Show all headers | View raw

On 03/10/2019 04:06, Rick C wrote:
> On Wednesday, October 2, 2019 at 6:11:58 PM UTC-4,
> upsid...@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).
> 
> I'm surprised no one thought of dealing with this issue by appending
> an optional char of all ones to the end of the message and adjusting
> the protocol to simply ignore this single char.  Treat it as optional
> and if the start bit is lost, no problem.  If it is received it gets
> tossed, no problem.

I know that's the way /I/ handled it, decades ago when it was a problem.
 I assume it was standard practice.

(As a side issue, I wrote a program on Win3.1 which needed fast regular
processing at about 1 kHz.  The Windows timers were at 50 or 60 Hz,
which was not nearly fast enough.  But if you opened an unconnected
serial port at 9600 baud, enabled interrupts on transfers, and sent one
character at a time - you had interrupts at approximately 1 kHz.  This
thread brings back happy memories!)

> 
> I recall working on a system that had this problem.  I don't recall
> how we dealt with it.  I seem to recall digging into the interrupt
> handler but that was over 30 years ago.  With the info I gained I did
> write a driver for the timer interrupt and the counter that drove the
> speaker.  I would read an 8 bit DAC sample and use it to pulse width
> modulate the speaker pulse train.  The timer interrupt was used to
> time the 8 kHz sample rate if I remember correctly.  It was seriously
> crude, but in those days a "multimedia" package was pretty pricey and
> many government computers didn't have it even if they needed it.
> This was a cheap way to play modem sounds for educational purposes on
> whatever PCs they had handy.  I had actually done this for my own
> amusement using a modem sound as my test file.  When one of the
> managers heard modem sounds coming from the lab he had to see how
> that was happening.  He knew only a couple of PCs in the office had
> multimedia kits installed.  He was amazed.  lol  It's so simple, I
> guess some people just don't think about stuff like that.  For me it
> was play.
> 
> 
>>> 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.
> 
> The Chinese brands don't have great drivers.  The Chinese fakes of
> quality brands are pretty crap.  I don't know of any that are so bad
> they crap out the PC though.
> 

When we have the choice, we invariably use FTDI devices - made in Scotland.

On older PC's, from the younger days of USB, I saw PC's crashing as the
result of ground loops through the USB drivers.  We had trouble with
that in one test system, long ago - the solution was an independent
ground wire from the PC chassis to the card, connected before the USB
was plugged in.

> 
>> 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.
> 
> Probably not the sequence, but rather the USB port.  When you plug a
> serial device into a USB port it gets a COM port number.  That number
> is now "locked" (in a soft way) and won't be reused unless you force
> it.  Plug the same serial device in another USB port and it will get
> a new COM port number.  The good point is you can select a COM port
> number without going into the setup by picking the USB port you plug
> it into.  The bad point is you need to remember which COM port is
> associated with which USB port.

That is not the case, at least not for FTDI devices (and several other
manufacturers).  Plug a different device (different serial number) into
the same port, and it will get a new comms port number.  Plug the old
one into a different port, and it might get the old number, or it might
get a completely new number - I have seen both effects, and can't
remember the controlling factors.

FTDI has application notes about registry entries you can change to get
the "comms port number follows physical port" effect, primarily for use
in test systems.

(Or you can use Linux with a few udev rules and get whatever number and
naming system you want.)

> 
> If you want, you can even pick an COM port number overriding any "in
> use" COM numbers as long as you know they aren't being used by
> hardware.  Not sure why, but Windows seems to want to reserve some
> low COM port numbers to start.
> 

Ports 1 to 4 are reserved for the standard physical comms ports (even
though they haven't been standard for a /long/ time on new PC's).

> 
>> 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'.
> 
> It's great if your device has an Ethernet port.  I don't know what it
> takes to set up the connection, but I know it was a bear to get two
> Windows 10 PCs to talk to each other over Ethernet, things like fill
> sharing.  Years before I use a web site WOW.com (World of Windows
> networking) or maybe it was WOWN.com, I forget.  It had the straight
> skinny on getting Win2k working and made it easy.  After Win2k MS
> seems to have made Ethernet harder and harder with each new
> generation.  Meanwhile WOWN.com was sold and the new guys didn't care
> about content, they just milked the traffic for advertising.

How are you trying to connect the PC's ?  Just a single Ethernet cable
between them, or putting them on an existing network?

(You are right that MS seems to make many tasks, like networking, harder
for each generation of Windows.)

> 
> Maybe I'm not recalling it right.  I see a site at wown.com which
> vectors to http://techgenix.com/networking/.  But searching for
> "world of windows networking" finds a site,
> http://www.windowsnetworking.com/j_helmig/contact.htm which looks
> like what I remember.  Oh, well.
> 
> 
>> 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.
> 
> Paper tape compatibility?  lol
> 

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