LINUX.ORG.RU
ФорумAdmin

работа с модемом через screen

 , ,


0

1

модем wavecom, подключается по usb
долго бьюсь с этой железкой, результаты таковы:

в миникоме или screen, если сделать ATE0 - команды выполняются довольно быстро

at+ccid - для получения ccid симки
at+cmgl=«all» - чтение смсок
и несколько других

но если выполнять команды из питона 3 с модулями pygsm + serial
то модем виснет в самых разных местах, тупо на чтении из устройства /dev/ttyUSB0

ковырял оба модуля, все упирается в чтение из устройства - оно попросто может не отвечать несколько минут

на винде тот же код вообще вечно висит на чтении смсок

Модуль ftdi_sio в lsmod присутствует. И как я понимаю, его нельзя как-то обновить. Он либо есть и обеспечивает появление /dev/ttUSB0-.., либо его нет и устройств нет.

Пробовал на другом ноуте с дебианом (у меня арч) - там картина такая же.

На винде через путти все работает быстро.

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

Вопрос в том, можно ли как-то заставить выполнять команды minicom или screen?

Надо что-то вроде:

<прога> -c AT+CMGL=«ALL»
и на выводе валятся прочитанные смски

реально найти такое?

Ну или понять отчего идут эти глухие зависания.

★★★

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

общение с модемом через миником это же не цель?

Обычно такие проблемы бывают из-за буферизации. Это можно увидеть strace-ом. Нужна либо строчная буферизация или совсем без нее. Или fflush после вывода каждой команды в порт.

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

спасибо
подскажите, эта буферизация определяется командами к модему (например команда для включения строчной буферизации) или это делается в софте (в моем случае модули питона pygsm/serial)?

пока не нагуглил ничего вразумительного

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

в софте.

Запустри программу через strace и увидишь, сразу данные передаются в модем или нет.

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

я приаттачил к питоновскому процессу

psgrep python3
user 27876 18.0 0.2 477720 22452 ? Sl 22:47 0:00 /usr/local/bin/python3 /home/user/start.py

sudo strace -p 27876 -o test

Однако в файле минимум информации:

cat test
futex(0x11e9e10, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x12cece0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x12d9fa0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x7f60980008c0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x87e424, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x87e420, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x87e3e0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x12f4590, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
write(1, «<script>clearInterval(window.tim»..., 48) = 48
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f60b85e3880}, {0x4df770, [], SA_RESTORER, 0x7f60b85e3880}, 8) = 0
exit_group(0) = ?
+++ exited with 0 +++

Похоже это то, что питон отвечает апачу, которым он запускается как cgi

Последил за миникомом, там вроде все в порядке.
Как же отследить что и когда пишется в устройство /dev/ttyUSB0 питоном?

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

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

IMHO оно у тебя тредовое, а это всегда дополнительный набор граблей ( во всем ).

Кстати, дурацкий вопрос - а uid/gid из под которого идет обмен с модемом имеет права на запись в /dev/ttyUSB0 ?

Отладка через веб-вервер весьма утомительна. Что мешает взять кусок кода и запустить его отдельно?

PS это в development нужно переносить.

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

интересен только процесс, который взаимодействует с модемом

точно, у меня к модему подключаются отдельные треды

имеет права на запись в /dev/ttyUSB0 ?

да, скрипт просто делает «sudo chmod 666 /dev/ttyUSB0» при запуске

Что мешает взять кусок кода и запустить его отдельно

спасибо, так и сделаю

Вот ещё интересный момент: 15 потоков одновременно начали работать с устройствами /dev/ttyUSB0-14

сделали некоторые действия, но потом разом все отвалились.
ls показал что в системе больше нет USB0-14, зато появились USB15-30

что это вообще было?
как многопоточный питон может убивать устройство?

*usb-шнур один, это пул модемов

sergey-novikov ★★★
() автор топика
Ответ на: комментарий от sergey-novikov

дык dmesg обычно при этом говорит нехорошие слова в адрес usb-устройств, ресетит их и находит под новым именем ( т.к. старое еще используется)

Нужно настраивать udev чтоб после ресета устройства и последующего его обнаружения об этом узнавала программа работавшая с ним (например через сигналы (и снова здрасте треды)) и чтоб устройству сохраняли имя (как это сделать - сильно зависит от usb-устройства)

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