[zltigo 1]

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

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

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

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

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

чтобы заниматься чем-то действительно полезным.

http://www.macupdate.com/app/mac/12146/tftp-client

Ну тут уже только выбирать, что делать, либо рассказать, как воспользоваться клиентом на MAC, либо городить огород с серверами, браузерами и прочими немалым разнообразием и от этого:

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

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

 

[AlexandrY 3]

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

 

 

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

 

 

Простых решений не видно.

Допустим на компе юзера DHCP сервер.

Скажем юзер расшаривает по Ethernet свой беспроводной интернет.

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

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

[zltigo 1]

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

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

 

[AlexandrY 3]

 

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

[zltigo 1]

Допустим на компе юзера DHCP сервер.

Скажем юзер расшаривает по Ethernet свой беспроводной интернет.

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

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

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

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

[_pv 69]

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

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

[zltigo 1]

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

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

 

 

[Quasar 20]

Что-то вы тут все усложняете со своими 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 1]

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

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

 

[_pv 69]

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

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

 

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

 

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

 

[zltigo 1]

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

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

 

[Quasar 20]

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

 

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

 

1) Железка приходит к пользователю уже с какой-то прошивкой;

2) Он обнаруживает, что прошивка устарела (перед этим настроив железку, то есть вбив сетевую конфигурацию);

3) Начинает обновлять, соответственно при обновлении надо использовать ту конфигурацию, которую он установил в п. 2.

 

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

 

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

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

 

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

[zltigo 1]

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

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

 

[HardEgor 76]

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 3]

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

 

Да ну!

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

И без тестирования?