/dev/ttyS0
К /dev/ttyS0 через шнур подключено устройство.
Получаю с прибора данные
Всё ок. Пытаюсь сделать обратную операцию.
Прибор в режиме ожидания приёма. Данные не проступают. Заканчивается всё TIMEOUT-ом в приборе.
Что я делаю не так?
PS: Илюстрации по «теме»:
какой там физический проводник — есть реальный RS232/TTL или оно всё симулируется в какой-нибудь виртуальной микросхеме по USB? Если есть реальный — смотрите целостность контактов — ведь отправка и получение по разным проводам
Пытаюсь сделать обратную операцию.
А она имеет смысл? А то может прибор не ожидает, что ты ему обратно отправишь данные, которые только что от него же и получил.
Прибор в режиме ожидания приёма. Данные не проступают. Заканчивается всё TIMEOUT-ом в приборе.
Прибор в режиме ожидания приёма. Данные не проступают. Заканчивается всё TIMEOUT-ом в приборе.
Всё же не очень я себе представляю для чего может понадобиться отправка _тех_же_ данных обратно.
не очень я себе представляю для чего может понадобиться отправка _тех_же_ данных обратно
Данные — координаты точек. Вручную забивать — зае..шся.
не очень я себе представляю для чего может понадобиться отправка _тех_же_ данных обратно.
Это тест. Если тест я завершу, каким-то образом, то данные закачиваемые в прибор будут слегка другими.
Дай ссылку на исходники прошивки или хотя бы на протокол.
Ты вообще уверен, что прибор умеет принимать вот так — жирным буфером? Может, ему после каждой порции (скажем, строки) данных нужно подтверждение компьютеру отсылать и компьютер на это отвечать должен?
некоторым нужно «stty -clocal»
Если устройство принимает бинарные данные, то там еще какие-то настройки нужно крутить с помощью stty
А если заглянуть в дамп посмотреть, что там за байты (особенно интересует конец строки) а потом это сравнить с тем что ожидает твой тахеометр.
Ставлю на то, что драйвер tty меняет служебные символы для удобоваримой печати в консоль.
Уверен что это нужно? Твой девайс умеет в rts/cts?
А если заглянуть в дамп посмотреть
I. Сброс данных с прибора
1) Настраиваю прием:
5) Переданные данные
II. Заливка данных на прибор
2) Передача данных
Не уверен. Пользую метод «научного тыка». Устанавливаю все параметры по очереди в надежде отыскать «нужный». Без параметров результат то пока такой же.
Попробую завтра. А что он делает кстати?
Мне не нравятся непонятные символы в консоли.
Где гарантия, что один и тот же файл можно без изменений гонять туда и обратно?
Где гарантия, что при приеме, прибор не ждет какой-либо специальной преамбулы, которую, например, шлет оригинальная прога?
Для гарантированного разрешения этого вопроса лучше всего в параллель прицепить еще один последовательный порт и слить случай заливки в прибор координат с официальной утилиты на этот прибор. Не знаю как у вас с такими возможностями, но как вариант, можно в виртуалку с вендой пробросить сериал-порт, а в линуксе его распараллелить, чтобы либо не только в физический порт но и в файл.
Где гарантия, что один и тот же файл можно без изменений гонять туда и обратно?
Эти файлы гонялись туда сюда через USB-COM без проблем.
не ждет сигнала CD при открытии устройства.
Хотя, если ты успешно передаешь в устройство данные, то оно ничего не поменяет.
Возможно «stty raw -F /dev/ttyS0» поможет.
То есть вся разница только в ttyS0 и ttyUSB0 ?
Эти файлы гонялись туда сюда через USB-COM без проблем.
сравни вывод «stty -a -F /dev/ttyUSBX» c ttyS0
Дефолтные настройки терминальной дисцилины м.б. разные.
Хотя, если ты успешно передаешь в устройство данные, то оно ничего не поменяет.
Не передаю, принимаю успешно. А вот с передачей на прибор траблы.
Самый первый вариант по методу «научного тыка». Но нет. Без изменений.
То есть вся разница только в ttyS0 и ttyUSB0 ?
Разница в том, что раньше я мог одолжить шнурок с адаптером, а сейчас нет. Пытаюсь пользовать то что есть.
сравни вывод «stty -a -F /dev/ttyUSBX» c ttyS0
Не выйдет. Нет шнурка с адаптером = нет /dev/ttyUSBX.
я не про это. когда был usb-com вариант с cat > /dev/ttyUSB0 работал?
когда был usb-com вариант с cat > /dev/ttyUSB0 работал?
Не только. И «serial port terminal», и «minicom», и «cat». Всё работало.
тогда принципиальной разницы не вижу. заходи в миником и крути параметры, чтобы из прибора валился нормальный дамп. потом можешь спокойно выйти и попробовать через cat, и там же срисовать те параметры которые поставились через minicom.
заходи в миником и крути параметры
Следующий пункт в методе «научного тыка». Согласен.
Ведь «stty» я почти «отработал».
когда настраиваю обмен через serial то использую такие настройки:
Приму во внимание. Шаманить, так шаманить.
Прозвони шнур, точно TX не перебит?
не ждет сигнала CD при открытии устройства.
Хотя, если ты успешно передаешь в устройство данные, то оно ничего не поменяет.
Занудства ради: если установлено детектирование сигнала CD, то его отсутствие не дает именно принимать данные, а cts (clear to send) — передавать.
угу. Это было сделано для модемов, которые поднимали CD после установления коннекта.
угу. Это было сделано для модемов, которые поднимали CD после установления коннекта.
Удивительно, что вас всегда можно поправлять. Сигнал CD именно и означал, что модемы «зацепились», возможность подать команду (данные) на модем опеределяется сигналами DSR/DTR. Теоретически, отсуствие соединения при TTL логике тоже означает 1, потому, те «модемы», которые не имеют CD или даже DTR/DSR/CTS особо не требовали выключение опций у асинхронного порта, но для надежности таки не помешает указывать stty -XXX.
Скорее всего. Либо сам прибор «хандрит». Попытался через ЗЛО-ОСь TopoCad-ом, результат тот же. Принимает данные легко, передача — по нулям.
Если бы знал как, прозвонил бы. Интересно всё-таки, что сбоит, шнурок или прибор.
Заметка на «всякий случай»:
Для подбора параметров tty к геодезическим приборам есть tcl-скрипт ComEasy.
Мне быстро «помог» понять, что дело не в /dev/ttySX, а в «шнурке», либо приборе.
берёшь мультиметр, пинаут, смотришь сопротивление, если в мультиметре пищалки нет. Если сопротивление не нулевое — возможен обрыв.
В кабеле что втыкается в прибор закороти rx-tx и глянь в minicom есть ли эхо. Может с проводами что.
соедени ноги 2-3 если 9-контактный разъем и посмотри есть ли эхо в миникоме. С выключенным hardware flow control. Если нету — чини провод.
То есть провод одним концом в комп а на другом перемычка. Из прибора вытащен.
Ни к чему. «Звонилку» нашёл у электриков. Tx «глухой». COM-штекер разобрал — разрыва нет. А разрывать противоположный «заклёп» не вижу смысла, как и «обёртку» резать. Не судьба видать.
PS: Не нашёл нормальной схемы COM-разъёма, либо COM-штекера (Wiki походу таджик состовлял). Если кто найдёт стоящую, линьканите в тему, а то, что за «Tx», «Rx» и еже, не очень понятно окружающим.
Разница в том, что раньше я мог одолжить шнурок с адаптером, а сейчас нет. Пытаюсь пользовать то что есть.
Уже была такая же тема на лоре и, похоже, с таким же финалом. Ты, случаем, к TTL уарту не цепляешь ли напрямую выход RS-232 с ПК? Вангую, что с «одолженным шнурком» теперь тоже работать не будет. Хорошо, если в устройстве какой-то буфер есть, а если нет, то только контроллер менять.
А просто в гуглопоиске ввести «распайка последовательного порта»? Ещё употребляют слово «распиновка».
А просто в гуглопоиске ввести «распайка последовательного порта»?
Не нашёл нормальной схемы COM-разъёма, либо COM-штекера
а твое устройство точно cts выставляет в сторону компа? а то может там висячка.
и попробуй minicom запустить и с его помощью ручками пообщаться со своим устройством
и попробуй minicom запустить и с его помощью ручками пообщаться со своим устройством
Tx «глухой». На COM-штекере разрыва нет. «Заклёп» раздирать не собираюсь. «Обмотку» резать тоже.
PS: Более-менее достойная схема COM:
А просто в гуглопоиске ввести «распайка последовательного порта»?
Источник
Linux: разница между / dev / console, / dev / tty и / dev / tty0
В системе Linux, в чем разница /dev/console , /dev/tty и /dev/tty0 ?
Каково их соответствующее использование и как они сравниваются?
В старые добрые времена /dev/console была консоль системного администратора. И TTY были последовательными устройствами пользователей, подключенными к серверу. Сейчас /dev/console и /dev/tty0 представляем текущий дисплей и обычно одинаковы. Вы можете переопределить его, например, добавив console=ttyS0 в grub.conf . После этого ваш /dev/tty0 монитор и /dev/console есть /dev/ttyS0 .
Упражнение, чтобы показать разницу между /dev/tty и /dev/tty0 :
Переключитесь на 2-ую консоль нажатием Ctrl + Alt + F2 . Войти как root . Тип sleep 5; echo tty0 > /dev/tty0 . Нажмите Enter и переключитесь на 3-ю консоль, нажав Alt + F3 . Теперь переключитесь обратно на 2-ю консоль, нажав Alt + F2 . Введите sleep 5; echo tty > /dev/tty , нажмите Enter и переключитесь на 3-ю консоль.
Вы можете видеть, что tty это консоль, с которой начинается процесс, и tty0 всегда текущая консоль.
/dev/console это виртуальный набор устройств, который можно установить в качестве параметра во время загрузки. Он может быть перенаправлен на последовательное устройство или виртуальную консоль и по умолчанию указывает на /dev/tty0 . Когда console= в ядро передается несколько опций, вывод консоли будет идти на более чем одно устройство.
/dev/tty0 текущая виртуальная консоль
/dev/tty[1-x] это один из виртуальных консолей вы переключитесь с control — alt — F1 и так далее.
/dev/tty это своего рода псевдоним консоли (физического, виртуального или псевдоустройства, если таковое имеется), связанный с процессом, который его открывает. В отличие от других устройств, вам не нужны привилегии root для записи на него. Также обратите внимание, что такие процессы, как запущенные cron и подобные пакетные процессы, не могут быть использованы /dev/tty , поскольку они не связаны ни с какими. Эти процессы есть ? в TTY столбце ps -ef вывода.
/ DEV / консоли
В Linux консоль ядра можно настроить с помощью параметра console= загрузки . Код ядра, который вызывает, printk() может записывать в него сообщения, например, когда устройство загружено или возникает ошибка. Эти сообщения также буферизируются ядром. (См. Также dmesg ). Когда консольное устройство найдено и запущено, оно получает все ранее буферизованные сообщения.
Вы можете передать console= несколько раз, чтобы настроить несколько консолей, и сообщения будут записаны на всех них. Очевидно, вы можете выбрать только одну консоль каждого «типа»: вы не можете использовать оба console=ttyS0 и console=ttyS1 .
Документация ядра указывает, /dev/console что символьное устройство нумеруется (5,1) . При открытии этого символьного устройства открывается «главная» консоль, которая является последним tty в списке консолей. Первый неядерный процесс, называемый init или «PID 1», запускается с /dev/console подключением к стандартному выводу, стандартной ошибке и стандартному вводу.
Если ни одна из консолей не является tty, то открытие /dev/console возвращает ошибку ENODEV («Нет такого устройства»). Ядро будет Распечатать зарегистрировать сообщение и начать init независимо. Для примера консоли ядра, которая не является устройством tty, см. netconsole Или моя любимая консоль линейный принтер .
Вы также можете увидеть список tty консолей, прочитав /sys/class/tty/console/active . В документации systemd указывается, что первое показанное устройство является главной консолью. Список на самом деле в обратном порядке командной строки ядра. В текущей документации ядра неверно указано, что последнее показанное устройство является основной или «активной» консолью. По какой-то причине возможно опросить этот файл на предмет изменений (в случае удаления консольных устройств?).
Внутри systemd-nspawn контейнера стандартный /dev/console файл заменяется псевдо-терминальным устройством (PTY). Их лучше всего описать как виртуальные терминальные устройства. Они создаются динамически, а также используются для реализации графических эмуляторов терминала, таких как GNOME Terminal, и для удаленного доступа ssh .
/ DEV / tty0
Узлы устройства Linux TTY tty1 через tty63 виртуальные терминалы. Их также называют VT или виртуальными консолями. Они моделируют несколько консолей поверх физического драйвера устройства консоли. Только одна виртуальная консоль отображается и контролируется одновременно. Активный терминал может быть переключен, например, используя chvt , или Ctrl + Alt + F1 через любое количество функциональных клавиш, которые у вас есть.
Вы также можете читать и писать в текущий VT, используя /dev/tty0 . tty0 обычная консоль ядра, например, если вы не выбрали явно. «Система сначала ищет VGA-карту [на которой работают VT], а затем — последовательный порт». Вы также можете установить консоль на определенный VT, например console=tty1 .
«Если в вашей системе нет карты VGA, первый последовательный порт автоматически станет консолью». Подобно «последовательной консоли», ttyS0 вероятно, является наиболее распространенной альтернативой tty0 . Невозможно использовать систему VT поверх последовательной консоли.
/ DEV / TTY
/dev/tty является одним из трех стандартных файлов устройств, указанных в POSIX ( /dev/ это одно из трех имен каталогов, указанных в POSIX). Открытие его эквивалентно открытию управляющего терминала текущего процесса. Управляющий терминал устанавливается, когда процесс впервые открывает терминал, по крайней мере, в Linux . Например, в init , это будет относиться к /dev/console .
Отсоединение от управляющего терминала является одним из шагов, традиционно необходимых для запуска фонового процесса, например , демона системного входа . Шаги, чтобы стать фоновым процессом, ужасно запутаны, но, если быть точным, шаг, который отсоединяется от управляющего терминала, является системным вызовом setsid . В более современных системах система init, например, systemd, запускает службу без какого-либо управляющего терминала.
Источник
