Forums

Multidrop bus on Windows

Started by pozz October 1, 2019
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.

On Tuesday, October 1, 2019 at 10:02:20 AM UTC-4, 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.
Why don't you stub the RS485 comms with some kind of network pub-sub layer? Perhaps using IP-multicast? I don't know offhand of a straight-forward (non-commercial) pub sub library, but probably there are a few out there... Maybe DBus? I wouldn't use serial comms for simulation. Hope that helps, Best Regards, Dave
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.
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.
Il 01/10/2019 17:01, Dave Nadler ha scritto:
> On Tuesday, October 1, 2019 at 10:02:20 AM UTC-4, 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. > > Why don't you stub the RS485 comms with some kind of network pub-sub layer? > Perhaps using IP-multicast? > I don't know offhand of a straight-forward (non-commercial) pub sub library, > but probably there are a few out there... Maybe DBus? > I wouldn't use serial comms for simulation.
I sometimes need to connect a simulator to a real device, so I need to use COM port.
On Wed, 2 Oct 2019 09:04:31 +0200, pozz <pozzugno@gmail.com> wrote:

>Il 01/10/2019 17:01, Dave Nadler ha scritto: >> On Tuesday, October 1, 2019 at 10:02:20 AM UTC-4, 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. >> >> Why don't you stub the RS485 comms with some kind of network pub-sub layer? >> Perhaps using IP-multicast? >> I don't know offhand of a straight-forward (non-commercial) pub sub library, >> but probably there are a few out there... Maybe DBus? >> I wouldn't use serial comms for simulation. > >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.
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. >
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.)
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?&#2013266080; 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.
On Wednesday, October 2, 2019 at 6:12:10 AM UTC-4, David Brown wrote:
> ... 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.)
Also, Exar make a USB-RS485 converter and drivers; I used these some years back to interface test code to a 485 bus.
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).
>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. 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'. 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.