Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
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. –  ihatetoregister Oct 18 '11 at 10:15

6 Answers 6

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
share|improve this answer

BTW, the putty package (which does run on Linux) does include serial support.

share|improve this answer

It depends on what you want to do. Do you want to run a shell or applicaiton interactively from the terminal, connect out to another computer over the serial line, automate communication with a device over a serial port?

If you want bidirectional communication then I presume you want something interactive with a human on the terminal. You can configure the system to allow logins from a terminal over a serial port by seting up a getty(1) session on the serial port - getty is the tool for setting up a terminal and allowing logins onto it. Put an entry in your inittab(5) file to run it on the appropriate serial port on a respawn basis.

If you want to connect to a device and initiate automated two way conversations then you could see if expect will get you what you want. Use stty(1) to configure the port to the right parity, baud rate and other relevant settings.

If you want to communicate interactively with another computer over the serial port then you will need terminal emulation software. This does quite a lot - it sets up the port, interprets ANSI or other terminal command sequences (ANSI was far from being the only standard supported by serial terminals). Many terminal emulators also support file transfer protocols such as kermit or zmodem.

The ins and outs of serial communications and terminal I/O are fairly complex; you can read more than you ever wanted to know on the subject in the serial howto.

share|improve this answer

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>.

share|improve this answer
    
+1 for screen! Also, see: serverfault.com/q/81544/11086 –  Josh Oct 14 '11 at 13:16
    
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 Mar 20 '12 at 22:22
    
feels ashamed I wrongly connected the TX/RX :o –  Lekensteyn Mar 20 '12 at 22:50

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 would not for you as expected. Notice that once you run a program like minicom, the port is left with a a set of settings that minicom used. You can query the communication settings using stty program like this:

stty < /dev/ttyS0

If you do it right after booting (before running any program like minicom), the communication settings will be at their defaults, which is probably different from what you need to use for your connection. In this situation, cat-ing from or echo-ing 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, what needs to be done in order for two-way communication through serial port, is 1) configuring the port 2) opening the pseudo-tty read-write. The most basic program I know of 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.

share|improve this answer
    
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). –  Michael Burr Oct 24 '13 at 21:11

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

 $ cu -l /dev/ttyS0 -s 9600
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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