I ran into the exact same issue trying to connect to a serial device at 115200 baud. I am running RHEL V5.
uname -a
Gives:
Linux localhost.localdomain 2.6.32-100.0.19.el5
#1 SMP Fri Sep 17 17:51:41 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
After some digging I found this:
sudo screen /dev/ttyS0 115200,cs8,-parenb,-cstopb,echo
or this:
sudo screen /dev/ttyS0 115200,cs8,-parenb,-cstopb,inlcr,onlret,echo
However, as you have pointed out, when the screen command is executed, the echo attribute of the selected serial port (in this case /dev/ttyS0) reverts to
-echo
This can be verified by the command
sudo stty -F /dev/ttyS0 -a
In a separate terminal window.
Furthermore, I discovered that detaching from screen sessions using
ctrl-A d
is a bad idea because you cannot re-attach. Let's take a look at a typical invocation::
[iceman@localhost ~]$ sudo stty -F /dev/ttyS0 echo
[iceman@localhost ~]$ sudo screen /dev/ttyS0 115200,cs8,-parenb,-cstopb,echo
[detached]
[iceman@localhost ~]$ ps aux | grep SCREEN
root 3779 0.0 0.1 78476 2876 ? Ss 11:05 0:00 SCREEN /dev/ttyS0 115200,cs8,-parenb,-cstopb,echo
iceman 3781 0.0 0.0 61152 740 pts/6 S+ 11:05 0:00 grep SCREEN
[iceman@localhost ~]$ screen -ls
No Sockets found in /var/run/screen/S-iceman.
[iceman@localhost ~]$
So the screen session we detached from is still running, but screen -ls shows NADA. While the screen session attached to /dev/ttyS0 is still up, let's take a look at the state of echo (which was set to active above). If we now check the status of /dev/ttyS0 we see that echo has been turned off:
[iceman@localhost ~]$ sudo stty -F /dev/ttyS0 -a
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^H; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 100; time = 2;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke
[iceman@localhost ~]$
and finally, trying other alternatives to re-attach:
[iceman@localhost ~]$ screen -x
There is no screen to be attached.
[iceman@localhost ~]$ screen -r
There is no screen to be resumed.
[iceman@localhost ~]$
This can be the source of much wasted time as a process search for lower case "screen" will turn up nothing!
IMPORTANT: If there are multiple screen sessions on the same serial port, attempts to determine what is going on will have random results, depending on which process "catches" the serial port interrupt.
As you have said Pak, the echo option in screen, for whatever reason, is not being passed through to stty and in fact, regardless of whether you use -echo or echo, stty sets to -echo when called by screen using /dev/ttyS0 as the specified serial port. (I have confirmed this)
I found a solution by using minicom as follows:
sudo minicom -s
Then setting up the serial port under the serial port menu as follows:
A - Serial Device : /dev/ttyS0
B - Lockfile Location : /var/lock
C - Callin Program :
D - Callout Program :
E - Bps/Par/Bits : 115200 8N1
F - Hardware Flow Control : No
G - Software Flow Control : No
Then save as "ser1" and use the command:
sudo minicom ser1
This will launch minicom, which you may then use:
ctrl-A E
to turn on local echo and
ctrl-A A
to append a linefeed to CR terminated ascii arriving at the serial port.
Minicom reports its version as:
Welcome to minicom 2.1
OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
Compiled on Jun 6 2007, 06:02:15.
I hope this helps, and saves at least one other person some time and effort. Who would have thought setting up the equivalent of HyperTerm in Linux would be so painful?