Send raw to serial with 0xA data

Question

I try sending to serial port someone string echo -ne '\x55\x90\x17\x01\x00' > /dev/ttyACM0, usb monitoring show me this data:

ffff8c957536f540 2932377867 S Bo:2:005:3 -115 5 = 55901701 00

this working properly, all data send it in one string, device accepted command. but if data include 0xA, its always split data into 2 lines. for example:

echo -ne '\x55\x90\xa\x01\xde' > /dev/ttyACM0

usb monitoring show me this:

ffff8c957536f540 3046024649 S Bo:2:005:3 -115 3 = 55900a
ffff8c957b719000 3046024661 S Bo:2:005:3 -115 2 = 01de

string split to 2 lines, of course, the device has ignored this command.

My question, how to send any data with included 0xA. This something wrong with stty, I spend a lot of time but still do not the success. or please confirm, this does not possible to send 0xA in mid of string from Linux console to a serial port.

Answer 1

This looks a lot like an issue that was discussed on Bash's mailing list during the past couple of days. Bash uses line buffering for output, so a printf or echo that contains newlines in the middle calls the write() system call for each "line".

$ strace -ewrite bash -c 'echo -ne "foobar"' >/dev/null 
write(1, "foobar", 6)                   = 6
+++ exited with 0 +++

$ strace -ewrite bash -c 'echo -ne "foo\nbar\n"' >/dev/null 
write(1, "foo\n", 4)                    = 4
write(1, "bar\n", 4)                    = 4
+++ exited with 0 +++

If the device you're writing to is sensitive about that, it may result in more than one distinct packet further down the line. A serial connection or a TCP stream^(*) shouldn't care, but something more like UDP packets would.

It appears you can't work around this in Bash, but you can use some other utility that doesn't split the output to lines in the middle of a single output command. All other shells I tested print the above in one write() call, and so does the external printf utility from GNU coreutils. It should be in /usr/bin/printf on Linuxes, so /usr/bin/printf '\x55\x90\xa\x01\xde' should work:

$ strace -f -ewrite /usr/bin/printf '\x55\x90\xa\x01\xde' >/dev/null 
write(1, "U\220\n\1\336", 5)            = 5
+++ exited with 0 +++

Alternatively, you could pipe the output through dd, which by default buffers the output to blocks of 512 (apart from the last), which should be enough in your case. (dd obs=512 to be explicit about it.)

_{(* TCP connections shouldn't care, but the question on the mailing list was exactly about printf ... > /dev/tcp/.... The distinct writes can affect the segmentation of the TCP stream, and apparently some buggy hosts care about that.)}

Answer 2

That doesn't mean that the data is "split" into 2 lines.

In short, you're writing the data correctly, it's the way you display the data that appears you have "two lines."

0xA is the ascii "linefeed"character, which is is the Unix/Linux "newline" character ('\n').

When you look at the data from USB monitor, the terminal (or almost all other text display software in Unix/Linux), will move the display to the next "line". On most terminals, this means that the display driver will insert a carriage return with the linefeed.

A better way to verify your data is to capture the data from USB monitor and pipe it to the od command, with the option to view hex characters (od -t x1). Then you should see the actual data that you've written.

Answer 3

Some tty devices keep LF to CRLF conversion output on. You can disable it using:

stty -onlcr -F /dev/ttyACM0

or, for strict POSIX stay

stty -onlcr < -F /dev/ttyACM0

or pure RAW mode try:

stty raw -echo -F /dev/ttyACM0

and then try

echo -ne '\x55\x90\xa\x01\xde' > /dev/ttyACM0