Отчего COM порты в linux такие странные?

Это не «ком-порт» так себя ведет, а терминальный клиент! Поставь себе tinyserial - все там нормально!! Ну или правильно настрой порт при помощи stty, а потом уж screen запускай.

Нет, я не из терминального клиента обращался к com порту. У меня программа с бинарным протоклом, работающем через com порт

Про stty то я нашел в итоге сам, просто непонятно, почему по-умолчанию он всякие доп действия делает

Они делают всякие дополнительные вещи.
Зачем так сделано?

Что сделано? Команды какие? «Кто» именно делает/неделает «дополнительные вещи»?

Казалось бы, для com порта по умолчанию ожидается что что подашь на один конец, то и вылезет из другого.

Да. При ОДИНАКОВЫХ настройках портов с обоих концов и отсутствии потерь и дефектов преобразований. <---- вот это надо читать несколько раз, до понимания. Интересно, сколько времени требуется среднему программисту, чтобы осознать смысл этой фразы. Жизнь ?

Ну вот и смотри, что твоя программа делает. Ты наверняка неправильно выставил настройки. Читай man termios

А вот фиг. Создал 2 связанных pts,

socat -d -d pty pty

$ od -t x1 /dev/pts/12

и делаешь

$ echo -n -e '\x0D' > /dev/pts/13

и из /dev/pts/12 вылезает

0000000 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a

Я изначально не выставлял настройки, кроме как 8N1 115200. Т.е. использовал режим по-умолчанию. И выяснилось, что в этом режиме на выходе может быть совсем не то, что на входе

Да проверь ты получше! Говорю тебе, стопудово есть разница в настройках входа и выхода! «Само» оно никак не может меняться. Разве что у тебя линия связи ужасная и шума много...

Нет, com порт в linux по умолчанию, как выяснилось, находится в canonical mode, где он как раз меняет в том числе 0x0d на 0x0a

И помехи тут ни при чем. Я вот выше пример с двумя связанными pty привел, там вообще никаких помех нет и не может быть

И мне совсем непонятно, зачем так сделано

/dev/pts/

Это не ком порты. Если хочешь нормальные связанные «виртуальные пары последовательных портов» - используй модуль ядра tty0tty.

Это не ком порты.

в чем отличие?

Сделано это затем, что изначально терминалы по последовательному порту подключались! Поэтому они и настроены по умолчанию на 9600N1 canonical mode, т.е. эхо там тоже есть (а то как видеть, что ты набираешь?)!

Как уже сказали, pty — не совсем то, что тебе нужно. Лучше всего экспериментируй с настоящими аппаратными портами...

пробовал /dev/ttyS0 и /dev/ttyUSB0 соединять через нуль-модемный кабель. Все ровно так же

еще раз: читай man termios! Отключи canonical mode. Или пользуйся простым клиентом, если не можешь stty порт настроить.

У меня есть простейший самописный терминальный клиент, которого уже несколько разновидностей - все никак не сяду и не напишу полноценный, чтобы скорость и прочие параметры менять можно было через командную строку! Попробуй. Он ничего не заменяет. Только символ q не выводит - это выход. Но есть у меня где-то на завалах гитхаба и клиент, который по ctrl+c завершается + умеет дублировать ввод/вывод в логфайл.

еще раз: читай man termios! Отключи canonical mode. Или пользуйся простым клиентом, если не можешь stty порт настроить.

Да настроил я все уже. Просто меня очень удивляет, нафига com порт по-умолчанию предпринимает некоторые не самые очевидные замены.

еще раз: читай man termios! Отключи canonical mode.

Ты отвечаешь на незаданный вопрос ответ на который у ТС уже есть.

Это дремучее легаси из эпохи когда к компам подключались через терминал.

Ну понятно, что такой режим может быть для чего-то нужен. Непонятно, зачем его держать по-умолчанию

Легаси 38 летнее или ещё дремучее.

Да хотя бы потому, что обычно «общение» по порту с железякой идет в текстовом формате: смотри те же GPS, монтировки телескопов и т.п. Кому охота заморачиваться с byte order? И очень редко выдумывают на свою пятую точку бинарный протокол. А потом страдают...

Кому охота заморачиваться с byte order? И очень редко выдумывают на свою пятую точку бинарный протокол. А потом страдают...

Текстовый протокол через чистый com порт не гарантирует доставку и корректность.

А значит для надежного обмена нужен некий аналог TCP, но поверх com порта.

+1

Текстовый протокол через чистый com порт не гарантирует доставку и корректность.
А значит для надежного обмена нужен некий аналог TCP, но поверх com порта.

Это правильное решение неправильно поставленной задачи. Потому что если вам нужен надёжный обмен, почему вы используете RS ? Сейчас вроде не 1971-й год...

Потому что мне сейчас пока лень переделывать железку и подключать к ней ethernet.

К слову, ethernet тоже не гарантирует доставку. Потому поверх него тоже нужен TCP или аналог

Я в итоге сделал реализацию протокола RFC908 (reliable datagram protocol) с некоторыми доработками напильником, работаующую через реализацию datagram через com порт

И очень редко выдумывают на свою пятую точку бинарный протокол.

Ну, это ты очень мощно неправ насчёт «очень редко». По протоколу MODBUS RTU работает до сих пор половина промышленных контроллеров, например. Протокол - полное г-но, но простой СЦК, и до сих пор им мажутся.

К слову, ethernet тоже не гарантирует доставку.

Да, но TCP - он не поверх ethernet, он двумя уровнями OSI выше.

Зачем тебе ethernet? Есть CAN, который не требует никаких мучений с низким уровнем: «оно само» контролирует целостность пакетов. У меня на телескопе так работает система термомониторинга.

MODBUS RTU

Старючее дерьмо мамонта! Но народ в силу своей инерции продолжает ходить по граблям.

В Linux вообще нет COM-портов. Вали обратно на венду!

Можно и поверх голого ethernet TCP сделать

Ethernet обеспечивает передачу датаграмм, для TCP требуется работа поверх протокола, дающего датаграммы.

Опять же, железку над переделать будет

Зачем тебе ethernet? Есть CAN,

Не знаю, зачем ему, а мне например ethernet затем, что он легко и нормально заворачивается в оптику, а ваш CAN гвоздями прибит к меди, а медь - когно.

Поэтому желательно заранее выбирать протокол обмена, исходя из длины линии и требований к связи. Но и RS-232 вне особых помех спокойно работает на 30-50-метровых проводах!

https://www.prosoft-technology.com/Products/Gateways/CanBus/Fiber-Optic-CAN-b...

Но и RS-232 вне особых помех спокойно работает на 30-50-метровых проводах!

Именно что «вне особых помех», ага.

У меня помехи от шаговиков и шпинделя. А значит нужен быстрый протокол с автокоррекцией ошибок. И да, мне нужен дуплекс, т.к. задержки при полудуплексе мне вовсе ни к чему

Что ж там за шаговики, что от них помехи мешают RS-232? Мы обычными слабыми (типа NEMA-17) управляли, когда рядом шла полуметровая линия тупого UART'а (то бишь TTL без всяких дифпар и т.п.). И ничего - проблем не было.

Китайские балалайки, вечно глючащие и виснущие. Хотя, весь CAN - это китайские балалайки. Ни одного фирменного адаптера в природе.

У «псевдо терминалов» урезанный набор ioctl'ов и пр. Если, к примеру, нужна эмуляция сигналов DTR/RTS то pts/pty в пролете.

Кроме того, по личному опыту, связывание при помощи socat хреново работает (по крайней мере для меня, например, быстро открыть/закрыть pts/pty у-во и прочее, часто все это фейлилось) и я перешел полностью на tty0tty, если нужны виртуальные пары.

Скорее китайский USB COM шнурок. Да, помехи не постоянные, но мне нужно, чтобы ВСЕ байты в течении нескольких минут/часов были приняты корректно

Если, к примеру, нужна эмуляция сигналов DTR/RTS то pts/pty в пролете.

Ну мне этого и не надо

весь CAN - это китайские балалайки

При этом работает очень стабильно. У меня никаких глюков за год работы не было!

Почему сразу шнурок, есть аппаратные COM порты. Но даже в случае кетайских плат, микросхемы UART - фирменные, так что тут нормально. А CAN - это обычно фееричные платы, фееричные драйверы от дяди Ляо, обкуренного.

Почему сразу шнурок, есть аппаратные COM порты.

не на моем ноуте

А ты выброси твой ноут, если для работы тебе нормальные RS порты нужны.

Я хочу сделать так, чтобы можно было с дешевым железом иметь надежную работу за счет алгоритмов

Реализация протокола собственно вот:

https://github.com/vladtcvs/rdpos

Обеспечивает надежный обмен датаграммами, не использует динамическое выделение памяти.

Оверхед всего 19 байт на пакет данных.

Осталось реализовать python обертку и отсылку keepalive пакетов по таймеру.

можно купить десктоп, в котором есть

Можно. У меня собствено и десктоп есть. Но это же еще место будет занимать лишнее, плюс это рядом с ЧПУ, а значит пыль будет копиться внутри. Ноут все-таки проще от пыли защитить

Нормальный аппаратный RS-232 можно и по USB организовать — взять ту же PL2303, например! Правда, я не уверен, что кернельный модуль все возможности PL2303 поддерживает.

Ну, как вариант — на дешевенькой STM'ке сделать свое.