How to connect to a serial port as simple as using SSH?

Question

Is there a way to connect to a serial terminal just as you would do with SSH? There must be a simpler way than tools such as Minicom, like this

$ serial /dev/ttyS0 

I know I can cat the output from /dev/ttyS0 but only one way communication is possible that way, from the port to the console. And echo out to the port is just the same but the other way around, to the port.

How can I realize two way communication with a serial port the simplest possible way on Unix/Linux?

Solution 1

I find screen the most useful program for serial communication since I use it for other things anyway. It's usually just screen /dev/ttyS0 <speed>, although the default settings may be different for your device. It also allows you to pipe anything into the session by entering command mode and doing exec !! <run some program that generates output>.

Solution 2

Background

The main reason why you need any program like minicom to communicate over a serial port is that the port needs to be set up prior to initiating a connection. If it weren't set up appropriately, the cat and echo commands would not do for you what you might have expected. Notice that once you run a program like minicom, the port is left with the settings that minicom used. You can query the communication settings using the stty program like this:

stty < /dev/ttyS0

If you have done it right; after booting the computer and before running any other program like minicom, the communication settings will be at their default settings. These are probably different than what you will need to make your connection. In this situation, sending the commands cat or echo to the port will either produce garbage or not work at all.

Run stty again after using minicom, and you'll notice the settings are set to what the program was using.

Minimal serial communication

Basically, two things are needed to have two-way communication through a serial port: 1) configuring the serial port, and 2) opening the pseudo-tty read-write.

The most basic program that I know that does this is picocom. You can also use a tool like setserial to set up the port and then interact with it directly from the shell.

Solution 3

I found a way using a shell script here that put cat as a background process and a while loop that read the user input and echo it out to the port. I modified it to be more general and it fitted my purpose perfectly.

#!/bin/sh

# connect.sh

# Usage:
# $ connect.sh <device> <port speed>
# Example: connect.sh /dev/ttyS0 9600

# Set up device
stty -F $1 $2

# Let cat read the device $1 in the background
cat $1 &

# Capture PID of background process so it is possible to terminate it when done
bgPid=$!

# Read commands from user, send them to device $1
while read cmd
do
   echo "$cmd" 
done > $1

# Terminate background read process
kill $bgPid

Solution 4

If UUCP is installed on the system, you may use the command cu, e.g.

 $ cu -l /dev/ttyS0 -s 9600

Solution 5

Try http://tio.github.io

"tio" is a simple TTY terminal application which features a straightforward commandline interface to easily connect to TTY devices for basic input/output.

Typical use is without options. For example:

tio /dev/ttyS0

Which corresponds to the commonly used options:

tio --baudrate 115200 --databits 8 --flow none --stopbits 1 --parity none /dev/ttyS0

It comes with full shell auto completion support for all options.

View more solutions

Comments

[Admin]

Great answers people!. Unfortunately no one seem to fully fit my purpose when working with embedded systems with a limited set of commmands. I did however find another way using a shell scrip which I add as one of the answers to my question.

[Hugo]

+1 for screen! Also, see: serverfault.com/q/81544/11086

[Lekensteyn]

See also noah.org/wiki/Screen_notes#using_screen_as_a_serial_terminal and the manual page stty(1), I had to add extra options (e.g. parity) for it to work.

[Lekensteyn]

feels ashamed I wrongly connected the TX/RX :o

[Michael Burr]

picocom also will let you connect to a serial port without reconfiguring it (--noinit) and will let you exit without restoring the serial port configuration (--noreset or use Ctrl-A/Ctrl-Q to quit picocom). I've found picocom to be much easier to use than minicom. For reasons I haven't figured out, minicom will sometime simply not send or receive data on a port that worked moments before or that picocom has no trouble with. It's probably some arcane configuration option, but whatever it is I can't figure it out (and this behavior has happened on more than one machine).

[Scott - Слава Україні]

(1) #!/bin/sh is ignored if it isn’t the first line of the file.  (2) Seriously?  You’re using 1 to specify even parity and 2 to specify odd?  (3) It’s conventional to have a “usage” or “help” message that documents all the parameters, not just the mandatory ones.  (4)  You should always quote your shell variable references (e.g., "$1", "$2", "$3", "$4", "$stopb", "$par", "$bgPid", and even "$?" and "$!") unless you have a good reason not to, and you’re sure you know what you’re doing.

[ihatetoregister]

@Fritz Nice find! So if I get this right, the background process would never be killed because $? doesn't seem to expand to anything right?

[Fritz]

@ihatetoregister: Not quite correct. The background process is killed, but not for the reasons one might expect. $? expands to the exit code of the last non-background command (in this case stty -F $1 $2), so it expands to 0 when there was no error. Thus, the last line becomes kill 0 which in turn seems to kill the current shell and all its children (it behaves differently in interactive shells I believe). For all the details see the following explanation: unix.stackexchange.com/questions/67532/…

[Fritz]

Howerver, the real gotcha in your script is that the background process is only killed if you press Ctrl+D to end your script, because that ends the while loop cleanly. If you kill it with Ctrl+C or with the kill command, then the cat process stays alive. To fix that you would need to use the trap command to execute kill $bgPid when the shell exits, like my script down below does. Honestly, I wouldn't even mind if you just added my whole script to your post. I tried to do that, but the edit was rejected.

[Chris Halcrow]

Could you please clarify where the connect comes in, as this is commented out in your answer

[ihatetoregister]

@ChrisHalcrow It's just what I choose to name the script. See the usage example.

[cardiff space man]

I find that Putty under Linux doesn't paste "the clipboard" (what you copy with control-C), but it will insert "the primary selection" (what you have currently selected in some program) with middle-mouse. Likewise you can select characters in Putty's screen to define the primary selection. But if I want text from a Putty screen to transfer to some VM, I need it to be the clipboard, so I have to use an intermediary program to receive the text from the main selection and then copy it to the clipboard.

[Ciro Santilli Путлер Капут 六四事]

screen is awesome, but I don't think it it simpler than minicom :-)

[Admin]

@CiroSantilli刘晓波死六四事件法轮功 - Screen may be not simpler than Minicom but because I already use Screen, for me it is less complexity to do my serial stuff with Screen too eliminating the need for Minicom totally.

[Admin]

If you try to switch the tabs in your browser or your virtual desktops with ctrl-a-commands you begin to realise being a Screen addict! ;-D

[Kohányi Róbert]

I'm using msys2 on Windows and you can install tio with pacman -S tio because it's among the available packages by default. screen, picocom, etc. are not. Thanks!

[iman]

Use ~^D or ~. to exit.

[user2561747]

+1 for picocom! I found that I wasn't able to write commands to the serial device without the correct line endings: I needed to use --omap crcrlf --echo options