On Sat, 2 Jan 2021 13:31:25 -0700, Grant Taylor
 declaimed the following:

>On 1/2/21 12:48 PM, Dennis Lee Bieber wrote:
>> Since you imply plain text I/O, the simplest route would probably be to
>> SSH into the R-Pi, and then use a command line terminal program on the
>> R-Pi to connect to the specific UART(s) -- rather than try to create
>> a terminal server on the R-Pi exporting virtual com ports on Windows..
>
>This may be a simpler solution.  But it often falls quite short of other
>solutions.  Particularly when software is running in a VM that needs to

 But the OP explicitly stated the use of a simple terminal program
(though HyperTerm is ancient and $$$, since the light version is no longer
available on Windows... TeraTerm and PuTTY in serial connection mode might
do).

 My approach would probably start with:

* Take out the Windows box first -- assume keyboard/mouse/monitor
connected to R-Pi.
 How would the OP handle the 6 serial ports from this configuration?
  Open 6 shell windows/xterm and run minicom/cu in each (I presume
they expect to receive some status back from the end devices in response to
any commands sent, otherwise a simple "echo command > serialport" would
maybe suffice and only use one shell window/xterm). Too messy? Open one
shell window/xterm with 6 tabs, each tab running minicom/cu.
  Create a custom application (Python with wxPython/Python
GTK/Tkinter...) with input and response widgets, and [send] button?

* Don't have keyboard/mouse/monitor on the R-Pi?
 Configure the R-Pi VNC server. Install VNC client on the Windows box.
Connect to R-Pi using VNC client.
  One now has a window on the Windows box that looks just like the
monitor did in the previous option, and the same serial port handling is
available (minicom/cu in shell window/tab) or custom application.

* VNC too much overhead?
 Install (if needed) "screen" on the R-Pi. Use PuTTY to SSH into the
R-Pi. Start "screen" as a shell (NOT the option for direct connect to
port). Run minicom/cu on first serial port. Use screen escape sequence to
create a second "window", run minicom/cu on second serial port; repeat
until all six instances are running. Now user screen escape sequences to
switch from serial port instance to instance.
  Of course, if no responses are expected from the end devices, a
single PuTTY session without screen would suffice, using the "echo command
> serialport" operations.
  Note: GUI applications need not apply (though a custom application
using text-only curses that handles all 6 serial ports at once is feasible)

* Screen escapes too messy? Text-only too ugly?
 Run a web-server on the R-Pi (nginx?). Create a web-app (flask/django,
PHP?) which presents a form with 6 sections (one for each serial port, each
section has a command input field, and a response output field).
  The most basic form would require a submit button, probably using
"GET" and the web-app would extract the sent command(s), deliver them to
the corresponding ports, collect return status (timeout?), then
refresh/resend the form with now empty input fields but populated response
fields.
  Better might be to have the form use AJAX to dynamically send
commands as entered, and receive responses for each port as they become
available, instead of undergoing full page refreshes.


 Creating VCPs seems fraught with difficulties. First, one needs a
"discovery" mechanism (for USB adapters, that is the USB device enumeration
system, which discovers newly connected adapters, queries them for
capabilities [serial port using xyz chip-set], searches registry for
chip-set specific driver [or goes on-line to find one], creates VCP
connected to adapter at address mno, assigns COM port number [and that
number may change if the adapter is moved to a different USB port]). For a
device on the net? Either the discovery module is hard-coded for a specific
R-Pi, and "pings" the network looking for it, and the R-Pi is running a
daemon that collects/distributes network packets, while the discovery
module creates VCPs that identify specific network port connections (and
how does one ensure the COM port numbers make logical sense)... OR the
discovery module is a passive listener, and the R-Pi broadcasts an
announcement that it has a serial port -- which any computer on the net
with a listener could respond to by sending back "I want it" response, and
then setting up a VCP talking to that handler process on the R-PI -- repeat
for each port.

 Which leads us back to something like
https://www.eltima.com/products/com-port-redirector/ (which, strangely,
appears to be the same as
https://www.eltima.com/products/serial-over-ethernet/ with a different
name). One runs server side on the R-Pi (suspect one has to build from
source, they likely don't have an ARMHF build), and client side on Windows
to create the VCPs.




--
 Wulfraed                 Dennis Lee Bieber         AF6VN
 wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05