Начну с конца:
Спасибо! Все заработало!
Далее по пунктам.> И кстати вот еще какой момент: безбашенным echo и прочим - вы
> могли ... загадить себе файл девайса.
Благо обошлось без этого.
> 5) Больше не эхайте в спецфайлы!
Полностью согласен. И не читайте всякими hexdum`пами и cat`ами и иже с ними. Особенно миникомами. Действительно уйму времени угробил, пока понял, что не все они "читают".
> А еще, для понимания того что реально происходит в плане системных вызовов
> - есть хотя-бы strace.
"Опустился" уже в какой-то момен и до неё. Но полностью применить её мощь не позволило недостаточность моих знаний.
> Если есть какие-то непонятки, делаем тот самый тест UART с замыканием линий:
[...]
> Это имеет смысл сделать одной из первых вещей
Это было сделать не тривиально: UART бридж на основе CP210x физически спрятан (впаян) внутри устройства, а не классический кабель-переходник, а разбираться в схемотехнике самого устройства у меня знаний не хватает.
>> Под виндой сделал за пару часов, а тут борюсь уже пару недель.
> Как я уже сказал, винда и линукс - разные вещи. И есть
> некоторые нюансы. Поэтому если вы будете лезть с виндовым бэкграундом в
> линух - будете получать граблями по лбу.
Согласен, но с чего-то начинать нужно.
> Чтобы работать с системой - надо
> ее все-таки знать.
Очень надеялся, что переслать пару байт возможно без глубокого (относительно) изучения всей системы. Но нет...
> А чтобы подсмотреть как работать с UART в Linux в явно работающих
> программах, в дебиане и прочих убунтах есть фирменный чит: apt-get source
> <какая-нибудь программа работающая с UART>.
Это действительно так. И я так и поступил. Правда влез в stty.
> Или тот же picocom
> (но он работает с текстовыми данными и не лучшим образом, это
> отдельный случай и его я не порекомендую).
И тут можно "плохому" научиться)) Так что не все сорсы одинакого полезны?
>> Вообще спасибо за советы! Очень путные!
> Ну еще бы - я по таким грабелькам уже попрыгал :).
Уже тоже имееться своя узкая тропинка, усыпаная грабельками...
> А еще - за неделю можно было бы задолбаться и накормить поисковик
> очевидными кейвордами. И в первых строках найти что-то типа http://tldp.org/HOWTO/Serial-Programming-HOWTO/index.html
Это было одно из первых, что я прочитал. Только без *никсового бекграунда это очень тяжело воспринимается снаскоку. Это теперь я вижу, перечитывая, как все _почти_ очевидно))
И да, работаю в режиме "многозадачности" и конечно чистого времени на эту проблему не пара недель. Просто когда вижу, что мысли начали заходить в тупик, переключался на другую задачу, где "бери лопату и кидай"))
Ну а как решил:
взял в руки что потяжелее, c++ например. Так отконфигурил, вот кусок кода:
tcgetattr(port.fd, &port.config_old);
port.config_new=port.config_old;
port.config_new.c_oflag = 0;
port.config_new.c_iflag=0;
port.config_new.c_cflag=CS8|CREAD|CLOCAL;
port.config_new.c_lflag=0;
cfsetispeed(&port.config_new, B19200);
cfsetospeed(&port.config_new, B19200);
if(tcsetattr(port.fd, TCSAFLUSH,&port.config_new)!=0)
{
cout<<"tcsetattr() failed."<<endl;
return (-1);
}
Ну а потом select в руки и read. И все заработало.
Параллельно большое спасибо за udev! Так как и сам девайс не подарок. Как оказалось переодически отваливался от компьютера, и премонтировался под разными /dev/ttyUSB#. grep показал, что "USB port nn disabled by hub (EMI?)". Причину EMI искать в устройстве-компе не стал, провода точно хорошие, а внутрь устройства лезть не буду. Прописал в рулезах и теперь постоянно поднимается симлинк с постоянным именем для девайса. Только в удев_рулёзе так и смог команду RUN заставить работать... Пробовал и RUN+="_команда_" и RUN{"_команда_"} все равно не исполняется. Но это уже мелочи.
Еще раз, всем огромное спасибо!
