Неожиданные результаты тестирования последовательного шлейфа с использованием echo и cat

17

Таким образом, у меня есть стандартный последовательный порт RS232, который возвращается к себе, просто проводя провод от Tx до Rx. Я тестирую петлю, запустив ее echoи catв двух отдельных терминалах:

cat /dev/ttyS1
echo "hi" > /dev/ttyS1

Моя проблема с выходом. Я ожидал бы увидеть, как один "привет" вернется на терминале с работающей кошкой, но вместо этого я получу это:

hi
[2 newlines]
hi
[4 newlines]
hi
[8 newlines]
hi
[16 newlines]
hi
[32 newlines]
hi

... и так до тех пор, пока я ctrl+ c cat.

После прерывания cat, если я запустлю его снова, он не выдаст «привет», пока я не запустил эхо во второй раз.

Это нормально? Есть идеи, почему я вижу это поведение?

Изменить : под новой строкой я имею в виду ASCII 0x0A. В этом выводе нет возврата каретки.

cat serial-port echo

— Кристина
источник

Может ли это быть вызвано тем, что два процесса открывают одно и то же устройство? Что если вы запустите tip /dev/ttyS1( ~.для выхода) и попытаетесь ввести данные там? Он должен отображаться в вашем терминале, когда провод подключен, поскольку он получает то, что он передал.

— mrb

3

Вы действительно получаете новые строки или пару "возврат каретки / новая строка"? Различие важно на том уровне, на котором вы работаете. Попробуйте "cat / dev / ttyS1> somefile", затем выполните "od -x somefile", чтобы увидеть, какие именно байты выходят из файла устройства TTY. Также выполните команду "stty -F / dev / ttyS1 -a". Прочтите справочную страницу "stty" и посмотрите, что выводит stty, для каждой маленькой настройки. Последовательные порты RS232 довольно сложны.

— Брюс Эдигер

21

Благодаря второму комментарию Брюса я смог самостоятельно разобраться в проблеме.

После запуска stty -a -F /dev/ttyS1я обнаружил, что для решения этой проблемы есть 3 варианта: «echo», «onlcr» и «icrnl».

Поскольку этот последовательный порт возвращается к себе, вот что произошло после запуска echo "hi" > /dev/ttyS1:

По echoумолчанию команда добавляет новую строку в конец сообщения, поэтому в / dev / ttyS1 отправляется «hi» + LF
Поскольку было установлено «onlcr», последовательное устройство преобразовало LF в CRLF, поэтому физическое сообщение, отправленное по линии Tx, было «hi» + CRLF
Поскольку был установлен icrnl, физический обмен сообщениями, полученный по линии Rx, преобразовал CR в LF. Таким образом, сообщение, выведенное 'cat', было "hi" + LFLF.
Поскольку было установлено «echo», сообщение, полученное на Rx («hi» + LFLF), затем было отправлено обратно по линии Tx.
Из-за onlcr "hi" + LFLF стал "hi" + CRLFCRLF.
Из-за icrnl "hi" + CRLFCRLF стал "hi" + LFLFLFLF
Из-за эха, "привет" + LFLFLFLF был затем отправлен Tx

И так далее...

Чтобы решить эту проблему, я выполнил следующую команду:

stty -F /dev/ttyS1 -echo -onlcr

Отключение «echo» предотвращает бесконечный цикл сообщений, а отключение «onlcr» не позволяет последовательному устройству преобразовывать LF в CRLF на выходе. Теперь catполучает один "привет" (с одной новой строкой!) За каждый раз, когда я бегу echo.

CR = возврат каретки (ASCII 0x0D); LF = перевод строки или перевод строки (ASCII 0x0A)

— Кристина
источник

-icrnlсделал трюк для меня.

— tcpaiva

3

У меня была похожая проблема с объединением файлов в последовательный tty для тестирования. В дополнение к принятому ответу:

Если вы тестируете последовательный вывод, выполняя что-то вроде:, cat somefile.txt > /dev/ttyS0он будет иметь большое количество неожиданных байтовых данных, если вы будете проверять точные байтовые значения.

С sttyделает простой stty raw -F /dev/ttyS0остановятся терминал из вставки / замены символов (например , [...] 0x0A [...]-> [...] 0x0D 0x0A [...]). rawФлаг изменяет режимы терминала так , не выполняется вход и выход обработки.

— мне нужно поспать
источник

1

Хм ... не похоже stty rawотключит эхо по умолчанию. Возможно, вам нужно сделать stty raw -echo.

— BMiner