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

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

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

Делаю устройство, у которого основным каналом общения с пользователем будет эзернет. Не могу определиться, как лучше сделать обновление программы в нем. В устройстве есть еще 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) Для записи самой первой прошивки на карточку надо иметь считыватель.

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

[HardEgor]

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

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

У вас два несовместимых пункта. Новую прошивку придется сохранять где-то(в памяти, на SD-карте), плюс лучше делать бэкап текущей, потому что если что-то пошло не так - например отключилось питание прошиваемого устройства, то вы получите "кирпич", а так есть вариант поднять bootloader'ом. Обычно кстати bootloader'ы работают по tftp, потому что он проще чем http.

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

Посмотрите как это сделано во всяких wi-fi роутерах. Вписан фиксированный адрес типа 192.168.0.1 и все нормально на него настраиваются и подключают.
Саму страничку, которую контроллер будет отдавать броузеру для обновления можно взять там-же и её можно существенно упростить если выкинуть все красивости.
Вам надо почитать как работает протокол http, тогда отпадут многие вопросы. По-простому, броузер посылается http-серверу ASCII команды, в ответ получает поток данных(содержащих html-страницы). Командами GET или POST броузер может сказать http-серверу что он отправляет бинарные данные. Как понимаете, контроллеру потребуется иметь собственный http-сервер, но можно самому написать simple-httpd, которые выполняет две-три команды протокола http, больше и не потребуется. Он-же и выдаст клиенту возникающие ошибки, но, чем сложнее интерфейс с пользователем - тем сложнее будет сервер.

Есть два момента определяющие сложность загрузчика через Ethernet - будет-ли необходима защита, т.е. будет ли обновление производится через общедоступные сети или это будет локальная сеть.

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

У вас два несовместимых пункта. Новую прошивку придется сохранять где-то(в памяти, на SD-карте), плюс лучше делать бэкап текущей, потому что если что-то пошло не так - например отключилось питание прошиваемого устройства, то вы получите "кирпич", а так есть вариант поднять bootloader'ом.

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

Обычно кстати bootloader'ы работают по tftp, потому что он проще чем http.

Сложность в разумных пределах меня не пугает. scmRTOS+lwIP+DHCP вчера заняли 33 К, нашел очень компактный HTTP-парсер, есть надежда уложиться в 48 К.

Посмотрите как это сделано во всяких wi-fi роутерах. Вписан фиксированный адрес типа 192.168.0.1 и все нормально на него настраиваются и подключают.

Вот я тоже не понимаю, почему вопрос настройки сетевого адреса вызвал такое обсуждение. Я тут не вижу никакой проблемы. Приложение сохраняет сетевые настройки во флеше. Загрузчик их берет оттуда, т.е. загрузчик работает на тех настройках, которые были у приложения. Если настроек там нет, то приложение еще не запускалось и загрузчик висит на прибитом гвоздями фиксированном адресе. Подключение к нему не сложнее подклюения к свежекупленному домашнему маршрутизатору. Любого пользователя можно отослать к инструкции от любого маршрутизатора. Все, на этом вопрос сетевых настроек предлагаю свернуть.

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

Разумеется, я же так ее и описал: строка текста, поле ввода имени файла и кнопка "обновить". _pv в третьем сообщении темы дал хорошую ссылку.

Как понимаете, контроллеру потребуется иметь собственный http-сервер, но можно самому написать simple-httpd, которые выполняет две-три команды протокола http, больше и не потребуется. Он-же и выдаст клиенту возникающие ошибки, но, чем сложнее интерфейс с пользователем - тем сложнее будет сервер.

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

Есть два момента определяющие сложность загрузчика через Ethernet - будет-ли необходима защита, т.е. будет ли обновление производится через общедоступные сети или это будет локальная сеть.

Это будет локальная сеть. Проект открытый, защита от чтения прошивки не нужна. Если в следующих проектах потребуется защита, добавлю AES-шифрование из предыдущих проектов.

[AlexandrY]

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

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

На IOS не работает! Сафари умеет грузить только картинки! Юзер останется недоволен [/off]

О, а у вас уже проблемы.

Невозможность аплодить произвольные файлы из мобильного Safari знает весь интернет.
Он же знает как это обойти.
Такую мелочь по сравнению с вашей явой могли бы и не упоминать.

[Quasar]

О, а у вас уже проблемы.

Невозможность аплодить произвольные файлы из мобильного Safari знает весь интернет.
Он же знает как это обойти.
Такую мелочь по сравнению с вашей явой могли бы и не упоминать.

То есть начали с того, что пользователь не может IP поменять, а теперь домохозяйка, решившая обновить вашу железку, должна решать вопрос с Safari? Или ставить другой браузер? Или делать джеил? Или переходить на андроид? Вы очень последовательны и логичны в рассуждениях.

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

[AlexandrY]

То есть начали с того, что пользователь не может IP поменять, а теперь домохозяйка, решившая обновить вашу железку, должна решать вопрос с Safari? Или ставить другой браузер? Или делать джеил? Или переходить на андроид? Вы очень последовательны и логичны в рассуждениях.

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

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

[Quasar]

Потому как если бы действительно существовало кроссплатформенные средство разработки я бы давно на нем программировал.

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

[AlexandrY]

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

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

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