LINUX.ORG.RU

/dev/ttyS0

 


0

1

К /dev/ttyS0 через шнур подключено устройство.

stty 38400 cs8 -parenb -crtscts -echo -F /dev/ttyS0

Получаю с прибора данные

cat /dev/ttyS0 > 20180425.sdr

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

cat 20180425.sdr > /dev/ttyS0

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

Что я делаю не так?

PS: Илюстрации по «теме»:

1) Схема COM-порта: http://www.compilog.ru/images/raspinovka_COM_porta.gif

2) «Шнурок»: http://www.eft-akc.ru/sokkia/403-0-0075-EFT

3) «Прибор»: http://i104.fastpic.ru/big/2018/0426/ef/33d0a65a706f706b1be089e52d529bef.jpg

Deleted

Последнее исправление: Deleted (всего исправлений: 1)

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

GPFault ★★
()

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

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

Deleted
()

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

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

anonymous
()

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

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

vel ★★★★★
()

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

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

yax123 ★★★★★
()
Ответ на: комментарий от yax123

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

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

Deleted
()
Ответ на: комментарий от redixin

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

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

Deleted
()
Ответ на: комментарий от Deleted

head ... tail

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

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

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

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

yax123 ★★★★★
()
Ответ на: комментарий от yax123

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

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

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

vel ★★★★★
()
Ответ на: комментарий от Deleted

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

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

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

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

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

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

Deleted
()
Ответ на: комментарий от yax123

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

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

Deleted
()
Ответ на: комментарий от vel

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

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

Deleted
()
Ответ на: комментарий от yax123

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

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

Deleted
()
Ответ на: комментарий от Deleted

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

yax123 ★★★★★
()
Ответ на: комментарий от yax123

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

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

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

Deleted
()
Ответ на: комментарий от Deleted

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

когда настраиваю обмен через 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);
yax123 ★★★★★
()
Последнее исправление: yax123 (всего исправлений: 1)
Ответ на: комментарий от yax123

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

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

Deleted
()
Ответ на: комментарий от vel

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

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

vodz ★★★★★
()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от vel

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

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

vodz ★★★★★
()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от Dark_SavanT

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

Скорее всего. Либо сам прибор «хандрит». Попытался через ЗЛО-ОСь TopoCad-ом, результат тот же. Принимает данные легко, передача - по нулям.

Прозвони шнур

Если бы знал как, прозвонил бы. Интересно всё-таки, что сбоит, шнурок или прибор.

Deleted
()
Ответ на: комментарий от vel

Заметка на «всякий случай»:

Для подбора параметров tty к геодезическим приборам есть tcl-скрипт ComEasy.

Мне быстро «помог» понять, что дело не в /dev/ttySX, а в «шнурке», либо приборе.

Deleted
()
Ответ на: комментарий от Deleted

берёшь мультиметр, пинаут, смотришь сопротивление, если в мультиметре пищалки нет. Если сопротивление не нулевое - возможен обрыв.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Deleted

В кабеле что втыкается в прибор закороти rx-tx и глянь в minicom есть ли эхо. Может с проводами что.

hbars ★★★★★
()

соедени ноги 2-3 если 9-контактный разъем и посмотри есть ли эхо в миникоме. С выключенным hardware flow control. Если нету - чини провод.

slapin ★★★★★
()
Ответ на: комментарий от slapin

а на другом перемычка

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

PS: Не нашёл нормальной схемы COM-разъёма, либо COM-штекера (Wiki походу таджик состовлял). Если кто найдёт стоящую, линьканите в тему, а то, что за «Tx», «Rx» и еже, не очень понятно окружающим.

Deleted
()
Ответ на: комментарий от Deleted

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

Уже была такая же тема на лоре и, похоже, с таким же финалом. Ты, случаем, к TTL уарту не цепляешь ли напрямую выход RS-232 с ПК? Вангую, что с «одолженным шнурком» теперь тоже работать не будет. Хорошо, если в устройстве какой-то буфер есть, а если нет, то только контроллер менять.

anonymous
()
Ответ на: комментарий от Deleted

А просто в гуглопоиске ввести «распайка последовательного порта»? Ещё употребляют слово «распиновка».

ABW ★★★★★
()
Ответ на: комментарий от ABW

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

Не нашёл нормальной схемы COM-разъёма, либо COM-штекера

Deleted
()

а твое устройство точно cts выставляет в сторону компа? а то может там висячка...

и попробуй minicom запустить и с его помощью ручками пообщаться со своим устройством

anto215 ★★
()
Ответ на: комментарий от anto215

и попробуй minicom запустить и с его помощью ручками пообщаться со своим устройством

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

PS: Более-менее достойная схема COM:

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

anto215 ★★
()
Ответ на: комментарий от anto215

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

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

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

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

anto215 ★★
()
Ответ на: комментарий от anto215

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

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

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.