6

I'm trying to multiplex access to a serial port on linux. I'm working with an embedded system that have only one serial port and it would be nice to have more than one process talking to it.

The common use case is to have:

  • One main program running tests (sending commands and receiving output);
  • Another logging all serial port activity;
  • An user terminal open to send additional commands and/or perform post morten analysis after some error during the tests.

First, I made a simple python script to open n pseudo terminal pairs (plus the serial port) and used a poll statement to direct input/output to the right places:

# Removed boiler plate and error checking for clarity

##### Serial port setup
ttyS = serial.Serial(device, baudrate, width, parity, stopbits, 1, xon, rtc)
ttyS.setTimeout(0) # Non-blocking

##### PTYs setup
pts = []
for n in range(number_of_slave_terminals):
    master, slave = os.openpty()
    # Print slave names so others know where to connect
    print >>sys.stderr, 'MUX > fd: %d pty: %s' % (slave, os.ttyname(slave))
    pts.append(master)

##### Poller setup
poller = select.poll()
poller.register(ttyS.fd, select.POLLIN | select.POLLPRI)
for pt in pts:
    poller.register(pt, select.POLLIN | select.POLLPRI)

##### MAIN
while True:

events = poller.poll(500)

for fd, flag in events:

    # fd has input
    if flag & (select.POLLIN | select.POLLPRI):
        # Data on serial
        if fd == ttyS.fd:
            data = ttyS.read(80)
            for pt in pts:
                os.write(pt, data)

        # Data on other pty
        else:
            ttyS.write(os.read(fd, 80))

This approach works very well if every pty is connected. If there is some unconnected pty, eventually its buffer fills up and it blocks on write. Seems like I need to either know which slaves are connected or some kind of on demand pty opening.

I found a neat trick on this question, on which the guy needs to do just the reading from the serial port part, so I adapted my script:

##### Serial port setup
ttyS = serial.Serial(device, baudrate, width, parity, stopbits, 1, xon, rtc)
ttyS.setTimeout(0) # Non-blocking

##### PTYs setup
pts = []
for n in range(number_of_slave_terminals):
    master, slave = os.openpty()

    # slaves
    print >>sys.stderr, 'MUX > fd: %d pty: %s' % (slave, os.ttyname(slave))
    os.close(slave) # POLLHUP trick

    # masters
    pts.append(master)

##### Poller setup
reader = select.poll()
writer = select.poll()

reader.register(ttyS, select.POLLIN | select.POLLPRI)
for pt in pts:
    reader.register(pt, select.POLLIN | select.POLLPRI)
    writer.register(pt, select.POLLIN | select.POLLPRI | select.POLLOUT)

def write_to_ptys(data):
    events = writer.poll(500)

    for fd, flag in events:

        # There is someone on the other side...
        if not (flag & select.POLLHUP):
            os.write(fd, data)

##### MAIN
while True:
    events = reader.poll(500)

    for fd, flag in events:

    if flag & (select.POLLIN | select.POLLPRI):
        # Data on serial
        if fd == ttyS.fd:
            write_to_tty(ttyS.read(80))
        # Data on other pty
        else:
            ttyS.write(os.read(fd, 80))

Which works, but uses 100% of the CPU because the reader poll is flooded with POLLHUP events.

I imagine I could get what I want if I used TCP sockets instead of pseudo terminals. The downside is that I would have to modify all other scripts that already work with terminals to use sockets (I know I can use socat, I just want something simpler). Besides, there's all that networking overhead...

So, any ideas?

I don't mind using other tools, as long as it's simple to setup. I also don't mind using other languages, I just like Python the most.

Community
  • 1
  • 1
Marcelo MD
  • 1,769
  • 1
  • 18
  • 23
  • 1
    The idea of muxing access to the serial port seems like a bad approach. I have done similar things on embedded platforms. Rather than have multiple procs use the serial port, write a single proc that only reads and writes the port and provides a data interface to other users via sockets. It's much easier to deal with a socket interface in all the clients and eliminates all the crazieness with trying to mux access to the port. – TJD Sep 20 '12 at 18:32
  • Probably better to just have the single pty, but use `screen` or `dtach`. – twalberg Sep 20 '12 at 19:00
  • @TJD: That's the general idea. Only I figured it would make sense to use pseudo terminals directly and bypass the network layer. Also, we already have a lot of test scripts which point to '/dev/ttyS0' or something like that. I figured it would be less of a chore to simply make them point to '/dev/pts/xyz'. – Marcelo MD Sep 21 '12 at 15:41
  • @twalberg: Any hints of how I would do that? I lost a few hours yesterday and couldn't find a way to make more than one window point to my serial port. – Marcelo MD Sep 21 '12 at 15:43
  • After I wrote that, I realized your embedded system may not have `screen`, but if it does, you basically run it on the embedded system, through your one terminal connection (`minicom` or whatever you use), and it allows you to run multiple virtual terminals that you can switch between with keystroke commands (also create/destroy virtual screens and many other commands). – twalberg Sep 21 '12 at 15:52
  • I see... Unfortunately I'm not able to run screen on my system. I'm either running commands on it's own user interface (no access to a shell) or watching for bugs during the boot process. Thanks a lot =) – Marcelo MD Sep 21 '12 at 21:53

1 Answers1

6

In the end I wrote a simple TCP server, just like I said I didn't want to... It works really well though. It uses the same general architecture as the code on the question but with TCP sockets instead of pseudo terminals.

I posted it here in case anyone wants to use it.

To call it:

md:mux_serial> ./mux_server.py --device /dev/ttyS0 --baud 115200 --port 23200
MUX > Serial port: /dev/ttyS0 @ 115200
MUX > Server: localhost:23200

I'm using socat on another terminal to access the port directly...

md:~> socat -,raw,echo=0,escape=0x0f TCP4:localhost:23200

...or to create a pseudo terminal to use inside scripts that require those:

md:~> socat -d -d pty,raw,echo=0 TCP4:localhost:23200
2012/10/01 13:08:21 socat[3798] N PTY is /dev/pts/4
2012/10/01 13:08:21 socat[3798] N opening connection to AF=2 127.0.0.1:23200
2012/10/01 13:08:21 socat[3798] N successfully connected from local address AF=2 127.0.0.1:35138
2012/10/01 13:08:21 socat[3798] N starting data transfer loop with FDs [3,3] and [5,5]
Marcelo MD
  • 1,769
  • 1
  • 18
  • 23