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

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

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

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

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

[Quasar]

Что-то вы тут все усложняете со своими IP адресами. Железка до обновления на каком-то IP уже сидела? И, наверное, работала? Вот на нем пусть и обновляется. Первый запуск и первая прошивка она всегда с каким-то статическим заводским IP, и шьется на производстве специальным человеком. Задача как я понимаю обновить уже где-то работающую железку.
У меня все железки обновляются по ethernet'у. Там, где ресурсов мало, я использую загрузчик на uIP с TCP и http. http используется только как протокол передачи, а в качестве интерфейса обновления использовал самописную программу на Java. То есть, пользователь запускает программу обновления, вбивает в ней IP железки, которую хочет обновить и ждет секунд 30, прогресс бар в программе пишет сколько процентов загрузилось. Поскольку программа обновления написана на Java, она полностью кроссплатформенная, запускается на Win, Lin и Mac. Кто-то скажет, что у Java есть недостаток в виде java машины, но сейчас у многих производителей ПО Java популярна, и Java машина у многих пользователей уже есть, если же её нет, то не проблема её поставить в эпоху мегабитов и мегабайтов :-)
Второй вариант, который я использую, на жирных железках (с embedded linux), это использования Web морды, то есть, пользователь заходит на веб-морду, загружает через Web интерфейс прошивку, получив фаил прошивки, железка его расшифровывает, разархивирует, обновляет rootfs, обновляет ядро (если оно есть в прошивки), обновляет uboot (если оно есть в прошивки). При этом флеш разделена на две равные части, Раздел 1 и Раздел 2, если сейчас все ПО запущено с Раздела 1, то обновляется ПО на разделе 2 и наоборот. При перезагрузке, просто переключается загрузочный раздел со старого на вновь обновленный. Соответственно, если в процессе обновления произошел сбой, ничего не поломается, так как с текущим разделом никто, ничего не делал, железка как запускалась с него, так и будет это делать дальше.

Естественно, все прошивки я шифрую во избежание их модификации супостатами, но это уже другая тема :-)