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

Groups > comp.arch.embedded > #28869 > unrolled thread

Multidrop bus on Windows

Back to article view | Back to comp.arch.embedded

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#28908

On Fri, 4 Oct 2019 16:14:11 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

>On 2019-10-04, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
>
>> On the slave side, each slave must be able to detect when a response
>> from an other slave has ended and when the master is sending a new
>> request to you. This requires accurate timing.
>
>I've seen it done without timing by using a state machine (including
>running CRC) to keep track of the response from the other slave and
>detect its end even without a gap.

One way of doing this is to have a 270 byte history buffer.

Immediately after a new byte is received, assume it is the last byte
of the CRC. Assume the 4th newest byte is the start of a frame and
calculate the CRC heck for this frame.

If it fails, start one byte position older and calculate new CRC for
this longer frame. Repeat this towards the end of the history buffer.

However, if there is a CRC match before reaching the end of the
history buffer, make a heuristic validity check (function code, count
etc.). If this check is OK, synchronization has been obtained and
lighter framing can be done in the future. If the heuristic fails,
this was a premature CRC mach, continue searching towards the older
starting points.

However, if no match has been found, the most recent received byte
was not the second byte of the CRC. Wait for next character and repeat
the processing with the history buffer.

[toc] | [prev] | [next] | [standalone]

#28884

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
> 

[toc] | [prev] | [next] | [standalone]

#28888

On 2019-10-03, David Brown <david.brown@hesbynett.no> wrote:

> 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.

I've worked for a "serial-port" company for 20 years, and port
numbering foul-ups are a non-stop source of problems for Windows
customers.  Still.

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

That is indeed the "right" answer (IMO).  I usually have 5-10 USB
serial devices plugged in to my desktop at any point in time, and it
doesn't matter what order/port I plug them in.  Thanks to a handful of
udev rules, they always get repeatable and predictable names.

-- 
Grant Edwards               grant.b.edwards        Yow! Could I have a drug
                                  at               overdose?
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#28894

On 03/10/2019 16:08, Grant Edwards wrote:
> On 2019-10-03, David Brown <david.brown@hesbynett.no> wrote:
> 
>> 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.
> 
> I've worked for a "serial-port" company for 20 years, and port
> numbering foul-ups are a non-stop source of problems for Windows
> customers.  Still.

Agreed.  (The FTDI note is a kind of "hack" solution, that they only
suggest for specific cases like a PC used for testing cards with their
devices on them.)

> 
>> (Or you can use Linux with a few udev rules and get whatever number and
>> naming system you want.)
> 
> That is indeed the "right" answer (IMO).  I usually have 5-10 USB
> serial devices plugged in to my desktop at any point in time, and it
> doesn't matter what order/port I plug them in.  Thanks to a handful of
> udev rules, they always get repeatable and predictable names.
> 

Yes.

Without specific udev rules (i.e., using the common standard rules),
there is a simple and predictable naming system - you get
/dev/ttyUSBxxx, where xxx is a number.  When you attach a device, you
get the next available number.  For simple uses, that can be enough.
But when using serial ports a lot, it is helpful to have rules that
match your own needs - whether that be giving specific names to specific
serial devices, or specific types of devices, or specific physical
ports, or whatever combination you like.

[toc] | [prev] | [next] | [standalone]

#28890

On Thursday, October 3, 2019 at 3:35:31 AM UTC-4, David Brown wrote:
> 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:
> > 
> >> 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.

You are saying that if you plug two identical USB serial port cables into the same USB port you will get two different COM port numbers?  I don't see that with FTDI devices.  I don't see any connection to serial number, rather to the type of cable.  FTDI will get a COM port number and another of the same type will get the same COM port number, but plug a CH340 cable into the same USB port and you'll get a new COM port number. 


> 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).

I have seen variable sets of low numbers reserved all the way up into the teens. 


> >> 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.)

Single cable between them.  I think I also tried using my home network but got zero traction with that.  The old system I used was a cable between two Win2k desktops.  

-- 

  Rick C.

  -- Get 2,000 miles of free Supercharging
  -- Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#28895

On 03/10/2019 17:04, Rick C wrote:
> On Thursday, October 3, 2019 at 3:35:31 AM UTC-4, David Brown wrote:
>> 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:
>>> 
>>>> 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.
> 
> You are saying that if you plug two identical USB serial port cables
> into the same USB port you will get two different COM port numbers?
> I don't see that with FTDI devices.  

Thinking more about this, it might depend on the devices.  Many newer
FTDI chips have ROM and/or EEPROM built in, and come with a serial
number.  But older ones relied on external EEPROM and you put in a
serial number yourself when you program them.  With blank devices, there
is no serial number and therefore no way to distinguish them until they
are programmed.  (And they should be programmed with a unique serial
number - that is a requirement of USB.)

Most of the time I am using ready-made cables from FTDI (especially the
USB to 3.3V TTL serial cables - they are hugely popular for us in
development).  These of course have serial numbers.

> I don't see any connection to
> serial number, rather to the type of cable.  FTDI will get a COM port
> number and another of the same type will get the same COM port
> number, but plug a CH340 cable into the same USB port and you'll get
> a new COM port number.

Certainly when you have different USB manufacturer ID or product ID, you
should get a different comms port.

And maybe something has changed, or varies with different FTDI driver
versions, Windows versions, history of drivers and devices on the
particular machine, or something.  Comms port numbers on Windows always
seems to be a bit of a guessing game.

> 
> 
>> 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).
> 
> I have seen variable sets of low numbers reserved all the way up into
> the teens.
> 

I haven't seen that myself, but I don't find it hard to believe!

> 
>>>> 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.)
> 
> Single cable between them.  I think I also tried using my home
> network but got zero traction with that.  The old system I used was a
> cable between two Win2k desktops.
> 

You might, perhaps, need a cross-over cable for a direct connection.
Otherwise it is a matter of giving the two machines fixed IP addresses
on the same network.  Then IP networking should work.  I haven't tried
this with Windows machines, but I don't see any reason why you should
have trouble.  I certainly don't see any need for third-party software.

If you prefer, any cheap router will do the job.  Just connect both PC's
to LAN ports on the router - you don't need anything connected to the
"Internet" port on the router, or any setup.  Each PC will get an IP
address by DHCP and they can communicate.

(You might need to partially disable the local firewall junk on the
Windows PC's to let them listen to each other.  And if you have any
third-party "security" crapware, it's best to get rid of it.)

[toc] | [prev] | [next] | [standalone]

#28900

On Friday, October 4, 2019 at 3:43:41 AM UTC-4, David Brown wrote:
> On 03/10/2019 17:04, Rick C wrote:
> > On Thursday, October 3, 2019 at 3:35:31 AM UTC-4, David Brown wrote:
> >> 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:
> > 
> >>>> 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.)
> > 
> > Single cable between them.  I think I also tried using my home
> > network but got zero traction with that.  The old system I used was a
> > cable between two Win2k desktops.
> > 
> 
> You might, perhaps, need a cross-over cable for a direct connection.

Lol, I would have been able to tell pretty easily if that were the trouble.  


> Otherwise it is a matter of giving the two machines fixed IP addresses
> on the same network.  Then IP networking should work.  I haven't tried
> this with Windows machines, but I don't see any reason why you should
> have trouble.  I certainly don't see any need for third-party software.

Yes, Windows always makes things so easy.  Parts would work and then stop working.  At one time I was able to run either laptop from the other using the remote console feature or whatever they call it when your screen, keyboard and mouse operate the remote machine.  Then it wouldn't work in one direction.  File sharing wouldn't work.  I spent hours digging around on the Internet but most web sites just give the same, lame first level instructions on how to set it up and nothing on trouble shooting.  


> If you prefer, any cheap router will do the job.  Just connect both PC's
> to LAN ports on the router - you don't need anything connected to the
> "Internet" port on the router, or any setup.  Each PC will get an IP
> address by DHCP and they can communicate.

Didn't work any better. 


> (You might need to partially disable the local firewall junk on the
> Windows PC's to let them listen to each other.  And if you have any
> third-party "security" crapware, it's best to get rid of it.)

Totally off. 

That was months ago when I was setting up some PCs for work and the easy way to copy stuff would have been by Ethernet.  Instead I ended up using USB memory sticks.  Windows sucks. 

-- 

  Rick C.

  -+ Get 2,000 miles of free Supercharging
  -+ Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#28902

On 04/10/2019 12:16, Rick C wrote:
> On Friday, October 4, 2019 at 3:43:41 AM UTC-4, David Brown wrote:
>> On 03/10/2019 17:04, Rick C wrote:
>>> On Thursday, October 3, 2019 at 3:35:31 AM UTC-4, David Brown
>>> wrote:
>>>> 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:
>>> 
>>>>>> 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.)
>>> 
>>> Single cable between them.  I think I also tried using my home 
>>> network but got zero traction with that.  The old system I used
>>> was a cable between two Win2k desktops.
>>> 
>> 
>> You might, perhaps, need a cross-over cable for a direct
>> connection.
> 
> Lol, I would have been able to tell pretty easily if that were the
> trouble.

I expect so.  But I thought I'd better mention it just in case - maybe
others are reading these posts.

> 
> 
>> Otherwise it is a matter of giving the two machines fixed IP
>> addresses on the same network.  Then IP networking should work.  I
>> haven't tried this with Windows machines, but I don't see any
>> reason why you should have trouble.  I certainly don't see any need
>> for third-party software.
> 
> Yes, Windows always makes things so easy.

Sarcasm, I assume?  Windows makes /some/ things easy - but then the next
version will complete change the way it is done.

>  Parts would work and then
> stop working.  At one time I was able to run either laptop from the
> other using the remote console feature or whatever they call it when
> your screen, keyboard and mouse operate the remote machine.  Then it
> wouldn't work in one direction.  File sharing wouldn't work.  I spent
> hours digging around on the Internet but most web sites just give the
> same, lame first level instructions on how to set it up and nothing
> on trouble shooting.
> 
> 
>> If you prefer, any cheap router will do the job.  Just connect both
>> PC's to LAN ports on the router - you don't need anything connected
>> to the "Internet" port on the router, or any setup.  Each PC will
>> get an IP address by DHCP and they can communicate.
> 
> Didn't work any better.

Are the laptops going into low-power modes, or something like that?
(Yes, I know that may be another silly question.)

> 
> 
>> (You might need to partially disable the local firewall junk on
>> the Windows PC's to let them listen to each other.  And if you have
>> any third-party "security" crapware, it's best to get rid of it.)
> 
> Totally off.
> 
> That was months ago when I was setting up some PCs for work and the
> easy way to copy stuff would have been by Ethernet.  Instead I ended
> up using USB memory sticks.  Windows sucks.
> 

It sounds like you have tried most of the things I can think of for now.
 Have you tried VNC rather than RDP?

And of course, you can always switch to Linux.

[toc] | [prev] | [next] | [standalone]

#28892

On 2019-10-03 Rick C wrote in comp.arch.embedded:
> On Wednesday, October 2, 2019 at 6:11:58 PM UTC-4, upsid...@downunder.com wrote:
>> 
>> 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.  
>

That is how we handled this 30 years ago. ;-)

>> 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. 
>

Hmm, had the same experience with FTDI just recently. In extreme conditions,
I must admit. But it did crash.

>> 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 "lock" seems rather soft indeed. A converter may have the same COM
number for a while. But then, after you haven't used it for a while, it
suddenly has a different number. For a while I put stickers with the number
on some converters, but that was useless as they changed after a while.

The real fun starts when you use FTDI chips on your own board and don't
program them with a serial number. Every time you plug them in, the number
is increased and if you do that with 4-port versions, the number rapidly go
over the 100.
(Last time I did this was a long time ago and on W7, may have changed now)


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

You will visit the Dung Pits of Glive soon.

[toc] | [prev] | [next] | [standalone]

#28883

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.)

[toc] | [prev] | [next] | [standalone]

#28885

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:
>> 
>>> 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.

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.

>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.

>>> 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.

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.

>
>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.

>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.

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.

[toc] | [prev] | [next] | [standalone]

#28886

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.

[toc] | [prev] | [next] | [standalone]

#28891

On Thu, 3 Oct 2019 11:12:15 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>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.

Is this the reason why Modbus RTU documentation defines slave address
range 1 .. 247 (oxF7) ?

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

[toc] | [prev] | [next] | [standalone]

#28896

On 03/10/2019 19:15, upsidedown@downunder.com wrote:
> On Thu, 3 Oct 2019 11:12:15 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> 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.
> 
> Is this the reason why Modbus RTU documentation defines slave address
> range 1 .. 247 (oxF7) ?

That could be the case.  Or they might have other reasons - sometimes I
wonder what the Modbus designers were thinking for some of their rather
arbitrary decisions.

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

[toc] | [prev] | [next] | [standalone]

#28899

On Fri, 4 Oct 2019 09:45:38 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>On 03/10/2019 19:15, upsidedown@downunder.com wrote:
>> On Thu, 3 Oct 2019 11:12:15 +0200, David Brown
>> <david.brown@hesbynett.no> wrote:
>> 
>>> 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.
>> 
>> Is this the reason why Modbus RTU documentation defines slave address
>> range 1 .. 247 (oxF7) ?
>
>That could be the case.  Or they might have other reasons - sometimes I
>wonder what the Modbus designers were thinking for some of their rather
>arbitrary decisions.

The strange is that I saw this limitation only quite recently (maybe a
decade or so) ago.

Modbus/TCP Unit number (=slave address) field can be 0 - 255. This is
useful especially for Modbus/TCP to Modbus RTU gateways.

For native Modbus/TCP devices, which is essentially point to point,
the recommended unit number is 255.

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

[toc] | [prev] | [next] | [standalone]

#28887

On 2019-10-03, David Brown <david.brown@hesbynett.no> wrote:

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

Does windows support half-duplex mode on the less-ancient versions of
the 16x50?  I've used varous brands of 16850 UARTs and the half-duplex
mode always worked fine on them.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm not an Iranian!!
                                  at               I voted for Dianne
                              gmail.com            Feinstein!!

[toc] | [prev] | [next] | [standalone]

#28897

On 03/10/2019 16:04, Grant Edwards wrote:
> On 2019-10-03, David Brown <david.brown@hesbynett.no> wrote:
> 
>> Still, it is /much/ nicer with a device like the FTDI chips that handles
>> the drive enable timing automatically.
> 
> Does windows support half-duplex mode on the less-ancient versions of
> the 16x50?  I've used varous brands of 16850 UARTs and the half-duplex
> mode always worked fine on them.
> 

I believe so.  It is a /long/ time since I have done such programming,
but I seem to remember Win32 calls to put the serial driver in
"auto-RTS" mode suitable for RS-485.  I can't say I know how it was
implemented.

[toc] | [prev] | [next] | [standalone]

#28871

On 01/10/2019 16:02, pozz wrote:
> I often work on embedded firmware for MCUs connected by a multidrop
> master/slave RS485 bus.
> 
> Moreover I try to compile the same code with mingw compiler, simulating
> the hw. Of course, I simulate the serial bus connection (UART) by using
> a COM port on Windows.
> This allows me to speed-up testing, debugging and so on.
> 
> So I can launch many simulators of the same device or different devices.
> If they are two, I can use null-modem emulator (such as com0com) to make
> a point-to-point connection between the two devices.
> 
> What I'm trying to do is to launch three o more device simulators, each
> opening a virtual serial port, and let them talk together as they are on
> a real RS485 bus.
> 
> What I'm searching is a software that retransmit all data received on
> one serial port to all other serial ports under control.
> 
> Device 1 <-> COM11 <- null-modem emulator -> COM12
> Device 2 <-> COM13 <- null-modem emulator -> COM14
> Device 3 <-> COM15 <- null-modem emulator -> COM16
> 
> This bus simulator should open COM12, COM14 and COM16 and retransmits
> all data received on one port to all other ports.
> 
> I know I can write this myself, however I'm sure someone already wrote
> something similar to reuse.
> 

It should be about a two dozen lines of Python with pyserial.

But surely your PC simulators don't have to use serial ports?  They can
communicate by named pipes, TCP/IP connects, or whatever.

[toc] | [prev] | [next] | [standalone]

#28872

Il 01/10/2019 20:44, David Brown ha scritto:
> On 01/10/2019 16:02, pozz wrote:
>> I often work on embedded firmware for MCUs connected by a multidrop
>> master/slave RS485 bus.
>>
>> Moreover I try to compile the same code with mingw compiler, simulating
>> the hw. Of course, I simulate the serial bus connection (UART) by using
>> a COM port on Windows.
>> This allows me to speed-up testing, debugging and so on.
>>
>> So I can launch many simulators of the same device or different devices.
>> If they are two, I can use null-modem emulator (such as com0com) to make
>> a point-to-point connection between the two devices.
>>
>> What I'm trying to do is to launch three o more device simulators, each
>> opening a virtual serial port, and let them talk together as they are on
>> a real RS485 bus.
>>
>> What I'm searching is a software that retransmit all data received on
>> one serial port to all other serial ports under control.
>>
>> Device 1 <-> COM11 <- null-modem emulator -> COM12
>> Device 2 <-> COM13 <- null-modem emulator -> COM14
>> Device 3 <-> COM15 <- null-modem emulator -> COM16
>>
>> This bus simulator should open COM12, COM14 and COM16 and retransmits
>> all data received on one port to all other ports.
>>
>> I know I can write this myself, however I'm sure someone already wrote
>> something similar to reuse.
>>
> 
> It should be about a two dozen lines of Python with pyserial.

I know.


> But surely your PC simulators don't have to use serial ports?  They can
> communicate by named pipes, TCP/IP connects, or whatever.
> 

I sometimes connect a simulator to a real device, so I need to use a 
real COM port.

[toc] | [prev] | [next] | [standalone]

#28876

On 02/10/2019 09:03, pozz wrote:
> Il 01/10/2019 20:44, David Brown ha scritto:
>> On 01/10/2019 16:02, pozz wrote:
>>> I often work on embedded firmware for MCUs connected by a multidrop
>>> master/slave RS485 bus.
>>>
>>> Moreover I try to compile the same code with mingw compiler, simulating
>>> the hw. Of course, I simulate the serial bus connection (UART) by using
>>> a COM port on Windows.
>>> This allows me to speed-up testing, debugging and so on.
>>>
>>> So I can launch many simulators of the same device or different devices.
>>> If they are two, I can use null-modem emulator (such as com0com) to make
>>> a point-to-point connection between the two devices.
>>>
>>> What I'm trying to do is to launch three o more device simulators, each
>>> opening a virtual serial port, and let them talk together as they are on
>>> a real RS485 bus.
>>>
>>> What I'm searching is a software that retransmit all data received on
>>> one serial port to all other serial ports under control.
>>>
>>> Device 1 <-> COM11 <- null-modem emulator -> COM12
>>> Device 2 <-> COM13 <- null-modem emulator -> COM14
>>> Device 3 <-> COM15 <- null-modem emulator -> COM16
>>>
>>> This bus simulator should open COM12, COM14 and COM16 and retransmits
>>> all data received on one port to all other ports.
>>>
>>> I know I can write this myself, however I'm sure someone already wrote
>>> something similar to reuse.
>>>
>>
>> It should be about a two dozen lines of Python with pyserial.
> 
> I know.
> 
> 
>> But surely your PC simulators don't have to use serial ports?  They can
>> communicate by named pipes, TCP/IP connects, or whatever.
>>
> 
> I sometimes connect a simulator to a real device, so I need to use a
> real COM port.

Can you abstract it a bit in the code?  Your simulator code could use
pipes or network sockets, and you can have a single extra program that
can act as a hub between these sockets and one real RS-485 serial port.
 It just seems inefficient to have lots of serial ports on a computer
with null modem cables connecting them together.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web