Есть несколько устройств WB-MSW v.3 работающих по rs485 за шлюзом MGE.
Есть описанная процедура обновления прошивок у таких устройств с использованием wb-mcu-fw-updater через socat (со сменой скорости и т.п.). До последнего времени (12/2022 
) всё работало нормально.
При попытке воспользоваться накатанной схемой сейчас wb-mcu-fw-updater (testing v1.8.1 ) начал ругаться на занятость порта который эмулирует socat ( /dev/rs-5 Will be paused and resumed after finish [Y/N]).
Если выбрать Y - прибивается socat а с ним и канал связи
Если выбрать N - “Stop socat … manually!” и утилита прерывается.
Выяснил что виновата проверка через fuser занятости порта в файле wb_mcu_fw_updater/update_monitor.py . Даже понятно для чего сделано - чтоб wb-mqtt-serial прибивать.
Но теперь или инструкцию поправьте предложив иной метод или утилитку wb-mcu-fw-updater чтоб понимала на что реагировать а что пропускать как норму.
Добрый день. Перед запуском socat вы останавливаете wb-mqtt-serial?
Да.
fuser показывает что порт свободен.
После запуска socat он естественно занимается socat ом.
Именно об этом и говорят все сообщения от wb-mcu-fw-updater
Можно было попробовать обновить через флешер - но что-то руки не дошли (хотя наверное он использует тотже набор библиотек)
Да, судя по всему мы это сломали. Подумаем, как починить. Спасибо за сообщение, отпишемся тут.
Не придумали еще? Вопрос актуален.
Здравствуйте, багрепорт разработчикам оформлен, пока не брали в разработку, но поставили в план.
Подскажите не рассматривается вариант добавления функционала обновления через шлюз в саму утилиту wb-mcu-fw-updater, например с ключом -gw или -mge? Вся необходимая информация в конфигурационных файлах есть, чтобы автоматически все могли делать без танцев с бубном вокруг утилиты socat.
IMHO наиболее простым вариантом (кроме удаления проверки из кода нафиг) было бы внесение ключа запуска утилиты при котором проверка отключалась бы.
К сожалению не силен в питоне -но если есть нужный навык убрать проверку из скрипта не трудно.
В обозримом будущем есть планы перевода этой утилиты на RPC (это такой внутренний протокол контроллера) — оно должно решить проблему обновления на скорости 9600.
Но чтобы обновлять ещё и устройства на любой другой скорости, надо вносить изменения в загрузчик устройств. Задача есть, сроков пока на это нет.
Проблема локализована, задача в разработку стоит. Добавили в инструкцию обновление через флешер — это временное рабочее решение: Утилита socat — Wiren Board
Темы закрываю.
Т.е. предлагается просто натравливать флешер на порт socat ? А вы проверяли что это работает? Как я припоминаю там те же библиотеки с той же проверкой занятости порта…
Раньше wb-mcu-fw-updater был обёрткой для флешера и там не было контроля занятости порта. Потом wb-mcu-fw-updater переписали на собственную реализацию протокола обновления и тоже без контроля занятости порта.
Позже добавили проверку, так как часто была проблема, что чей-то софт читает/пишет в порт и тут wb-mcu-fw-updater вмешивается и в устройстве портится прошивка. Этим и сломали костыль, с помощью которого обновлялись устройства. Сделаем хорошо в одном из обновлений, пока решение — флешер.
Я лично не проверял — это рекомендация пользователей и она работает: Telegram: Contact @wirenboard
Эта тема была автоматически закрыта через 7 дней после последнего ответа. В ней больше нельзя отвечать.