> Нашел - установил - буду пробовать.Достаточно полезная штука для изучения что вообще происходит. Может показывать не только данные, но и управляющие сигналы и их изменения.
И кстати вот еще какой момент: безбашенным echo и прочим - вы могли ... загадить себе файл девайса. Дело в том что /dev/ttyUSB0 - не только девайс, но и некий СПЕЦИАЛЬНЫЙ файл, реально существующий в файловой системе на диске. Как часть иерархии ФС. А ваше "echo" и прочие "обычные" утилиты - не в курсе что файл СПЕЦИАЛЬНЫЙ. И могут, натурально, снести его куда подальше и создать на месте /dev/ttyUSB ... обычный файл, в который запишут тот же текст из echo. Файловой системе все-равно. Просите нормальный файл по этому пути - сделаем нормальный, значит. Единственная проблема: этот файл ... не будет иметь никакого отношения к UART-ам и вас ждет много интересных открытий. Когда вы будете пытаться читать обычный текстовичок как якобы UART и внезапно обнаружите что творится какая-то фигня. Если терминалки и прочие jpnevulator "глючат" и вопят что не удалось получить статус модемных линий и что там еще - это оно. У простого текстового файла нет модемных линий, IOCTL завалится с ошибкой. Не надо эхать в спецфайлы, это источник грабель. С файлами в /dev вообще стоит поаккуратнее.
Workaround такой ситуации, если это она:
1) Удаляем кривой файл - от рута: rm /dev/ttyUSB0
2) отключите адаптер на CP2102 от компьютера.
3) переподключите адаптер.
4) Убедитесь что /dev/ttyUSB0 пересоздался (таким как изначально задуман).
5) Больше не эхайте в спецфайлы!
А еще, для понимания того что реально происходит в плане системных вызовов - есть хотя-бы strace. Покажет какие системные вызовы были и чем закончились. Может навести на мысли. Если оно отлупляет нечто типа inappropriate IOCTL for device, это хорошая подсказка что идут "неожиданные" файловые операции.
> К сожалению систему не могу выбирать.
Ну так проверьте что ваш UART для начала работает как надо. CP210x древние и возможно нормально работают даже в этом дебиане.
Как-то примерно так:
1) picocom /dev/ttyUSB0
(При старте напишет параметры порта, если все ок. Возможно надо будет еще указать правильный baud rate, т.к. не факт что дефолтный - такой какой вам надо)
2) Напечатайте что вы там хотели. Посмотрите приехал ли ответ от вашего девайса.
Если есть какие-то непонятки, делаем тот самый тест UART с замыканием линий: запускаем picocom, CP2102 - не подключен ни к чему. Печатаем. Убеждаемся что ничего не печатается (локального эха нет). Соединяем TX и RX вашего CP2102. Проверяем что теперь - печатается (т.е. то что шлется в TX, прилетает назад по RX). Если это так - ок, порт работает и дело в чем-то другом (baud rate, flow control, кривая работа с портом, ...). Если не ок - напишет в чем проблема. Если не рабтает даже picocom, простой как 5 копеек, то у вас таки проблемы системного характера.
> Если ничего не поможет, то так и сделаю.
Это имеет смысл сделать одной из первых вещей - позволяет понять насколько работает UART, в обе стороны. Если этот тест не прошел - у вас что-то не так и остальное работать и подавно не будет.
> Под виндой сделал за пару часов, а тут борюсь уже пару недель.
Как я уже сказал, винда и линукс - разные вещи. И есть некоторые нюансы. Поэтому если вы будете лезть с виндовым бэкграундом в линух - будете получать граблями по лбу. Примите как данность: Linux - это не еще один вариант винды. Это другая система. И у него свои особенности. Вот файлы девайсов - в том числе. Не стоит в них лишний раз соваться general purpose утилитами, особенно от рута, без четкого понимания последствий.
> То что девайс работает - это точно, затык именно в линухе.
ИМХО затык в том что вы пытаетесь применять виндовый бэкграунд к линуху. А это чревато интересными обломами. Чтобы работать с системой - надо ее все-таки знать.
А чтобы подсмотреть как работать с UART в Linux в явно работающих программах, в дебиане и прочих убунтах есть фирменный чит: apt-get source <какая-нибудь программа работающая с UART>. Желательно маленькая, чтобы разбираться поменьше было. Например, stm32flash (прошивалка STM32 по UART). Или тот же picocom (но он работает с текстовыми данными и не лучшим образом, это отдельный случай и его я не порекомендую). Получите сорц программы, при том - заведомо более-менее рабочей. Позволит посмотеть "а как это делали другие". Вообще, пакетный менеджер и открытый софт - штука хорошая. В винде такой чит не получится, хоть там что.
> Вообще спасибо за советы! Очень путные!
Ну еще бы - я по таким грабелькам уже попрыгал :).
А еще - за неделю можно было бы задолбаться и накормить поисковик очевидными кейвордами. И в первых строках найти что-то типа http://tldp.org/HOWTO/Serial-Programming-HOWTO/index.html - с рассказом что есть UART и с какого бока к нему заходить. Кстати говоря, даже в винде с UART есть свои бестолковости, особенности и грабли. Самая очевидная грабля с которой я столкнулся: винда врет про успех установки baud rate, каким бы он ни был, даже бредовым. Это вынуждает городить нефиговые костыли иной раз. В линухе соотв. вызовы честно отлупляют статус: если порт такой baud не умеет - выставить его и не дадут, собственно.
