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

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