Работа с minicom

Добрый вечер.
Через minicom (wb-2501) не могу отправить команды и прочитать ответы. Все что видно, на скриншоте ниже.


При этом, все символы что набирались (не видны в терминале и не отправляются) после закрытия minicom отправляются в порт.
Это баг или я что-то делаю не так?

Добрый день!

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

Наверное я неправильно описал проблему, с Wirenboard7 я пытаюсь опросить модем, который подключен к RS485-2, для этого хотел использовать утилиту minicom, но она не работает (поведение как описано в первом сообщении на нескольких WB7). Для теста утилиты minicom, к порту RS485-2 WB7 вместо модема я подключил COM-порт ПК. В minicom не отображается то, что отправляется с ПК, единственное на ПК пришли все набранные символы только после закрытия minicom (при этом символы не видно в самом minicom, все что видно на скриншоте в первом сообщении).

Добрый день!

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

Создание архива описано в документации.

Архив в ЛС отправил. “список команд, которые вы вводили как с контроллера, так и с ПК”-любые символы, ну например “AT”.

Добрый день!
Можете уточнить, как настраивали модем? Какой модем подключён к шине?

Модем ОВЕН, но это не особо важно, так как не работает даже прямое подключение WB7 к ПК. Сам модем опрашивается с ПК, также работает с установленной MasterSCADA на WB7. Само собой я проверяю, перед подключением minicom, что порт не занят другими службами (ну и выключен в программах) Проблема только в minicom, то что он не работает.

Запускаю так
minicom -D /dev/ttyRS485-2 -b 19200 -8 -a off

Добрый день!

Судя по команде, все верно. Проверьте логи на наличие ошибок с помощью команды:

dmesg | grep tty

Есть ли там ошибки?

[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait ro
[    0.977870] printk: console [ttyS0] disabled
[    0.978020] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 52, base_baud = 1500000) is a Allwinner sun4i
[    1.941976] printk: console [ttyS0] enabled
[    2.405127] 1c28800.serial: ttyS2 at MMIO 0x1c28800 (irq = 53, base_baud = 1500000) is a Allwinner sun4i
[    5.595417] systemd[1]: Created slice system-getty.slice.
[    5.689174] systemd[1]: Created slice system-serial\x2dgetty.slice.
[   20.513620] 1c29c00.serial: ttyS7 at MMIO 0x1c29c00 (irq = 130, base_baud = 1500000) is a Allwinner sun4i
[   20.700613] 1c28c00.serial: ttyS3 at MMIO 0x1c28c00 (irq = 131, base_baud = 1500000) is a Allwinner sun4i
[   22.035891] 1c29000.serial: ttyS4 at MMIO 0x1c29000 (irq = 132, base_baud = 1500000) is a Allwinner sun4i

Спасибо, мне потребуется некоторое время для ответа.

Проверяю.
Беру и пишу банальный “эхо” для rs-485.
Ну и вижу что-то действительно странное. Пожалуй проверю завтра на разных контроллерах.

1 лайк

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

1 лайк

Также я решил проверить работу с serial-tool, но и там у меня возникла проблема, возможно они связаны.

Перезапускался ли колнтроллер перед этим? Проверил:

serial_tool -b 9600 -p N -d 8 -s 2 -t 1 /dev/ttyRS485-2
serial_tool on /dev/ttyRS485-2: 9600 8N2.0
Enter your commands below in HEX form. 
All characters but 0-9,a-f including spaces are ignored.
Press Control-D or Control-C to leave the application.
Press [Enter] to print received data
>> 8D 03 00 80 00 01 9A EE
<< 8D 03 02 00 8D 69 FE`

Нет не перезапускался. Сейчас запустил контроллер и проверил еще раз, в целом работает, НО заметил одну странность, если после таймаута отправить ответ с ПК, то при следующей отправки команды с WB, этот ответ подставится.

И после работы с minicom перестают поступать ответы в serial-tool

Логично, так как он в буфере, откуда его некому читать. Это как раз ожидаемо.

А про это - уже у разработчиков, по моему поверхностному дебагу меняется режим управления порта и остается в таком виде. То есть будет починено обновлением.

Вчера трижды сдувал трансмиттер на периферийном устройстве - не догадался сразу ткнуться анализатором в ноги контроллера.

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

Тогда напишите, как появится обновление с исправлением