> Спасибо! Все заработало!Отлично :)
> Благо обошлось без этого.
Но запомнить этот момент не лишне. Я так как-то долго прыгал по грабелькам. А потом заметил что файл девайса оказывается вовсе и не файл девайса, а уже обычный файл.
> Полностью согласен. И не читайте всякими 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" :)
> Еще раз, всем огромное спасибо!
Да не за что - приятно помочь сообразительному человеку.
