Serial Port Tips for Linux

From rdiez's Personal Wiki
Jump to: navigation, search

Addressing a Serial Port

Built-in serial ports tend to get the same device filename everytime, like /dev/ttyS0 for the first one, /dev/ttyS1 for the second one, and so on.

However, USB virtual serial ports get a different filename each time, depending on the kind of device and the order with which the USB ports are connected to the system. Typically, such device filenames look like /dev/ttyACM0 or /dev/ttyUSB0, but such names are often unpredictable.

You have several options:

  • Manually inspect the tty* files under /dev, in order to find out which one gets created when a particular USB device is connected.
  • Use a filename under /dev/serial/by-id or /dev/serial/by-path.
  • Use a script like FindUsbSerialPort.sh in order to find a USB serial port filename by manufacturer name, serial number, etc.
  • Write a UDEV rules file that assigns a fixed filename to your particular USB device.

If you are using many USB serial port adapters at the same time, finding out which one is which can be time-consuming. The following command prints the associated filename whenever you connect or detach a serial port. Note that, on Ubuntu/Debian, you will need to install package inotify-tools beforehand, which provides the inotifywait tool the following command uses:

 DIR="/dev/serial/by-path" sh -c "inotifywait --monitor --event create,delete --format \"%:e \$DIR/%f\" \"\$DIR\""

The "sh -c" and the \$ extra quoting above are just a trick, so that you can specify the directory to watch at the beginning of the line using a single, temporary variable for just that command.

Configuring a Serial Port under Linux

Set the default configuration with stty to 9600 bps, 8N1, no flow control:

stty -F /dev/serial_port cs8 -parenb -cstopb -clocal -echo raw speed 9600

 # What the arguments mean:
 #   cs8:     8 data bits
 #   -parenb: No parity (because of the '-')
 #   -cstopb: 1 stop bit (because of the '-')
 #   -clocal: Disable modem control signals (no hardware flow control)
 #   -echo: Without this option, Linux will sometimes automatically send back
 #          any received characters, even if you are just reading from the serial
 #          port with a command like 'cat'. Some terminals will print codes
 #          like "^B" when receiving back a character like ASCII ETX (hex 03).

You only need to configure the serial port with stty if you are going to be using generic file tools like cat, which often fail on serial ports anyway. Other tools like socat or dedicated serial port terminal software can configure all serial port parameters themselves.

Opening a Serial Port

Say you have the following scenario:

  • Your device reacts to single keypresses.
    Therefore, you do not want line editing on the local side, because characters need to be sent straight away.
    An example device would be the Bus Pirate.
  • You want to use a standard text console.
  • You want to terminate the connection when you press Ctrl+C.

You can connect to your device with the following command:

socat -t0  STDIO,raw,echo=0,escape=0x03,nonblock=1  file:/dev/mydevice,b115200,cs8,parenb=0,cstopb=0,clocal=0,raw,echo=0,setlk,flock-ex-nb,nonblock=1

# What the arguments mean:
#
# -t0: When terminating socat with Ctrl+C, do not wait for a short time,
#      but exit immediately.
#
# On the STDIO side:
#   raw: Do not interpret special codes.
#   echo=0: Do not print the input characters locally. The remote end
#           usually does that.
#   escape=0x03: Ctrl+C terminates socat (with an exit code of 0, indicating success).
#                If you wish to pass Ctrl+C to the remote end, you can switch to Ctrl+O
#                with escape=0x0F.
#   nonblock=1: Just in case, specify this on the STDIO side too. See comments on the
#               same parameter on the /dev/mydevice side below for more information.
#
# On the /dev/mydevice side:
#   b115200: The serial port speed.
#   cs8,parenb=0,cstopb=0,clocal=0: The usual 8N1 configuration, see the stty example above.
#   raw,echo=0: matches the configuration on the STDIO side.
#   setlk: Write-lock the whole file, see below for more information on exclusive locks.
#   flock-ex-nb: Similar to setlk, see below for more information on exclusive locks.
#   nonblock=1: I had trouble with an "Aten USB-to-Serial Converter (RS-232)",
#               Model UC-232A. socat did not work, but picocom and others did, and the fix
#               was to specify nonblock, which looks like a reasonable option anyway.
#               Shouldn't all full-duplex, async I/O be non-blocking anyway?
#               I have seen this with a 'ch341-uart' too, so it may not be a device-specfic
#               issue after all.

If the backspace key does not work, try using Ctrl+H instead.

Depending on your device, you may need to add "crnl" to either the STDIO or the tty side, in order to convert the line termination characters properly.

Watch out that socat's address specification requires some unusual quoting. For example, in order to open the following serial port:

 /dev/serial/by-path/pci-0000:00:12.2-usb-0:2.3:1.0-port0

you need to type in Bash the following socat address:

 file:/dev/serial/by-path/pci-0000\\:00\\:12.2-usb-0\\:2.3\\:1.0-port0

The open-serial-port-in-new-console.sh script has a Bash routine that performs such quoting.

Say that you only want to print any data received, with timestamps and hex codes, but not send any data:

 socat -U  STDIO  file:/dev/mydevice,b115200,cs8,parenb=0,cstopb=0,clocal=0,raw,echo=0,flock-ex-nb,nonblock=1  | stdbuf -o0 hexdump -v  -e '/1  "% 6_ad#  "'  -e '/1  "0x%02X "'  -e '/1 " %3u  "' -e '/1 "%_u\n"' | ts '%F %H:%M:%.S'

Option 'setlk' does not seem to work when opening the serial port in read-only mode. This is an example output for the command above:

 2017-02-20 14:28:04.636950      0#  0x02    2  stx
 2017-02-20 14:28:04.637021      1#  0x31   49  1
 2017-02-20 14:28:04.637054      2#  0x32   50  2
 2017-02-20 14:28:04.637073      3#  0x33   51  3
 2017-02-20 14:28:04.637094      4#  0x03    3  etx

Alternatives to socat

Check out script open-serial-port-in-new-console.sh, which will let you comfortably choose any of the tools below when opening your serial ports.

  • picocom -b 115200 -p n -d 8 /dev/serial-port-device
    Exit with Ctrl+A, Ctrl+X.
  • minicom -b 115200 -8 -D /dev/serial-port-device
  • screen /dev/serial-port-device 115200
    Exit with Ctrl+A, '\'.
  • C-Kermit
  • cutecom
  • gtkterm -s 115200 -p /dev/serial-port-device
  • putty -serial COM8 # Only on Windows.
  • plink # Only on Windows.

Printing Timestamps

Here are some alternatives:

  • socat's option -v generates an extra output log to stderr which includes timestamps.
  • Tool ts (see Ubuntu package moreutils) copies stdin to stdout prepending timestams. Usage example:
       unbuffer $COMMAND | ts "%F %H:%M:%.S"
    Unfortunately, if you are using socat, you will have to remove "icanon=0,echo=0" from the STDIO side, which may have unpleasant side-effects.
    As an alternative to unbuffer, you can use stdbuf -o0 .
  • Tool grabserial reads lines from a serial port and writes them to a standard output, optionally prepending timestamps, which allows you to easily time processes, like booting an embedded operating system.

No exclusive lock when accessing serial ports

I was surprised to learn that several Linux processes can open a given serial port at the same time. This usually makes a mess of the data. If you make a mistake and try to use the same port from several concurrent scripts, it may take a while to figure out why the data is getting chopped and mixed up in random ways.

There is no exclusive lock when opening serial port files, like there is under Windows. As far as I know, there is no way to enforce such a protection against concurrent access at system level. If you do know how to achieve that, please drop me a line!

There is a work-around if all processes cooperate. Tool socat implements arguments setlk, which uses "fcntl(fd, F_SETLK, ...)", and argument flock-ex-nb, which uses "flock(fd, LOCK_EX|LOCK_NB)". Interestingly enough, those two file-locking mechanisms seem to be independent from each other, at least under Linux. If a process uses one method, then other processes that use the same method will realise that the file is already locked. However, processes that do not use any locking method will not be affected at all.