Несподівані результати тестують серійну петлю за допомогою echo та cat

18

Тож у мене є стандартний послідовний порт 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.

Після переривання кота, якщо я запускаю його ще раз, він не видасть "привіт", поки я не запущу ехо вдруге.

Це нормально? Будь-яка ідея, чому я бачу таку поведінку?

Правка : Під новим рядком я маю на увазі ASCII 0x0A. У цьому виході немає повернення каретки.

cat serial-port echo

— Христина
джерело

Чи може це бути викликано тим, що два процеси відкривають один і той же пристрій? Що робити, якщо запустити tip /dev/ttyS1( ~.для виходу) і спробувати ввести там дані? Він повинен відображатися у вашому терміналі, коли провід підключений, оскільки він отримує те, що передав.

— mrb

3

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

— Брюс Едігер

21

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

Після запуску stty -a -F /dev/ttyS1було знайдено 3 варіанти, які я міг сприяти проблемі: "ехо", "onlcr" та "icrnl".

Оскільки цей послідовний порт повернуто до себе, ось що сталося після запуску echo "hi" > /dev/ttyS1:

echoКоманда додає нову рядок в кінець повідомлення за замовчуванням, так «привіт» + LF відправляється до / DEV / ttyS1
Оскільки було встановлено "onlcr", послідовний пристрій перетворив LF у CRLF, щоб фізичне повідомлення, що надсилається рядком Tx, було "привіт" + CRLF
Оскільки "icrnl" був встановлений, фізичні повідомлення, отримані по лінії Rx, перетворювали CR в LF. Тож повідомлення, виведені "cat", були "привіт" + LFLF.
Оскільки було встановлено "ехо", повідомлення, отримане на Rx ("привіт" + LFLF), потім було відправлено назад на лінію Tx.
Через onlcr "привіт" + LFLF став "привіт" + CRLFCRLF.
Через icrnl, "привіт" + CRLFCRLF став "привіт" + LFLFLFLF
Через відлуння тоді "привіт" + LFLFLFLF був відправлений Tx

І так далі...

Для вирішення цієї проблеми я запустив таку команду:

stty -F /dev/ttyS1 -echo -onlcr

Вимкнення "ехо" запобігає нескінченному циклу повідомлень, а відключення "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Прапор змінює режими терміналу так , не виконується вхід і вихід обробки.

— ineedtosleep
джерело

1

Хм ... не схоже stty raw, що за замовчуванням вимкне відлуння. Можливо, вам доведеться це зробити stty raw -echo.

— BMiner