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

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

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

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

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

[_pv]

я так понимаю основная проблема со статическим адресом, например 192.168.2.3, это то, что у пользователя может оказаться другая подсеть, например 10.0.0.0 или с нормальными адресами, соответственно при попытке обратиться к 192.168.2.3 пакеты будут отправлены не устройству, а в шлюз, который дальше их отправит хз куда.
но это вроде как лечится единственной командой route add без изменения каких-либо других настроек сети.

[zltigo]

но это вроде как лечится единственной командой route add без изменения каких-либо других настроек сети.

Отроутить, конечно, можно куда угодно и соответственно в желаемый интерфейс улетит. Но вот обратно уже ничего не дойдет.

[_pv]

Отроутить, конечно, можно куда угодно и соответственно в желаемый интерфейс улетит. Но вот обратно уже ничего не дойдет.

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

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

хотя конечно не особо это упрощает по сравнению с тем чтобы заставлять пользователей настройки сети менять.

[zltigo]

и роутить там собственно нечего - тупо отвечай туда откуда прилетело.

Только вот прилетит с IP, на который отправивший его не среагирует. Тупо НЕ его адрес. Вот такая печалька. Вот если-бы устройство могло ответить НЕ тупо, как Вы решили, а на реальный адрес отправившего, КАК НА РОУТЕР, тогда да. Но ведь адрес роутера, увы, у устройства другой - забитый от фонаря.

[_pv]

Только вот прилетит с IP, на который отправивший его не среагирует. Тупо НЕ его адрес. Вот такая печалька. Вот если-бы устройство могло ответить НЕ тупо, как Вы решили, а на реальный адрес отправившего, КАК НА РОУТЕР, тогда да. Но ведь адрес роутера, увы, у устройства другой - забитый от фонаря.

есть железка с зашитым адресом 192.168.2.3, которую воткнули в локальную сеть 172.16.
ПК, после route add ..., будет слать пакеты для 192.168.2.3 непосредстренно ему, а не в шлюз.
если устройство временно, на время начального конфигурирования, забъёт на маршрутизацию, и получив пакет от ПК 172.16.100.100 ему же обратно и ответит, с dst mac адресом ПК, а не шлюза, ПК разве этот ответ проигнорирует? ip - его, mac - его, то что src ip немного странный - так вроде без разницы, тем более в таблице маршрутизации он есть.

[zltigo]

есть железка с зашитым адресом 192.168.2.3, которую воткнули в локальную сеть 172.16.
ПК, после route add ..., будет слать пакеты для 192.168.2.3 непосредстренно ему, а не в шлюз.

Да. Для определенности - если указать роутинг подсети 192.168.2.xxx на IP адрес своего интерфейса (только надо его узнать предварительно ), то действительно будет просто улетать на этот интерфейс.

если устройство временно, на время начального конфигурирования, забъёт на маршрутизацию

А вот это уже дополнительное условие в Вами ранее озвученному . Да, забить на маршрутизацию можно и даже легко - маска 0.0.0.0 и весь мир у твоих ног . Тогда все будет работать, именно, как Вы описываете. Действительно самый минималистичный вариант вмешательства.
Остается только еще глянуть позволит-ли route поставить все, как хочется - в WIN постарше оно, помнится, капризное было

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

Ну вот, самое интерсное и полезное предложил похерить . На самом деле все остальное (из скольки букв в имени протокол выбрать, ставить-ли для этого "линукс" или обойтись портированием MQX ...)уже есть рутинные детали реализации. А вот как НЕ выполнять дурацкие действия, пусть даже их "все выпоняют", это действительно интересно.

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

А вот как НЕ выполнять дурацкие действия, пусть даже их "все выпоняют", это действительно интересно.

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

[_Pasha]

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

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

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

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

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