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.

| improve this question | | | | |
  • 1
    What shell are you running? – ilkkachu Sep 24 '18 at 4:17
  • 1
    Have you done stty -F /dev/ttyACM0 raw -echo ? – meuh Sep 24 '18 at 8:06
  • of course, and one million another stupid combination parameter has been tried with stty. sorry not answered about shell, Linux 4.9.30 #1 SMP Sat Aug 26 18:26:45 AEST 2017 x86_64 GNU/Linux, bash – Victor L Sep 24 '18 at 8:09

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

| improve this answer | | | | |
  • first thanks for try to help me. I use printf before, of course, had a similar result to echo command, not work with 0xa in the middle. what I try to say, the problem not in echo or printf or another utility, the problem in STTY, from this point I have a question, how to "fix" stty, it's possible to use something another and does not involve stty when sending to the serial port? or, change 0xa in STTY to another byte, for example to 0XFF, I do not send 0xff in my data.in short story, the problem in STTY, how to fix? – Victor L Sep 25 '18 at 4:32
  • @VictorL, what happens if you run (printf '\x55\x90\x17'; printf '\x01\x00') > /dev/ttyACM0 ? Does it work in the same way as the same in just one printf, or does it also get split into two the way you didn't want it to? – ilkkachu Sep 25 '18 at 7:47
  • not working, the problem in stty – Victor L Sep 25 '18 at 7:54
  • @VictorL, how do you know the problem is in stty? – ilkkachu Sep 25 '18 at 8:17
  • It’s simple, when I forward data to the file from echo or printf, I have correct data in file. But when I forward data to the file from USBmon, this data after stty has been involved, and checking data in the file, string with data not correct. – Victor L Sep 25 '18 at 9:00

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.

| improve this answer | | | | |
  • ok, maybe the report is wrong, but the question still in, how to send raw string data to a device, when data include 0xa in the middle of the string. – Victor L Sep 24 '18 at 6:13
  • Ok, I have enough information, and I believe someone really smart help me. first when I send this string \x55\x90\x0b\x01\x85, this converted to 35 35 39 30 30 62 30 31 20 38 35, but, when I send this string \x55\x90\x0a\x01\x85, this converted to 35 35 39 │ 30 30 61 0A │ 66 66 66 66. in first variant b has been converted to 62, this is correct, in second variant A has been converted to 61 this is as well correct, but after this has been added real code 0A, and of course after this 66 66 66 66. stty, Linux, driver?, I do not know who is added this 0xa, but how to remove this??????????? – Victor L Sep 24 '18 at 7:03
  • 1
    This answer does not match the output given in the question, where clearly the USB monitoring program is not printing a Line Feed, but is already dumping the character data in hexadecimal in two groups of 6 and 4 hex digits instead of one 1 group of 10 hex digits. ikkachu's unanswered request for clarification is actually very pertinent. – JdeBP Sep 24 '18 at 7:46
  • where did you see answer mate? only flood with smart face it's my second thread on this forum and probably last, first was here stackoverflow.com/questions/52438785/send-to-serial-x0a – Victor L Sep 24 '18 at 8:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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