1

Is it possible to have multiple processes doing IO on the same /dev/ttyUSBx device simultaneously? From the testing I've done it seems that the last (most recent) process to open the handle for read gets the output. When this process exits the next most recent process gets the output again.

Start process A - read output from port
Start process B - read output from port. Process A stops reading.
Stop process B - process A starts reading again.

Is there a param for the connection that would permit both to get the output? The docs make it look like one could fork the original process but I rather need one long running and multiple separate (shorter lived) jobs.

ethrbunny
  • 10,379
  • 9
  • 69
  • 131
  • 1
    Probably not. You'd need some kind of mux. Otherwise how would the data get routed? The DTR and RTS might also be in an inconsistent state. Further, with no process reading the port (for some interval) - where would any data received go? – Elliott Frisch Jun 03 '14 at 21:17
  • How do the processes hand off control of the port? They can't all just read simultaneously because you'd have no idea which process got which bytes. – Jim Garrison Jun 03 '14 at 21:17
  • Possible duplicate - http://stackoverflow.com/questions/1605721/faking-an-rs232-serial-port – ChrisF Nov 15 '15 at 21:48

2 Answers2

6

It would be unusual on any operating system for multiple processes to be able to share a serial-based device like that.

What you want is for process A and B to "subscribe" to process C. Process C reads the device and publishes what it read to the subscribers. The communication channel could be any arbitrary IPC mechanism that works for you, like a pipe, message queue, or socket.

This is commonly called the Publish–subscribe pattern.

indiv
  • 17,306
  • 6
  • 61
  • 82
0

One way to get around the fact that only one process can read from a specific serial (COM) port at a time, is by using virtual COM ports.

Faking an RS232 Serial Port

Described in the above post, the software lets you create virtual COM port pairs on windows. Virtual COM pairs work in a way that when you send data trough COM-A, it will be received on COM-B and vice versa.

In turn this allows you to do the following in your program:

  1. Listen for data on a real COM port (Process 1)
  2. Read from a real COM port (Process 1)
  3. Store what you read (Process 1)
  4. Send the stored data on trough a virtual COM port pair (Process 1)
  5. Listen for incoming data on virtual COM port pair (Process 2)
  6. Read, store and use the received data (Process 2)

This way you can use the data that came trough the real COM port in both processes, without running into the problem of one process blocking the other from reading the COM port. You can use the same steps in reverse to write data back to the real COM port from process 2. The only down side of this is that there will be a short delay for process 2 to receive or send the data.

I'm using this solution in a situation where I need to intercept and process data from a COM port, that another application is connected to. So I simply connected the application to a virtual COM port to which my process is forwarding the original data received from a real COM port.

Hope this helps.

NOTE: The above program works for Windows, not sure if there is a version for Linux, but maybe you can find something similar for Linux.

Community
  • 1
  • 1
ak93
  • 1,135
  • 16
  • 27