No particular protocol is required, the final goal is to be able to use a Hyperterminal / Realterm type program on a Windows PC to read/write on any of the 6 Raspberry4 uart boards
This is valuable information, I didn't know there was a standard for serial port communications via telnet
When you talk about 'client program' exactly what are you referring to?
I know com0com but I thought it used its own protocol to communicate between the various components of the project Do you think you can also use it to communicate with netcat or other program that will be installed on the Raspberry?
I understand the substance of the written code, what I can't do at the moment is how to use it on Raspberry What documents / tutorials to follow to understand how to use the sent code?
The rs232 level is not useful to me I would connect the uart of the Raspberry gpio connector directly to electronics at the 3v3 level Furthermore, the USB ports are not sufficient, of the four available, two remain free (after keyboard and mouse) while the uart devices to write/read are 6 For this reason I am trying to exploit the uart directly from the gpio connector
That's right, se2net on the Raspberry side and then on the Windows side what do I put in it?
This may prove helpful to you:
Crammed with details including the Windows side of things.
-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
Den 2021-01-02 kl. 11:14, skrev RobertoA:
save it to a file and run it with tclsh filename
There is none - since I wrote it for me - unless you mean tcl as a language and in particular file events
I just saw it wasn't complete - this should work (though not tested since I got no serial device)
save it to a file, install tcl if not alredy there (sudo apt install tcl)
and set - below set my_com "/dev/ttyWhatever" set port 6789 to whatever values you need.
Then - when something connects to the tcp/ip port of your choise it is forwared byte by byte to the serial device. and vice versa. whenever the soceket ot serail port becomes readable, it invokes proc pass_through that reads a byte and forwards it unless its a carriage return. those are swallowed - change the if-statement 'if {[string equal "\r" $tmp]}' - in pass_through if it does not apply to you.
run it with tclsh whatever/name/you/gave/it
##### #Associate a tcp/ip port 'port' with a tty 'my_com' # run with tclsh scriptname ##### set done 0 set my_sock 0 set my_com "/dev/ttyWhatever" set port 6789 set ss 0 set debug 1 set config_line {} ###########################
proc gettime {} { return [clock format [clock seconds] -format "%Y-%b-%d %H:%M:%S"] }
###########################
proc dbg {what} { if {$::debug} { puts $what # puts $::error_file_pointer $what # catch {flush $::error_file_pointer} } }
###########################
proc pass_through {from to} { set tmp [read $from 1] ;# read 1 byte at a time if {[eof $from]} { ;# client gone or finished set ::done 1 ;# signal to main loop to let go } else { #do things if {[string equal "\r" $tmp]} { catch {puts "\n[gettime] -> CR received, terminating chars above" 1} } else { catch {puts -nonewline $tmp} catch {puts -nonewline $to $tmp} ;# put it out } } } ###########################
proc accept {sock addr port} { dbg "[gettime] -> start accept from $addr"
set ::my_sock $sock set ::my_com [open $::tty {RDWR}]
# Read channels w/o buffering and in binary mode fconfigure $::my_sock -buffering none -translation binary fconfigure $::my_com -mode $::mode -buffering none -translation binary
# Setup handler for communication on the channels fileevent $::my_sock readable [list pass_through $::my_sock $::my_com] fileevent $::my_com readable [list pass_through $::my_com $::my_sock]
# make sure noone else connects while a session in running catch {close $::ss} dbg "[gettime] -> stop accept" }
###########################
# loop to reopen the listening socket when connection down while {1} { dbg "[gettime] -> Start listening" set ss [socket -server accept $port] vwait done ; # wait until the connection is closed # clean up after session dbg "[gettime] -> Close this session" catch {close $::my_com} catch {close $::my_sock} }
I remember messing with things in two broad categories.
1) A driver that created a virtual serial port on the client computer, e.g. COM3, Which any standard Windows program could use, e.g. Hyperterminal. 2) A program that spoke the RFC 2217 protocol itself. Think enhanced telnet / PuTTY / etc.I believe #1 / driver type is what you are after.
-- Grant. . . . unix || die
On Sat, 2 Jan 2021 11:08:27 +0100, RobertoA declaimed the following:
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..
The "screen" command, alone, doesn't seem that helpful -- at least, most examples seem to assume one is just toggling shell sessions on the device; I've only found one example claiming to open connected to a serial port.... Ah, wait
Similar process with "minicom"... SSH from host to R-Pi, start minicom, connect to desired UART/serial port.
If using something like PuTTY on the Windows box, you could maybe even provide a start-up command to be run when the connection is made -- that command could be to start one of the above commands automatically (you'd have a PuTTY configuration defined for each target serial port, so clicking on the configuration in PuTTY session control menu would connect to the R-Pi, run the appropriate connection command for the port, ...
-- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
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 connect to a modem to call a bank / CC company / etc. or needs to connect to industrial equipment.
Conversely, drivers that create a virtual serial port that communicates across the network will work for these types of special case scenarios.
-- Grant. . . . unix || die
On Sat, 2 Jan 2021 13:31:25 -0700, Grant Taylor declaimed the following:
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 commandNote: 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
-- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
And the COM port driver allows a simple terminal program to use the remote serial ports.
Six different instances of the COM driver pointed to each remote serial port.
Then HyperTerm / ProComPlus / Quicken / pager program / fax program could use COM1, COM2, COM3, COM4, COM5, COM6 at their discretion. Just like they would for a hardware COM port.
You could even have Windows Routing and Remote Access Server provide Dial Up Networking on the aforementioned COM ports.
The pager / fax / banking program that need to connect to a modem on a serial port are the exact type of programs that can't / won't use something like minicom / cu on a remote machine.
That won't work when the time clock / attendance application needs to connect to the time clocks in the factory over a serial port.
That is untennable in a business environment. Especially when there is an option to install a virtual COM port that connects across the network and allows the application to run the same way that it has for the last
15 years.
Nope.
It's about more than simply talking to the serial port. It's about /how/ you talk to the serial port and /where/ you talk to the serial port.
Things like the time clock application or the fax software running on Windows (where) need (as in they have no choice in the matter) to talk to a local (to Windows) COM port (how).
GUI applications work perfectly fine with the virtual COM port.
So now you want to add even more complexity -and- code development into the process.
You're selling the virtual COM port for me.
1) Install and configure the remote serial port server. 2) Install and configure the virtual COM port driver. 3) Reconfigure the existing program to use the new COM port. 4) Profit!!!Not really.
It's quite like using an IP port for a printer. It's been quite standard for the better part of 30 years. Quite easy to do too.
Which seems to be a varient of what I'm describing.
-- Grant. . . . unix || die
o/~ Talking to myself in public o/~
On Sun, 03 Jan 2021 12:27:42 -0500, Dennis Lee Bieber declaimed the following:
This might almost be a built-in...
Node-Red is available for the R-Pi. There appear to be modules available to create a web-page "dashboard". So... It should be possible to define a "flow" for text inputs to a serial port and serial port to an output (for any responses).
I'm not familiar with Node-Red, and for some reason was unable to get said dashboard to display an input item -- I did have a text input node connected to a serial port (send/receive port node -- there are also send-only and receive-only nodes).
This would be simpler than a full-fledged web app and server configuration, since the flows are defined by drag&drop nodes.
-- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.