Работа с СОМ-портом на Си в linux

[dlinyj]

Сегодня Великий День, я впервые написал статью моему хорошему другу di_halt на сайт http://easyelectronics.ru/

Вы можете прочитать её по следующей ссылке. Выражаю благодарность xlat за разрешение использовать её фотографию в данной статье. Это Teletype Model 33 ASR. Данное устройство, как нельзя лучше иллюстрирует все проблемы работы с СОМ-портом.

В целом, практически обо всём я так или иначе рассказывал на своих вебинарах, но порой лучше прочитать, чем просмотреть.

Comments

[minimumlaw.livejournal.com]

Спасибо. Все хорошо написано. По существу претензий нет.
А вот мелкие детали... Вплоть до ioctl все было нормально. Везде были уточнения, но... Все они были явно лишними в рамках рассматриваемой темы и уводили в те дебри, куда не всякому лезть надо. А вот пассаж "Системный вызов ioctl не стандартизован и очень опасен" заставил аж передернуться. Нет же. Нет никакой опасности в вызове IOCTL. Более того - это исторически первый (и долгое время единственный) способ конфигурирования порта. Он же самый универсальный. Увы, termios не во всех UNIX одинакова. Другое дело, что реализация IOCTL (как, впрочем, и POOL для не блокирующего чтения) остается на совести авторов драйвера конкретного порта. Далеко не все допустимые параметры реализованы в том же ttyACM. Часть в принципе невозможно реализовать. Спецификация интерфейса их не предусматривает. Часть просто не реализована.

Про 485ый справедливо. Не смотря на наличие специального режима в ядре, в реальной жизни оно мало кем используется. А уж для USB-конвертеров и подавно. Подавляющее большинство таких изделий не требуют каких-либо усилий и используют аппаратный сигнал переключения чтения/записи. Но большинство - не значит все. Часть использует RTS. А некоторые еще какую-то экзотику. Потому с общим выводом согласен, но мне кажется что краски уж больно густыми вышли.

И еще. Serial Programming HOWTO (лучше в оригинале, но... http://linux.yaroslavl.ru/docs/howto/Serial-Programming/Serial-Programming-HOWTO_ru.html - раз уж статья на русском) в сносках крайне желательно.

[dlinyj.livejournal.com]

Спасибо за развёрнутый комментарий.

ioctl не регламентирует размер третьей переменной, и этот вызов может делать переполнение. Самый коварный вызов. В рамках порта да, но при работе в целом он плох.

Serial Programming HOWTO для меня был бесполезен чуть более чем полностью.

[minimumlaw.livejournal.com]

В странное время мы живем. То, что когда-то было великой мощью IOCTL, и позволяло практически бесконечно наращивать его возможности оставаясь в рамках "универсального" вызова для всех устройств теперь не только вами, но даже преподавателями из ЛЭТИ, объявляется опасным и страшным. Ладно преподу простительно - он типичный прикладник. Но системщикам-то чего его бояться? Да, третий аргумент имеет тип (void *). Да, что именно там будет зависит от второго аргумента. А может быть целое или указатель. Опять же указатель на строку или структуру. А в принципе и список. Все предельно просто и понятно. Ошибка (то самое переполнение) - это ошибка программиста. Который "накосячил" с параметрами. И только. Так такие ошибки везде не редкость и везде приводят к вылету.

Нет, блин. Это реально страшно. Любое упоминание (void *) вводит современных программистов в ступор. Потому простой и понятный ioctl обзавелся сокетной альтернативой типа netlink. Куда более тяжелой и неудобной, за то понятной современным программистам. Та же ерунда с системой инициализации. Шутитли в свое время про Nero, которое должно своей осью обрасти. Дошутились. Здравствуй systemd. SysV, при всех его недостатках, был понятным. И надежность системы зависела от качества кода в ней, а не от возможности поднять не вовремя упавшее. А потом удивляемся - и почему код стал таким большим, неповоротливым и ненадежным.

Из "старья" мне не жалко разве что XFree86. Вот она получилась реально замороченной. И для своего времени, и тем более сейчас. Когда она обросла слоями совместимости. Мне нравится как себя ведет Weston в Embedded. Надеюсь в скором времени и прикладники научатся с ним нормально работать.

Но, продолжая с ностальгией, могу сказать еще вот что. В далеком 1998 году, когда на моем HP Vectra 486DX2-66 с аж 16Мб RAM и 540Mб жестким диском, меня, практически выпускника колледжа радиоэлектронники, очень порадовала Coffee Making HOWTO. Теперь ее и найти-то не просто. Оригинал на https://tldp.org/HOWTO/Coffee.html датирован 2004 годом, русский перевод более ранний https://www.opennet.ru/docs/HOWTO-RU/Coffee.koi8-r.html - 1998 год. Мы же помним золотое правило - документация либо русская, либо правильная. До сих пор актуально. Но суть не в этом. Суть в том, что в далеком 1998 году FIdo'шники обсуждали возможность перезапуска станции путем выноса кнопки Reset компьютера в сторону лотка CDROM'а. Типа программно открываем CDROM и лотком нажимаем на сброс а тут такое богатство. Так что могу сказать четко, и Serial Programming и Coffee Making HOWTO очень серьезно помогли мне в части выбора жизненного пути. Вплоть до изучения английского (ибо русского перевода тогда еще не было от слова совсем).

Теперешней молодежи вроде и легче (компьютеры доступнее) и тяжелее. Принтерный порт умер, последовательный планомерно изживается из ПК и остается только у embedder'щиков. Правда сегодня есть замечательные gpio-led(s) и gpio-key(s). Но завести их сильно сложнее.

[Николай Замотаев (from livejournal.com)]

> И надежность системы зависела от качества кода в ней, а не от возможности поднять не вовремя упавшее. А потом удивляемся - и почему код стал таким большим, неповоротливым и ненадежным.

Самое смешное, что поднять не вовремя упавшее тоже не требует особой сложности. Что runit, что daemontools имеют копеечный размер и отлично работают. С зависимостями немного сложнее, но тоже можно.

[vladikoms.livejournal.com]

Не совсем в тему, но по странному стечению обстоятельств я как раз сейчас запилил "Ethernet to RS485" на апельсинке. Пошел по самому легкому пути - подключил в USB-порт одноплатника преобразователь "USB - RS485" с алиэкспресса :) Всё норм.

[simsun.livejournal.com]

на днях пытался гуглить "Ethernet over RS485" , потом хотя бы просто какой tcp/ip...и как то не очень

[minimumlaw.livejournal.com]

Гуглите SLIP или PPP. Больше шансов на успех будет. Теоретически нет проблем и ethernet кадры обернуть и передать.
А не поделитесь кому и зачем такое понадобилось?

[simsun.livejournal.com]

Зачем мне гуглить если весь первый инет у меня по PPP и ходил под линуксом, а выделенка на SLIP была. Но как бы Point to Point как бы говорит само за себя что это не разделяемая среда, так ведь?
А мне надо пусть и медленно но множественный доступ. В теории.... не то что бы я уже прямо так хочу это все реализовывать. Тут может и двухпроводный пром эзернет (10 мБит) подвезут когда -нибудь как и анонсировали недавно... но там правда точек на одном проводе совсем не много, да и ценник поди ахунг в начале

[minimumlaw.livejournal.com]

Беда всегда в разделении. Нужно как-то гарантировать паузу между пакетами отправителя, чтоб получатели ответить успевали. В случае с множественным доступом все становится совсем плохо. Но в целом какая разница в какую бумажку заворачитвать кадры. Хоть Ethernet, хоть IP, хоть IPX (если очень надо).

[simsun.livejournal.com]

> Нужно как-то гарантировать паузу между пакетами отправителя
да канал не надо утилизировать весь, скорости хватает

> Но в целом какая разница в какую бумажку заворачивать кадры. Хоть Ethernet, хоть IP, хоть IPX
Эзернет в чистом виде кажется не пройдёт по таймингам. Помню - кварцы перепаивали до 2-2.5mHz если не изменяет память. И кажется если ниже начинало ломаться.

Собств коммент был, что гугль мне ничего такого путного не сказал по этой теме, удивило. Может не так спрашивал?

[minimumlaw.livejournal.com]

Ну на вскидку мой гугл тоже молчит. Обратного хватает, а вот упаковки ethernet'а в serial (даже без уточнения в 485-ый) как-то не видно. С другой стороны, а надо оно? Не многовато ли OVERHEAD'а будет если ethernet кадры паковать? Опять же уникальность MAC-адресов надо как-то обеспечивать. Хотя бы административно. Да и таймауты. Чо логично. С другой стороны, и чистый IP упаковывается куда угодно. Хоть в 802.3, хоть в serial. Так что было бы желание... Впрочем, как правило дальше UDP там все равно не идет - сложно и заморочисто. В первую очередь по требованиям к памяти.

Собственно, потому и интересуюсь кому и зачем надо. Есть же всякие ModBus'ы как раз для этих целей. С ними проще. ДА и если надо, есть железки которые RTU через Ethernet гоняют...

[simsun.livejournal.com]

Спасибо за наводящие вопросы! Эзернет уже не помню откуда тут взялся :)
Речь конечно просто о tcp/ip по RS485, может даже и просто UDP для простоты.
с ходу вот предлагают, но не вникал пока: https://github.com/dukelec/cdbus_doc

[simsun.livejournal.com]

> Есть же всякие ModBus'ы как раз для этих целей.
У него же как я понял - фатальный недостаток - один мастер(опросник), а надо каждый с каждым, отсюда и аналогия с эзернетом

[minimumlaw.livejournal.com]

Это где такое написано? ОЧень даже неплохо себя чувствуют несколько устройств master-slave на одной шине. Главное чтобы адреса у них разные были. Больше того, такой вариант вполне себе предусмотрен спецификацией.

[simsun.livejournal.com]

имелось в виду, что мастер должен сам опрашивать, на счет что может быть несколько мастеров - не знал

[minimumlaw.livejournal.com]

Может может. Роль у устройства ведуший, ведомый или их комбинация. Другое дело, что арбитраж шины целиком в руках программиста. Т.е. придется делать что-то типа контроля ethernet'овского несущей и дублировать запросы по неполучению ответа. Но это придется делать и для любой другой реализации. Хоть для IP, хоть для Ethernet, хоть для чего-то другого.