/dev/ttyS0

какой там физический проводник - есть реальный RS232/TTL или оно всё симулируется в какой-нибудь виртуальной микросхеме по USB? Если есть реальный - смотрите целостность контактов - ведь отправка и получение по разным проводам

какой там физический проводник?

Кабель EFT данных (Sokkia/ SDL/ PC; 2м)

Пытаюсь сделать обратную операцию.

А она имеет смысл? А то может прибор не ожидает, что ты ему обратно отправишь данные, которые только что от него же и получил.

А то может прибор не ожидает

Прибор в режиме ожидания приёма. Данные не проступают. Заканчивается всё TIMEOUT-ом в приборе.

Прибор в режиме ожидания приёма. Данные не проступают. Заканчивается всё TIMEOUT-ом в приборе.

Всё же не очень я себе представляю для чего может понадобиться отправка _тех_же_ данных обратно.

не очень я себе представляю для чего может понадобиться отправка _тех_же_ данных обратно

Данные - координаты точек. Вручную забивать - зае..шся.

не очень я себе представляю для чего может понадобиться отправка _тех_же_ данных обратно.

Это тест. Если тест я завершу, каким-то образом, то данные закачиваемые в прибор будут слегка другими.

Дай ссылку на исходники прошивки или хотя бы на протокол.

Ты вообще уверен, что прибор умеет принимать вот так — жирным буфером? Может, ему после каждой порции (скажем, строки) данных нужно подтверждение компьютеру отсылать и компьютер на это отвечать должен?

некоторым нужно «stty -clocal»

Если устройство принимает бинарные данные, то там еще какие-то настройки нужно крутить с помощью stty

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

Ставлю на то, что драйвер tty меняет служебные символы для удобоваримой печати в консоль.

-crtscts

Уверен что это нужно? Твой девайс умеет в rts/cts?

А если заглянуть в дамп посмотреть

I. Сброс данных с прибора

1) Настраиваю прием:

$ stty 38400 cs8 -F /dev/ttyS0
$ stty -a -F /dev/ttyS0
speed 38400 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke
$ cat /dev/ttyS0 > 20180426.sdr

2) Панель обмена в приборе

3) Передача

4) Завершение передачи

5) Переданные данные

head ... tail

II. Заливка данных на прибор

1) Подготовка к приёму

2) Передача данных

$ cat 20180426.sdr > /dev/ttyS0

3) Данные не поступают

4) TIMEOUT

Уверен что это нужно?

Не уверен. Пользую метод «научного тыка». Устанавливаю все параметры по очереди в надежде отыскать «нужный». Без параметров результат то пока такой же.

stty -clocal

Попробую завтра. А что он делает кстати?

head ... tail

Мне не нравятся непонятные символы в консоли.

Где гарантия, что один и тот же файл можно без изменений гонять туда и обратно?

Где гарантия, что при приеме, прибор не ждет какой-либо специальной преамбулы, которую, например, шлет оригинальная прога?

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

Где гарантия, что один и тот же файл можно без изменений гонять туда и обратно?

Эти файлы гонялись туда сюда через USB-COM без проблем.

не ждет сигнала CD при открытии устройства.

Хотя, если ты успешно передаешь в устройство данные, то оно ничего не поменяет.

Возможно «stty raw -F /dev/ttyS0» поможет.

То есть вся разница только в ttyS0 и ttyUSB0 ?

Эти файлы гонялись туда сюда через USB-COM без проблем.

сравни вывод «stty -a -F /dev/ttyUSBX» c ttyS0

Дефолтные настройки терминальной дисцилины м.б. разные.

Хотя, если ты успешно передаешь в устройство данные, то оно ничего не поменяет.

Не передаю, принимаю успешно. А вот с передачей на прибор траблы.

Возможно «stty raw -F /dev/ttyS0» поможет.

Самый первый вариант по методу «научного тыка». Но нет. Без изменений.

То есть вся разница только в ttyS0 и ttyUSB0 ?

Разница в том, что раньше я мог одолжить шнурок с адаптером, а сейчас нет. Пытаюсь пользовать то что есть.

сравни вывод «stty -a -F /dev/ttyUSBX» c ttyS0

Не выйдет. Нет шнурка с адаптером = нет /dev/ttyUSBX.

Пытаюсь пользовать то что есть.

я не про это. когда был usb-com вариант с cat <file> > /dev/ttyUSB0 работал?

когда был usb-com вариант с cat <file> > /dev/ttyUSB0 работал?

Не только. И «serial port terminal», и «minicom», и «cat». Всё работало.

тогда принципиальной разницы не вижу. заходи в миником и крути параметры, чтобы из прибора валился нормальный дамп. потом можешь спокойно выйти и попробовать через cat, и там же срисовать те параметры которые поставились через minicom.

заходи в миником и крути параметры

Следующий пункт в методе «научного тыка». Согласен.

Ведь «stty» я почти «отработал».

если поможет.

когда настраиваю обмен через serial то использую такие настройки:

fd_uart = open(defp.dev, O_RDWR | O_NOCTTY | O_NONBLOCK);

options.c_cflag |= (CLOCAL | CREAD); // установка битов
options.c_cflag |= CS8; // опять установка

options.c_cflag &= ~PARENB; // сброс битов
options.c_cflag &= ~CSTOPB;
options.c_cflag &= ~CSIZE;
options.c_iflag &= ~(ICRNL | INLCR);
options.c_iflag &= ~(IXON | IXOFF | IXANY);
options.c_oflag &= ~OPOST;
options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);

использую такие настройки...

Приму во внимание. Шаманить, так шаманить.

Прозвони шнур, точно TX не перебит?

не ждет сигнала CD при открытии устройства.
Хотя, если ты успешно передаешь в устройство данные, то оно ничего не поменяет.

Занудства ради: если установлено детектирование сигнала CD, то его отсутствие не дает именно принимать данные, а cts (clear to send) - передавать.

угу. Это было сделано для модемов, которые поднимали CD после установления коннекта.

угу. Это было сделано для модемов, которые поднимали CD после установления коннекта.

Удивительно, что вас всегда можно поправлять. Сигнал CD именно и означал, что модемы «зацепились», возможность подать команду (данные) на модем опеределяется сигналами DSR/DTR. Теоретически, отсуствие соединения при TTL логике тоже означает 1, потому, те «модемы», которые не имеют CD или даже DTR/DSR/CTS особо не требовали выключение опций у асинхронного порта, но для надежности таки не помешает указывать stty -XXX.

точно TX не перебит?

Скорее всего. Либо сам прибор «хандрит». Попытался через ЗЛО-ОСь 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:

https://www.generatorplus.ru/wa-data/public/shop/products/96/22/2296/images/892/892.500x0.jpg

А просто в гуглопоиске ввести «распайка последовательного порта»?

Спасибо.

Ещё одна:

http://www.compilog.ru/images/raspinovka_COM_porta.gif

Tx «глухой». На COM-штекере разрыва нет. «Заклёп» раздирать не собираюсь. «Обмотку» резать тоже.

ничего не понял из этого набора слов

ничего не понял из этого набора слов

Для этого я просил «знающих» людей схемы COM-разъёма в «тему» линькануть.

Третий провод (TX) у меня «глухой» (не прозванивается). На COM-штекере разрыва нет (разобрал, проверил, собрал обратно). С другой стороны «шнурка» «заклёп» (разбирается только молотком и зубилом).

Какая тебе к чорту схема нужна?

Нормальный прямой кабель это когда все 9 проводов прозваниваются один к одному и еще корпуса разъемов тоже звонятся через отдельный провод. Это если у тебя устройство - DCE.

Если у тебя TxD не звонится, то устройство никак не получит данные от компа.

Если у тебя TxD не звонится, то устройство никак не получит данные от компа.

Так именно это и происходит. Из-за этого и «печалька».