How do I read from /dev/ttyACM0 in Linux without a terminal emulator?

Question

I just bought an Arduino Due and I'm having trouble reading from a simple serial IO program.

I have a SparkFun RedBoard which is like an Uno. With that, I just ran a "stty" command to configure the baud rate and other terminal settings, and then I could do "cat /dev/ttyUSB0". Actually I have a C++ program which opens "/dev/ttyUSB01" and reads from it like a normal file.

Now, with the Due, the device is "/dev/ttyACM0" and there have been a few snags. One of them is that after programming the Due, and running stty, I have to open /dev/ttyACM0 using the screen program:

screen /dev/ttyACM0 115200

and then kill screen, before cat /dev/ttyACM0 will work. Otherwise, cat prints out one byte and exits; rarely it prints out 10 bytes or a line, or sometimes it prints nothing.

This is a bit annoying and I can't figure out what screen is doing to the device which I can't seem to accomplish using stty. My stty command is:

sudo stty -F /dev/ttyACM* 115200 -parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts \
-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 -flusho -extproc

I got this by running stty -a < /dev/ttyACM0 after using screen to initialize as above.

I thought it might have something to do with serial auto-reset, so I tried using a resistor between 3.3V and RESET, but this did not fix the problem.

I should note that cu from the uucp package is able to read continuously from /dev/ttyACM0, but unlike screen it does not leave the terminal set up in such a way that a subsequent cat command will work.

$ cu -l /dev/ttyACM0 -s 115200
<continuous stream of data>
$ killall cu # (from another shell)
$ cat /dev/ttyACM0 | hexdump -c
<e.g. 7 bytes>
$

With screen, cat would have printed an infinite stream. Any ideas how to accomplish this setup without using screen?

• Chris Stratton: You can have stty dump the settings established by screen for future use. See its man page for details.
• Metamorphic: I thought you'd missed my use of stty -a but then I saw that there's a stty -g ("print all current settings in a stty-readable form"). It doesn't really seem to be documented, but now I see that I can pass the output of stty -g as an argument to stty: stty "0:0:18b2:0:3:1c:7f:8:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0" -F /dev/ttyACM0. This indeed works, where copy-pasting from stty -a didn't work because I missed the min 1 bit. However, I'm glad for @jantje's solution because now I understand what was going wrong and plus I have a readable command-line.

Answer 1

I have had very similar problems with my yun(shields) and I found the stty command to be very crucial for a good working. I use following command and it works with mega and due on the yun

stty -F ${PortName} ${SerialSpeed} raw -clocal -echo icrnl

Since I call these I can redirect from and to /dev/ttyxxx without problems. As far as I can see you mis the raw.

• Metamorphic: That seems to work for me. In fact I narrowed it down a bit: if I just stty -F /dev/ttyACM1 115200 min 1 then it works. The min 1 is part of the definition of stty raw. So I guess the Arduino IDE was putting the terminal into a mode where reads could be non-blocking. I guess I'll use your whole stty command in the future though - the other options look useful, although may I ask why you have icrnl? Anyway, thank you!
• jantje: To be honest.... I think you understand far more about this then I do. I started like you; with running a program (minicom in my case) and then querying stty. After 2 years of playing with the yun shield I ended up with these. I'm happy to see they work for you as well. But it is based on trial and error not on knowing. So I can't answer your question.
• Metamorphic: Well, I'm not sure, but I confess I had a recent issue with a mysterious glitch appearing in my software-oscilloscpe trace around X=13. It went away when I removed the icrnl setting :)