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

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



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

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

Короче не буду оригинальным, но напомню, что 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. Работает.

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

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

То есть:

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

[off]

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

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

Сложность в разумных пределах меня не пугает. scmRTOS+lwIP+DHCP вчера заняли 33 К, нашел очень компактный HTTP-парсер, есть надежда уложиться в 48 К.

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

Разумеется, я же так ее и описал: строка текста, поле ввода имени файла и кнопка "обновить". _pv в третьем сообщении темы дал хорошую ссылку.

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

Это будет локальная сеть. Проект открытый, защита от чтения прошивки не нужна. Если в следующих проектах потребуется защита, добавлю AES-шифрование из предыдущих проектов.

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

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

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






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

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

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

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

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

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

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

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

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

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

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

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

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