On Linux, I want to send a command string (i.e. some data) to a serial port (containing control characters), and listen to the response (which also usually might contain control characters).

How can I do this as simplest as possible on Linux? An example is appreciated!

  • you should look at this unix.stackexchange.com/a/116705/53092 – Kiwy Feb 26 '14 at 12:28
  • I don't have interceptty installed. – Alex Feb 26 '14 at 12:32
  • 1
    nominating for re-opening - it's not a duplicate as suggested. – peterph Jul 1 '15 at 7:19
  • some people are too stupid they just suggest questions as dublicate. First bother reading the questions and answer. – Denis Oct 4 '18 at 8:14
  • Oh, nuts! So many good answers, and I only have a single check mark to give out ... – Noughtnaut Jan 24 at 16:45

All devices on Unix are mapped to a device file, the serial ports would be /dev/ttyS0 /dev/ttyS1 ... .

First have a look at the permissions on that file, lets assume you are using /dev/ttyS1.

ls -l /dev/ttyS1

You will want read.write access, if this is a shared system then you should consider the security consequences of opening it up for everyone.

chmod o+rw /dev/ttyS1

A very simple crude method to write to the file, would use the simple echo command.

echo -ne '\033[2J' > /dev/ttyS1

and to read

cat -v < /dev/ttyS1

You can have cat running in one terminal, and echo in a 2nd.

If everything is gibberish, then baud rate, bit settings might need setting before you start sending. stty will do that. !! NOTE stty will use stdin as default file descriptor to affect.

Equivalent commands.

stty 19200 < /dev/ttyS1
stty 19200 -F /dev/ttyS1

This might be enough for you to script something and log ? Not sure what you are trying to achieve.

For a more interactive, remembers your default settings approach would be to use minicom it is just a program which does everything I've mentioned so far. (similar to hyperterminal in Windows, you might be familiar).

An intermediate solution, would use a terminal program like screen which will work on a serial device.

screen /dev/ttyS1

man screen man minicom man stty for more information

  • 1
    I'm not getting any output at all. Have any ideas? – JobHunter69 Nov 10 '18 at 1:01
  • Possibly hardware flow control, either switch off with atty command or strap high in serial cable, search for null modem cable. – X Tian Nov 10 '18 at 9:37
  • 1
    # stty -speed 38400 -f /dev/ttyUSB1 returns stty: invalid argument '-speed' – Pro Backup Nov 27 '18 at 20:03
  • 1
    on stty it is -F (capital F) to set the device. Also your speed parameter is wrong. You can use speed to get the baud rate of the port, or ispeed or ospeed (without the minus sign) to set input and output speeds, or just a number to set both input and output speeds, like so: stty 19200 -F /dev/ttyS.... – Paulus May 17 '19 at 14:16
  • Amazing nobody has noticed that before, thank you @Pro Backup I've corrected the example. – X Tian May 17 '19 at 17:24

All you have to do is open two terminals. In the first terminal you cat everything from the device, e.g.

cat /dev/ttyS0

in the other terminal, you can send arbitrary hex characters and text to the terminal e.g. as follows:

echo -e "\x7E\x03\xD0\xAF und normaler Text" > /dev/ttyS0

The echo -e command enables the interpretation of backslash escapes.

One has to make sure of course that (i) the serial settings (speed, word length, flow ctrl, etc) are correct and (ii) the serial device (on the other end) is not blocking.

  • You have answered this 10 mins after I wrote my answer above and you haven't added any further information at all ! – X Tian Feb 26 '14 at 15:24
  • Oh sorry, I did not read your answer completly. I saw that my answer is included in yours, so I will accept your answer as the correct one, as you described just what I have described. – Alex Feb 26 '14 at 16:06
  • I don't know much about COM ports. Could you please explain what does "the serial device (on the other end) is not blocking" mean? Some issue with the firewall? – Sopalajo de Arrierez Sep 13 '15 at 15:55
  • echo -ne '\xFF' > /dev/ttyUSB0 works for me. if someone is having issues make sure the baud rate of your port is the same as the baud rate of your device. – Cheetaiean Jul 9 at 16:48

Programs that talk to serial devices:


or from shell you can do:

stty -speed 19200 < /dev/ttyS0 # sets the speed of the port
exec 99<>/dev/ttyS0 (or /dev/ttyUSB0...etc)
printf "AT\r" >&99
read answer <&99  # this reads just a CR
read answer <&99  # this reads the answer OK
exec 99>&-
  • 1
    yours is an awesome answer that taught me about bidirectional file descriptors. However, are you sure the last line syntax for closing the descriptor is right? I get syntax error. I think either exec 99<&- or exec 99>&- should be used. Or possibly both? – Yankee Jun 22 '19 at 22:48
  • 1
    typo.. you are right – Zibri Jun 24 '19 at 5:58
  • speed is not recognized as a valid argument on ubuntu stty -F /dev/ttyS0 9600 cs8 -cstopb -parenb – user3455897 Jul 7 '20 at 17:45
  • This works great and provided a wonderful solution to my UART dilemma of downloading a file over the UART and providing feedback path to see if it got there successfully. It seems like this solution could also be extended to split a file into chunks, sending each chunk and sending success/failure indication for each chunk. Thank you for posting! Truly appreciated! – DragonSpit Apr 22 at 12:04

This could be a better approach:

stty -F /dev/ttyUSB0 115200 raw -echo   #CONFIGURE SERIAL PORT
exec 3</dev/ttyUSB0                     #REDIRECT SERIAL OUTPUT TO FD 3
  cat <&3 > /tmp/ttyDump.dat &          #REDIRECT SERIAL OUTPUT TO FILE
  PID=$!                                #SAVE PID TO KILL CAT
    echo "R" > /dev/ttyUSB0             #SEND COMMAND STRING TO SERIAL PORT
    sleep 0.2s                          #WAIT FOR RESPONSE
  kill $PID                             #KILL CAT PROCESS
  wait $PID 2>/dev/null                 #SUPRESS "Terminated" output

exec 3<&-                               #FREE FD 3
cat /tmp/ttyDump.dat                    #DUMP CAPTURED DATA
  • This is very good because it automates the process! The only change I would make, which is totally optional, is to confirm the contents received is the same as sent - could be just a count or full on diff. – HiDefLoLife Feb 5 '19 at 19:55

You can read and write to a device simulataneously like so:

cat /dev/cu.usbmodem411 & cat > /dev/cu.usbmodem411

Your message is sent to the second cat from stdin, and the first cat relays the response to stdout, turning your terminal into a chatroom.

To finish up, ctrl-c, then run fg then ctrl-c again.

Not the answer you're looking for? Browse other questions tagged or ask your own question.