I’m working on a Linux project to route data between devices attached to a computing platform via serial lines. There is one app that maintains a socket and is responsible for writing socket data to the serial port. The other app reads the serial port, determines which socket(s) the date needs to go to, and sends the data strings on their respective merry ways. Each process, 2 to a port, is unidirectional.
When I was actively debugging, this worked quite well. Now that I’m trying to get it to work IRL for a demonstration, I’m having all kinds of trouble with port contention, and it’s not working. My frustration is mounting.
Anyone know how I can get this to work?
Why is this two different apps?
It seems simpler in my mind to implement, along with a heaping helping of VMS experience where I could explicitely share the ports in this manner. It never occured to me that there were no similar options in Linux.
I’m mulling right now the mechanics of combining the two into one process without imposing significant latency in the end-to-end delivery times.
Can’t you just have one application running two threads?
Different, but related, questions.
It appears to me that a large part of the problem is that the serial ports are left open when I kill the processes, and when I restart, the processes fail because they can’t open a zombie port.
Q1: Is there a way I can seize a zombie port and slam it shut during startup, and before I actually start the processes?
Q2: Is there a function similar to get_pid() that can get me a pid based on a known name of a process?
We always used the ps command (possibly with a “-Af” switch), piped through grep to get a particular line, then picked out what was needed from that line (e.g., using cut).
It’s been awhile since I’ve done low-level serial port stuff, so I’m looking into it. If I find anything, I’ll post it, but I have to admit that my programming was much higher level – solutions concerning hardware were generally ad-hoc and done using command-line scripts called from within a program. I’m not sure if this’ll help, but you might want to look at setserial to close/reset the port (someone in our lab used it to figure out that the default settings to open a laser range finder was rendering it inoperable, then reset the port configuration). Perhaps that’ll give you a place to start looking, perhaps not.
It looks like socat might provide the functionality you need (descriptive article from linux.com here).
I’d never heard of it before, but it’s already installed on my Debian system (that is, I didn’t explicitly install it), so my guess is that it’s pretty widely available.