I was facing a strange issue when debugging a serial communication from a microcontroller on a Linux machine.
I was using this command to print modem communication:
$ cat /dev/ttyUSB0 | hexdump -v -e '/1 "%02X "' -e '/1 "%c\n"' 41 A 54 T 5A Z 0A 0A
The microcontroller was sending “ATZ\r\n” but in the Linux I saw only “ATZ\n\n”, initially I suspected that RTOS NuttX in the microcontroller was converting the “\r” (0x0D) to “\n” (0x0A).
After some low level debug I verified that NuttX was writing “\r” correctly in the serial port’s buffer.
Then I realized the guilt should be the Linux. In fact Linux handles serial port as a TTY interface. It means that Linux will do some post processing of serial data.
Fortunately we can change this behavior configuring the serial port to RAW mode, this way:
$ sudo stty -F /dev/ttyUSB0 raw $ sudo stty -F /dev/ttyUSB0 -echo -echoe -echok $ sudo stty -F /dev/ttyUSB0 115200
Now everything goes fine:
$ cat /dev/ttyUSB0 | hexdump -v -e '/1 "%02X "' -e '/1 "%c\n"' 41 A 54 T 5A Z 0D 0A
2 thoughts on “Configuring Linux’s serial port to raw mode”
The newline behavior is from UNIX. I worked for AT&T until 1983 and worked with UNIX machines – even had access to the entire UNIX source code. I encountered the same issue when interfacing new peripherals. This newline design decision dates back to Ken Thompson and Dennis Ritchie. I suspect that it had something to do with the DEC terminals that they were using, but I don’t truly know the reason. It would be a good history research project.
BTW – by AT&T I’m mean the REAL AT&T that owned Bell Labs, not the new, fake AT&T that is actually the old Southwestern Bell based in Dallas.
Yes in fact this behavior is from old UNIX.
The original “\r\n” idea remounts the “teletype age” that was based on typewriter principles, where you need first to return the carriage and then move to below line.
For a computer I think using two bytes to indicate a new line is a waste of space and time.
I think UNIX idea is right again! 🙂
Unfortunately some modern GSM modems are not prepared to receive just “\n” instead of “\r\n”.