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

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

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

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

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

[Lotor]

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

Как вариант, писать на карту файл-лог.

[_pv]

ни разу не знаток html
но страничка с кнопкой добавить файл и отправка этого файла вроде как пару строчек всего.
https://www.cs.tut.fi/~jkorpela/forms/file.html
опять же для отображения прогресса на МК сделать отдельный файл который доступен через http и содержит текущий статус ругань если не получилось,
и отдать простенький яваскрипт который будет периодические в этот файл лазить и отображать в браузере прогресс бар тоже еще несколько строчек и без всяких наворотов с серверной (МК) стороны.

[AlexandrY]

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

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

Дивайс сразу должен работать по двум сценариям.
Либо он сервер DHCP и сообщает свое имя в поле sname и юзер после втыкания провода идет по известному статичному имени дивайса на его HTTP сервер
Либо дивайс сам принимает из сети свой IP адрес и по опции DHCP "Host Name Option" сообщает свое имя.

Пересылка файлов по HTTP это тысяча способов. Но придется подучить JavaScript и фреймворки не нем.

Но 48 К памяти очень мало. Надо хотя бы сотню.

[SSerge]

У ST есть пара примеров в обычном для них стиле:
LwIP TCP/IP stack demonstration for STM32F4x7 microcontrollers (AN3966)
STM32F4x7 in-application programming (IAP) over Ethernet based on LwIP TCP/IP stack (AN3968)

[Aner]

48 К памяти хватит, ... сделано, работает. Проблема неоговорённая: что будет если будет подвисание проца, сбой по сети, обрыв питания, и тп. во время абдейта. Откат назад должен быть гарантирован. DHCP да, порты тоже нужно будет выделять для доступа во внутреннюю сетку.

[zltigo]

Теперь чего хочу:

Самое минималистичное - в устройстве TFTP сервер - это буквально считанные байты над UDP.
https://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol
Клиенту вручить какой-нибудь готовый TFTP клиент или штатный активизировать. В 90-е годы массово использовал, может даже еще клиента самописного найду - там была добавлена специфичная надстройка через пару новых команд, но в остальном чистый TFTP.
Control Panel -> Programs and Features -> Turn Windows features On -> Client TFTP
Проще нереально, если ставить задачу не писать приложение для PC. Если писать, то тогда все можно сделать проще, в том числе, если в локальной сети, то пофиг IP адреса вместе с DHCP, HTTP и всем, что сейчас здесь насоветуют .

[AlexandrY]

48 К памяти хватит, ... сделано, работает. П

С DHCP сервером?

[zltigo]

Это самое экстремальное научить юзера IP адресам.

Незачем его учить - netsh и скрипты еще никто не отменял.

[AlexandrY]

Незачем его учить - netsh и скрипты еще никто не отменял.

netsh то чем поможет?
Исходим из того, что юзер не согласится менять сетевые настройки своего компа ради прошивки дивайса.
А то вам придется стать персональным администратором компа вашего юзера.

[zltigo]

Исходим из того, что юзер не согласится менять сетевые настройки своего компа ради прошивки дивайса.

Не спрашивать его чего-то делать и уж тем более не рассказывать ему о сетевых настройках и хочет-ли он их менять. Изменить и вернуть самостоятельно. Для этой операции скрипт прилагаемый в комплект к ПЕРВОНАЧАЛЬНО прошиваемому firmware.

[AlexandrY]

Не спрашивать его чего-то делать и уж тем более не рассказывать ему о сетевых настройках и хочет-ли он их менять. Изменить и вернуть самостоятельно. Для этой операции скрипт.

А как именно, телекинезом или телепатией?

[Aner]

Самое минималистичное - в устройстве TFTP сервер - это буквально считанные байты над UDP.
https://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol
Клиенту вручить какой-нибудь готовый TFTP клиент или штатный активизировать. В 90-е годы массово использовал, может даже еще клиента самописного найду - там была добавлена специфичная надстройка через пару новых команд, но в остальном чистый TFTP.
Control Panel -> Programs and Features -> Turn Windows features On -> Client TFTP
Проще нереально, если ставить задачу не писать приложение для PC. Если писать, то тогда все можно сделать проще, в том числе, если в локальной сети, то пофиг IP адреса вместе с DHCP, HTTP и всем, что сейчас здесь насоветуют .

TFTP без секюрнотости мало кому сегодня уже нужен, так поиграться только. Да и не локалка у него.

[zltigo]

TFTP без секюрнотости мало кому сегодня уже нужен, так поиграться только.

Ой! Какой ужас! Все, 100500 битные ключи еще сейчас начем обсуждать. Вы бы хоть подумали, зачем это нужно при загрузке firmware, если его целостность (и почти наверняка шифрование) по любому должна обеспечиваться средствами загрузчика.

Да и не локалка у него.

Причем тут к TFTP локалка, не локалка или кусок кабеля?
Да и вообще при ПЕРВОНАЧАЛЬНОЙ заливке устройства речь о НЕ локалке ВООБЩЕ идти не может.

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

не-не-не, не все так плохо. DHCP будет, но если у пользователя в сетке нет DHCP-сервера, то устройство сядет на статический адрес. И да, пользователь не совсем чайник, поменять один раз под чутким руководством IP-адрес компа и потом вернуть его взад сможет. А вот поднимать на устройстве DHCP-сервер желания нет.
_pv, спасибо большое, почитаю. Похоже это то, что мне нужно.
AlexandrY, у меня сейчас lwIP поднят на STM32F107, с DNS, DHCP, телнетом, USB (VCP), scmRTOS и кучей еще всего занимает 55 К. Думаю без всего лишнего в 48 уложусь. Ну в крайнем случае в 64.
zltigo, TFTP я когда-то смотрел, но это опять же нужна какая-то программа-клиент, чего не хочется совсем. Ваш пример поиска явно не для WinXP. А есть ли она в XP? А если у пользователя Мак? Вот к гадалке не ходи - если у пользователя Мак, то мне придется искать ему эту программу, самому разбираться с ее установкой на Мак, которого я в глаза не видел и делать все остальные действия вместо того, чтобы заниматься чем-то действительно полезным. Потому что "а у меня ничего не работает, помогите!".

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

Про DHCP и статический адрес - все попадавшиеся мне домашние роутеры при первом включении имеют статический адрес. Наверное есть какой-то глубокий смысл в том, что этот адрес именно статический. Хотя бы потому, что этот адрес точно известен.

[zltigo]

zltigo TFTP я когда-то смотрел, но это опять же нужна какая-то программа-клиент, чего не хочется совсем.

Главное, что она не самописная. И практически наверняка есть в операционке.

Ваш пример поиска явно не для WinXP. А есть ли она в XP?

Есть, ее просто ВООБЩЕ не надо искать и активизировать - TFTP в командной строке и все

А если у пользователя Мак? Вот к гадалке не ходи - если у пользователя Мак, то мне придется искать ему эту программу
чтобы заниматься чем-то действительно полезным.

http://www.macupdate.com/app/mac/12146/tftp-client
Ну тут уже только выбирать, что делать, либо рассказать, как воспользоваться клиентом на MAC, либо городить огород с серверами, браузерами и прочими немалым разнообразием и от этого:

Потому что "а у меня ничего не работает, помогите!".

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

[AlexandrY]

не-не-не, не все так плохо. DHCP будет, ноесли у пользователя в сетке нет DHCP-сервера, то устройство сядет на статический адрес. И да, пользователь не совсем чайник, поменять один раз под чутким руководством IP-адрес компа и потом вернуть его взад сможет. А вот поднимать на устройстве DHCP-сервер желания нет.


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

Простых решений не видно.
Допустим на компе юзера DHCP сервер.
Скажем юзер расшаривает по Ethernet свой беспроводной интернет.
Так просто попросить юзера установить статический адрес на компе не получится. Ему придется рушить мост. Кучу настроек, файрвол...
Вот будет радости.

[zltigo]

Про DHCP и статический адрес - все попадавшиеся мне домашние роутеры при первом включении имеют статический адрес. Наверное есть какой-то глубокий смысл в том, что этот адрес именно статический. Хотя бы потому, что этот адрес точно известен.

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

[AlexandrY]

По нынешним временам проще Wi-Fi использовать. Увидел юзер AP с нужным названием подключился к нему и голова не болит.

[zltigo]

Допустим на компе юзера DHCP сервер.
Скажем юзер расшаривает по Ethernet свой беспроводной интернет.
Так просто попросить юзера установить статический адрес на компе не получится. Ему придется рушить мост. Кучу настроек, файрвол...

Зачем, если есть DHCP, устанавливать статически-то???

Вот будет радости.

Ну а радость-то Сергею будет по любому - ну выдадут его устройству адрес, но он-то его НЕ узнает. И будет объяснять юзеру, как на неведомом роутере узнать адрес выданный им его устройству. Преред этим шоу померкнут любые объяснения, как воспользоваться какой-нибудь утилитой

[_pv]

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

[zltigo]

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

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

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

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

[zltigo]

Что-то вы тут все усложняете со своими IP адресами.

Что-то Вы решили категорически не ознакомиться с написанным

[_pv]

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

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

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

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

[zltigo]

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

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

[Quasar]

Что-то Вы решили категорически не ознакомиться с написанным

Нет, я со всем ознакомился и недоумеваю в связи с предложениями поднимать DHCP на железке или еще где-то (на хосте). Фиксированный IP возможен только в локальной сети, там, где как вы отметили выше, возможна работа вообще без IP. Можно использовать DHCP с полем file (или еще каким, указывающим адрес хоста с прошивкой), что бы при первом запуске железка качала ПО. Но я с трудом представляю себе ситуацию, когда первый запуск железки, происходит только с бутлоадером, без основной прошивки, соответственно без какой-то начальной или уже установленной пользователем сетевой конфигурации. Плюс, если железка стоит не в одной локальной сети с пользователем, то фокус с DHCP опять не получится и возвращаемся опять в начало, нафига нам IP со всеми этими страшными аббревиатурами?

1) Железка приходит к пользователю уже с какой-то прошивкой;
2) Он обнаруживает, что прошивка устарела (перед этим настроив железку, то есть вбив сетевую конфигурацию);
3) Начинает обновлять, соответственно при обновлении надо использовать ту конфигурацию, которую он установил в п. 2.

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

Поэтому мне не ясен вот такой посыл:

В предельном случае пользователь берет в руки устройство, в котором прошит только загрузчик,

Поэтому, я бы топикстартеру все-таки порекомендовал поглядеть в сторону утилиты обновления, которая ищет и обновляет железки в локальной сети (то есть железки с неизвестной сетевой конфигурацией) и обновляет железки где угодно с известной сетевой конфигурацией. В плане кроссплатформенности, не нравится Java, берите C++ с QT. Обновление через Web на 48КБ, сделать конечно можно, тем более если у вас есть SD карточка, но в этом случае автопоиск железки в сети невозможен, надо знать её IP.

[zltigo]

Поэтому, я бы топикстартеру все-таки порекомендовал...

Как Вы понимаете из написанного мною ранее, я описаный подход поддерживаю, если действительно делать оптимально-удобно для всех сторон.

[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 - будет-ли необходима защита, т.е. будет ли обновление производится через общедоступные сети или это будет локальная сеть.

[AlexandrY]

Поскольку программа обновления написана на Java, она полностью кроссплатформенная, запускается на Win, Lin и Mac.

Да ну!
И перекомпилировать на каждой из платформ не надо? Вот прям на любых дистрибутивах Линукса и Mac OS? И даже на iOS и Android наверно?
И без тестирования?

[Quasar]

Да ну!
И перекомпилировать на каждой из платформ не надо? Вот прям на любых дистрибутивах Линукса и Mac OS? И даже на iOS и Android наверно?
И без тестирования?

Ну вообще как бЭ да, перекомпилировать Java приложение не надо. Тестировать конечно надо, но при правильном дизайне, ведет себя приложение одинаково на всех платформах. Могут возникать некоторые вопросы по Linux'у, так как там частенько используют свободную JRE, а не JRE от Sun, а она глючноватая немного. Но это тоже решаемо, и в основном встречается на сложных приложениях. На простой обновлялке вы вряд ли столкнетесь с этим.

А вот если юзать QT с C++, то конечно, здесь нужна сборка под каждую платформу.

Да ну!
И даже на iOS и Android наверно?

На iOS нет Java, на Android Java не от Sun. Мы говорим про десктоп, Win, Lin, Mac. Я одинаково много работаю на всех этих платформах и могу сказать, что Java чрезвычайно кроссплатформена. На IOS вам с трудом удастся загрузить фаил прошивки через Web, так что здесь вариант обновления через Web тоже не покатит. А Android можно вообще выкинуть из рассмотрения, кому придет в голову обновлять железки с него (да и с IOS в общем-то тоже)?

[AlexandrY]

Но это тоже решаемо,... На простой обновлялке вы вряд ли ...

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

Короче не буду оригинальным, но напомню, что lwIP можно заменить на более продвинутое middleware на базе MQX.
В TCP стеке идущем с MQX есть и DHCP сервер и DHCP клиент.
В добавок к этому идет сервер Link-Local Multicast Name Resolution (LLMNR) , это чтобы юзеру не разбираться с IP адресами.
В довесок есть также FTP сервер (ну и клиент тоже есть).
Само собой есть и WEB сервер с авторизацией и даже протокол WebSocket
А вот и первый же пример загрузки файла по WebSocket - http://basic4ppc.com:51042/websocket_with_fileupload/

Проверил на Android. Работает.

[zltigo]

Короче не буду оригинальным...

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

[Quasar]

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

Не на паре, а на тройке, еще раз Win, Lin, Mac и проблем с обновлялкой не было. А неуверенность в голосе, потому что я про вас говорю (ну или про кого-то еще, кто будет реализовывать обсуждаемый мною подход) и соответственно уверенности в действиях этого человека у меня нет.

То есть:

На простой обновлялке вы вряд ли столкнетесь с этим.

Так что просьба не передергивать, я реализовав метод обновления с помощью Java обновлялки с проблемами не столкнулся, как получится у вас, не знаю :-)

[off]

А вот и первый же пример загрузки файла по WebSocket - http://basic4ppc.com:51042/websocket_with_fileupload/

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

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

У вас два несовместимых пункта. Новую прошивку придется сохранять где-то(в памяти, на 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-шифрование из предыдущих проектов.

[_pv]

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

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

[Aner]

... на Android Java не от Sun. ...

Сама приюлуда Android писана на той самой Java не от Sun, что поверх Linyx там у всех.

[AlexandrY]

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

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

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

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

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

[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 ...)уже есть рутинные детали реализации. А вот как НЕ выполнять дурацкие действия, пусть даже их "все выпоняют", это действительно интересно.

[Quasar]

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

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

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

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

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

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

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

[zltigo]

Кому как. Мне проще сделать "как у всех", чем искать или писать и поддерживать еще какую-то хитрую утилиту.

Ну в данном случае возникло решение, как упростить "инструкцию" и без утилит. Да и утилиты отметать не следует, ибо сейчас у тебя один домашний пользователь. А если будет какой-то обьект на котором тобой разработанных устройств разом смонтируют и включат сотню-другую?

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

Ну кому-то надо начинать делать ПЕРВОМУ не как у всех, тем более, что "все" в твоем примере цельнотянущие друг у друга роутеростоители бытовых роутеров.

[AlexandrY]

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

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

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

[HardEgor]

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

У меня роутер DIR-320, когда я в броузере на страничке настройки роутера нажимаю кнопку "перезагрузить", он на страничке выводит "ничего не делайте, через 99 секунд произойдет подключение", и счетчик секунд уменьшается до нуля. При нуле происходит автоматическое подключение броузера к странице настройки роутера. Как там это делается я не вникал, видимо в страничке есть код javascript, которые запрещает обновление страницы, отсчитывает 100 секунд, и принудительно обновляет страницу - броузер запрашивает соединение у стека tcp/ip, а стек подключается к http-серверу роутера.
Так что ваш сценарий реален.

[Quasar]

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

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

[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 для их свитчей есть какая-то там утилита и т.д,. Это всего лишь вопрос выбранного пути. "Как у всех" или "не как у всех", тут не причем.