> Спасибо! Все заработало!

Отлично :)

> Благо обошлось без этого.

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

> Полностью согласен. И не читайте всякими hexdum`пами и cat`ами и иже с ними.

Ну это все-таки не совсем обычный файл. Там буферизация, настройки таймаутов, потенциально - процессинг ввода. И какие настройки по дефолту и насколько это то что вы хотели - отдельный вопрос. И в разных системах все это по разному.

> Особенно миникомами.

Он переклинен на диалапных модемах. Терминалка для обзвона BBS-ок. Остальное там - "можно, но сложно".

> Действительно уйму времени угробил, пока понял, что не все они "читают".

Миником ожидает модем. А обычные утили - обычные файлы. Попытки кормить софт не тем чем он ожидал - ни к чему хорошему не ведут.

> мощь не позволило недостаточность моих знаний.

Да там все достаточно просто. Хотя спама может быть многовато. Можно обрубить лишнее, встроенным фильтром или просто каким-нибудь редиректом в grep.

> Это было сделать не тривиально: UART бридж на основе CP210x физически спрятан

Извиняюсь, невнимательно читал что у вас погодная станция. Думал что кабель все-таки отдельно. А с отдельными кабелями бывает много грабель в электрическом уровне, вот я "по инерции" и посоветовал.

> схемотехнике самого устройства у меня знаний не хватает.

На самом деле это не так уж сложно, в том плане что найти надо этот самый CP2102 и посмотреть куда идут его лапки TX и RX (даташит на CP210x - общедоступен). Скорее всего к процу этой штуки, на его UART. В лучшем случае могут быть контактные площадки или даже разъем с UART-ом. Но разбирать готовый девайс и правда как-то не очень.

>> Поэтому если вы будете лезть с виндовым бэкграундом в
>> линух - будете получать граблями по лбу.
> Согласен, но с чего-то начинать нужно.

На самом деле я сам когда-то прогрмамил компорты в винде. А теперь в линухе. Они не настолько уж разные. Но отличия все-таки есть. И желание срезать угол на предыдущих знаниях может сыграть дурную шутку иной раз.

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

Ну это на самом деле нечто типа random. Может и получится, в зависимости от. Параметры порта - можно выставить утилитой типа setserial, например. Но изначально ее может в системе и не быть. И мне кажется надежнее явно впрогрмамить заведомо правильные настройки порта и проверять статус операций. Так по крайней мере в случае чего - понятно что не так.

> Это действительно так. И я так и поступил. Правда влез в stty.

Да не принципиально в кого именно, единственное что всякие "терминалы" и т.п. - могут использовать "канонический" процессинг текста, а насколько вы хотели это при работе с произвольным девайсом - отдельный вопрос.

> И тут можно "плохому" научиться)) Так что не все сорсы одинакого полезны?

Как написано в том мануале на который я сослался, есть канонический ввод, ориентированый сугубо на построение терминалок. И есть неканонический, где система не пытается умничать и делать строки из того что строками может и не являться. По понятным причинам, с произвольными данными работать надо в неканоническом режиме. Если этот момент упустить - можно удивляться тому что данные "портятся".

> Уже тоже имееться своя узкая тропинка, усыпаная грабельками...

Да на самом деле там не все так страшно, особенно если подсмотреть у кого-нибудь заведомо работающего как это делать.

> Это было одно из первых, что я прочитал.

Даже так? Про это можно было бы упомянуть :)

> Только без *никсового бекграунда это очень тяжело воспринимается снаскоку.

Я бы не сказал что я - такой уж крутой *никсовый программер. Там вроде все достаточно логично написано и не то чтобы мне требовался при чтении этого какой-то бэкграунд.

> И да, работаю в режиме "многозадачности" и конечно чистого времени на эту
> проблему не пара недель. Просто когда вижу, что мысли начали заходить
> в тупик, переключался на другую задачу, где "бери лопату и кидай"))

А, ну понятно :). А я то удивлялся - как за 2 недели можно не найти тот how to и что там в нем 2 недели читать. Я то в него более-менее въехал ну может часа за 2.

> взял в руки что потяжелее, c++ например. Так отконфигурил, вот кусок кода:

...
> Ну а потом select в руки и read. И все заработало.

Ну вот я тоже как-то так предпочитаю :). Там ничего особо страшного.

> Параллельно большое спасибо за udev! Так как и сам девайс не подарок.
> Как оказалось переодически отваливался от компьютера,

Вот это уже может быть глюками старого ядра. Как бы там ни клялись про стабильность фанаты дебиана, мне ядра до 3.10 в плане работы usb не очень нравятся. На самом деле, чипы и чипсеты в мамках - достаточно бажные. А драйвера наполовину состоят из "quirks" и воркэраундов глюков чипов. Одна из причин по которым я не люблю старые ядра - чем новее ядро тем о большем количестве нестандартных закидонов чипов оно знает и знает как правильно выходить из таких штопоров или вообще не допускать их.

> и премонтировался под разными /dev/ttyUSB#.

Ну да, если ttyUSB0 уже занят, очередной адаптер сядет на ttyUSB1, и так далее.

> grep показал, что "USB port nn disabled by hub (EMI?)". Причину
> EMI искать в устройстве-компе не стал, провода точно хорошие,

Тогда может быть это какие-то глюки чипа или чипсета а относительно старый кернел не все воркэраунды содержал.  С другой стороны, качество проводов для usb на глаз прикинуть тоже нелегко. Это скоростная дифференциальная пара, там волновое сопротивление роялит и прочие отражения сигнала. На глаз это проверить не то чтобы просто.

> симлинк с постоянным именем для девайса.

Вариант. Заодно можно какое-то более логичное название девайса дать. Скажем /dev/weatherstation. Из недостатков: прога будет по идее сталкиваться с ошибками чтения когда девайс отпал. Но если написать там переоткрытие порта - работать по идее будет. Хоть это и костыль и по хорошему так быть не должно.

> Только в удев_рулёзе так и смог команду RUN заставить работать...

Я в правилах обычно пользуюсь чем-то типа: RUN+="/usr/bin/program %k" (отдает /usr/bin/program как argv[1] параметр %k, который "название девайса по мнению ядра"). Да, там надо указывать ПОЛНЫЙ путь к программе. И там не будут работать всякие фичности шелла типа перенаправлений или раскрытия wildcard, насколько я помню. Это просто выполнение программы а не шелл. Но можно передать кучу параметров и прочая. Путь к программе - ***обязательно*** полный. А примеры подсмотреть можно в системных правилах, их немеряно в каком-нибудь /lib/udev/rules.d/ :)

> все равно не исполняется.

Странно, у меня исполняется. Например, на нотике я делаю как-то так:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNEL=="wlan*", RUN+="/usr/bin/macchanger -r %k"

Этот рулес при появлении сетевого устройства "wlan*" в системе - запускает программу macchanger, которая ставит на указанном интерфейсе (%k - имя девайса по версии ядра) рандомный MAC. Небольшой подарок любителям слежки за перемещениями людей через отслеживание MAC в периодических probe requests :P. Или "как запилить это более честно чем apple" :)

> Еще раз, всем огромное спасибо!

Да не за что - приятно помочь сообразительному человеку.