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?

  • You can have stty dump the settings established by screen for future use. See its man page for details. Commented May 31, 2016 at 8:11
  • 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. Commented May 31, 2016 at 20:10

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

  • 1
    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! Commented May 31, 2016 at 20:00
  • 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.
    – jantje
    Commented May 31, 2016 at 21:32
  • 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 :) Commented Jun 2, 2016 at 6:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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