Обновление прошивки через эзернет, Как сделать удобнее для пользователя, какой протокол? Опции

[Сергей Борщ]

Приветствую всех.

Делаю устройство, у которого основным каналом общения с пользователем будет эзернет. Не могу определиться, как лучше сделать обновление программы в нем. В устройстве есть еще RS-485, CAN, можно даже подцепиться к UART, но подключение компа к этим интерфейсам для обновления прошивки требует каких-то специальных переходников. В моем же случае устройство берет в руки обычный пользователь, у которого никаких переходников нет да и вообще не хотелось бы для обновления делать какие-то дополнительные подключения. Считаем, что устройство установлено в месте, доступ к которому затруднен.
В предельном случае пользователь берет в руки устройство, в котором прошит только загрузчик, т.е. приложение в процессе обновления может и не участвовать (чуть ниже распишу). Оно может сохранить где-то свои сетевые настройки, при отсутствии которых загрузчик берет какой-то статический адрес по умолчанию, скажем 192.168.3.2 и я могу научить пользователя настроить свой комп для связи с этим адресом. А что дальше? Как красивее и удобнее организовать сам процесс обновления? Я делал множество устройств с обновлением через UART, RS-485 и USB (VCP), там у меня все давно отработано, но мне никогда не приходилось до этого делать обновления по эзернету. Вся имеющаяся у меня информация об обновлении через эзернет - это слухи с форумов. Поэтому надеюсь, что более опытные в этом вопросе коллеги направят меня в сторону нужного решения.

Начну с того, чего я не хочу:
1) я не хочу чтобы это устройство лазило куда-то за обновлениями само. Во-первых потому, что у меня нет сайта, куда я мог бы выкладывать обновления и я не имею желания такой сайт делать, поддерживать и содержать. Во-вторых, устройство может находиться в локальной сети не имеющей выхода в интернет. В-третьих - человек должен сам решать когда и, главное, на какую версию обновляться.
2) я не хочу, чтобы пользователю для обновления нужно было на свой компьютер устанавливать какой-то дополнительный сервер или программу-клиента, потому что неизвестно, какая ОС стоит у пользователя и найдется ли бесплатная программа под эту ОС. Тем более не хотелось бы писать никакую программу для компьютерной стороны. У всех есть браузер и хотелось бы ограничиться его возможностями.

Теперь чего хочу:
1) все это должно уместиться в первые сектора STM32F4xx, максимум 48К, поэтому полноценный сайт с апачем или полноценный ФТП-сервер развернуть там не удастся. Хотелось бы, чтобы пользователь попадал на страничку "бла-бла-бла, текущая версия такая-то, нажмите эту кнопку, чтобы выбрать у себя на компе файл обновления", а дальше как тут на форуме при прикреплении файлов к сообщению.

2) Запуск процесса обновления чаще всего будет происходить из работающего приложения, но при отсутсвии приложения (после сбоя обновления или сразу после производства) точно такой же запуск должен быть возможен и средствами самого загрузчика. Из этого вытекает, что загрузчик должен содержать весь минимально необходимый функционал, т.е. быть способным показать пользователю веб-страницу обновления.

3) Чтобы прошивка происходила в процессе передачи файла, то есть чтобы пользователь имел обратную связь и наблюдал на экране какую-то полосу с процентами. Поэтому не хочу, чтобы прошивка сначала сохранялась где-то, а потом загрузчик молча переписывал ее собствено в память контроллера.

4) Я пока очень смутно представляю, как работают веб-морды. Хочу разделить процесс выбора файла и процесс его передачи, т.е. чтобы вот эту страницу выбора файла мог показывать как загрузчик, так и приложение(пункт 1 хотелок), а после выбора файла посылался бы какой-то сигнал серверу, соединение бы закрывалось, контроллер сбрасывался, попадал в загрузчик в режим обновления и уже загрузчик ждал бы нового соединения от браузера с передачей собственно содержимого файла.

Вот такие вот у меня мысли. Странного ли я хочу? Какие еще варианты обновления вы встречали и находили удобными (мне очень хочется, чтобы процесс обновления был удобным). Что еще посоветуете, что раскритикуете?

*********
На борту есть еще SD-карта. Можно было бы создать в ней отдельную директорию, в которую пользователь клал бы свежую прошивку. Класть можно как на компе со считываетем SD-карт, так и через веб-морду в основном приложении. И загрузчик вынимал бы версию прошивки из имен файлов в этой папке, находил самую свежую, сравнивал с текущей и при несовпадении переписывал бы приложение из этого файла. Откат на предыдущую версию сводится к удалению файла самой последней версии и перезагрузке.

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

********
Спасибо форуму. Пока формулировал это сообщение, хотелки стали понятны самому.

[Mahagam]

делал подобное. только у меня лимит был в 64к кажись. uIP стек с DHCP клиентом и веб-мордой. на веб-морде кнопка "upload новую прошивку".
ах да. NetBIOS имя было ещё, чтобы по адресу не обращаться. работало

[AlexandrY]

Ну да, вы даже не поняли, что Java это не средство разработки.

Это уже не важно, как я понял ява тут вообще никого не возбудила.

А вот постоянные TCP соединения кроме самого HTTP на Web странице можно создавать как раз с помощью WebSocket.

[Quasar]

Это уже не важно, как я понял ява тут вообще никого не возбудила.

А вот постоянные TCP соединения кроме самого HTTP на Web странице можно создавать как раз с помощью WebSocket.

Ваш бред с Wi-Fi AP и DHCP сервером на железке тоже и что же теперь? Я рассказал как сделал я, а вы лишь теоретизируете как можно. По поводу создания веб-странички для загрузки ПО хочешь с WebSocket, хочешь стандартными AJAX средствами с POST запросом особо обсуждать нечего, бери и делай. Ну придется немного с http/html/JavaScript разобраться, ну и все собственно.

[zltigo]

Это уже не важно, как я понял ява тут вообще никого не возбудила.

Это совершенно не аргумент. Большинство поступают "как все" - а нехай пользователь лезет и меняет IP я не буду об этом парится, а в устройство запихну, тоже "как все" чего-нибудь потолще, типа линукса и опять не буду париться.
P.S.
Я чего это у Вас в подписи уже давным давно дохлая ссылка висит?

[A. Fig Lee]

Да, вот этим путем я и двигаюсь. На данный момент у меня вопрос вот о чем: пользователь нажал кнопку "обновить". Можно ли сделать так, чтобы по этой кнопке броузер отправлял одно сообщение типа "пааехали", закрывал соединение, а следом в отдельном сообщении и уже новом соединении посылал данные из файла? Для чего мне это нужно: по первому сообщению моя железка перезагрузится и войдет в режим обновления, т.е. в режим, в котором она с определенным таймаутом (скажем, 3 секунды) ожидает нового соединения с данными образа прошивки. Этот момент перезагрузки у меня отделяет собственно обновление от предыдущей работы. После него мне совершенно не важно, кто показывал пользователю страничку с выбором файла - приложение или загрузчик (при отсутсвии приложения). То есть фактически мы имеем три отдельные программы:
1) загрузчик, который умеет только принять файл и на лету из него обновить приложение.
2) приложение, которое кроме основной работы умеет по команде от пользователя запустить загрузчик.
3) минимальное приложение, которое живет в области загрузчика и умеет только проверить целостность приложения и если оно не целое, то по команде от пользователя запустить загрузчик.
Такая схема у меня используется во всех проектах и показала свою неубиваемость. Переход на программу 1 у меня происходит по программному сбросу. Это позволяет начать жизнь с чистого листа и в процессе загрузки не зависеть от настроек периферии, которые могло сделать приложение.

Да, заметно, что Вы и здесь это пытаетесь применить.
Можно, наверное. Вам придется возится с javascript-ом,
который само собой сожрет килобайты.
Или писать все самому или пользовать какой нибудь dojo 27 килобайт и тоже часть писать самому.
События по нажатию на кнопку итиси.



Я бы сделал аплоад там же в загрузчике. Я вон перехожу после аплоад простым jump и ничего.
Ну проверить регистры после джампа, убедится что все чисто, принудительно сбросить.
В принципе вся периферия должна перед инициализацией проходить процесс деинициализации.

Кстати, "моя" схема тоже используется в нескольких проектах и тоже показала свою неубиваемость.

А, появилась неуверенность в голосе.
Признайтесь, тестировали вы это на паре тройке платформ и то кое как.

С java кросс платформенностью гораздо меньше возни чем с разными браузерами.
Не помню, чтоб гдето у java было чтото не кроссплатформенное

[Quasar]

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

По-моему это самый логичный вариант. Веб-морда и все скрипты лежат в основном приложении, не сжирается место в загрузчике, не усложняется процесс обновления переустановкой соединения. На неустойчивой сети это может вызвать проблемы. Если бы у меня была SD карта, я бы сделал так:

1) Страничка загрузки лежит в основной прошивке;
2) С её помощью пользователь загружает фаил прошивки на SD карту, основная прошивка проверяет целостность и если все ok, прыгает в бутлоадер;
3) Бутлоадер, обнаружив новое ПО на карте, начинает его прошивать (расшифровывать и прошивать?), после чего передает прошитому ПО управление, можно еще где-нибудь в ОЗУ оставить флаг статуса последнего обновления, для того, что бы пользователь в веб-морде увидел, что все ok (или не ok);
4) Пока все это происходит, на веб-странице горит прогресс бар (просто таймер на примерное время обновления), после того, как таймер истекает, JavaScript начинает пытаться обновлять страницу, дабы узнать статус.

[AlexandrY]

Кста, только что сделал Telnet по WiFi вот для этой платы - http://geektimes.ru/post/260720/
И сделал Telnet драйвером вместо RS232 для терминала в дивайсе.

Мои дивайсы издавно программируются по Y-modem через RS232.
Реперь же дивайс через CC3100 подключается в Wi-Fi локалку , а если ее нет становится AP и в обоих случаях открывает порт Telnet.
Получая данные по telnet выдает их в задачу терминала вместо RS232.

Открываю программу эмулятора терминала на PC типа TeraTerm и по Telnet старым добрым способом гружу апдейты.

Вот это простота! На микроконтроллере только протокол SimpleLink (портированный на MQX) да пару строчек негоциации telnet.

[zltigo]

Вот это простота!

"Простота" более, чем условная. Сначала добавим цельный Wi-Fi модуль со всем своим стеком, а потом "просто" зайдем телнетом. Нет, я понимаю, что дело идет к тому, что для помигать светодиодом надо просто взять контроллер с линуксом, ну или совсем по минимуму, Java на борту и все, но все-же не надо глупости нести, что все просто. Ну а действительно простому решению - наличию у устройства подключения терминала по RS232 для программирования и отладки, нималейших претензий нет - сам так делаю уже десятки лет.

[_Pasha]

Кому как. Мне проще сделать "как у всех", чем искать или писать и поддерживать еще какую-то хитрую утилиту. Причем обычный пользователь будет видеть это именно как "сделано черз Ж", потому что "не как у всех".

Делал по UDP
Белый сервак плюс серые клиенты.

[Сергей Борщ]

Белый сервак плюс серые клиенты.

А теперь для особо одаренных раскройте эти термины, пожалуйста.

[_Pasha]

Сервер обновлений с белым ip
На нем присутствует демон, udp сокет слушает обращения с любого ip отправителя на фикс. порт, т.е. bind("0.0.0.0",UDP_PORT)
Отвечает тоже по фикс. порту и принятому адресу.

Клиенты имеют "серый" адрес за NATом.
Поскольку NAT искажает номера портов, клиенту приходится слушать все входящие пакеты на любой порт.
В пакете первым находится magic number(32 бита) плюс некоторые внутренние зависимости, скажем - поле команды имеет несколько предопределенных значений.
Отвечать на входящие не нужно, т.к. это UDP - железный клиент просто игнорирует то, что не является программирующим пакетом.
По приему программирующего пакета можно организовать минимальную поддержку сеанса - запомнить порт и по таймауту чтобы он обнулялся, снова открывая для прослушки все пакеты.

Дальше пакеты содержат команды - принять буфер данных (512 байт) по такому-то адресу и старт обновления.
Клент отвечает что мол принял по такому то адресу с таким-то CRC
И что ушел в ребут с обновлением.

Нет ответа - идет повтор. Сервер по таймауту иключает адрес из очереди и делает в своей базе пометку, на чем собсна остановились.

На клиенте:
Код складывается в неиспользованную половину флеша, по старту обновления код работает в ОЗУ и пишет.
Далбнейшие варианты обезопасить процесс - делать своп и оставлять какую-то фиксированную часть под бут.
Чтобы он не мог самоубиться.

ЗЫ. Железо в базе различается по мак-адресу.

Сообщение отредактировал _Pasha - Oct 21 2015, 13:25

[AlexandrY]

Сервер обновлений с белым ip
На нем присутствует демон, udp сокет слушает обращения с любого ip отправителя на фикс. порт, т.е. bind("0.0.0.0",UDP_PORT)
Отвечает тоже по фикс. порту и принятому адресу. ...

У..., как все замудренно.

Вона недавно сделал обмен данными с дивайсами через месенджер Google Hangouts.
Вот это реальное удобство.
Ни где сервер, ни какой он, ни где дивайсы голова не болит.

[_Pasha]

У..., как все замудренно.

Вона недавно сделал обмен данными с дивайсами через месенджер Google Hangouts.
Вот это реальное удобство.
Ни где сервер, ни какой он, ни где дивайсы голова не болит.

О. На джаве?

[Quasar]

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

Ой. Вы хотите сказать, что клиенты, находящиеся за NAT'ом, ВСЕГДА слушают ЛЮБОЙ порт?

Кому как. Мне проще сделать "как у всех", чем искать или писать и поддерживать еще какую-то хитрую утилиту. Причем обычный пользователь будет видеть это именно как "сделано черз Ж", потому что "не как у всех".

Утилиты есть у многих вендоров, у Apple - AirPort, у D-LINK для их свитчей есть какая-то там утилита и т.д,. Это всего лишь вопрос выбранного пути. "Как у всех" или "не как у всех", тут не причем.