[Quasar 20]

Да ну!

И перекомпилировать на каждой из платформ не надо? Вот прям на любых дистрибутивах Линукса и 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 3]

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

 

А, появилась неуверенность в голосе.

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

 

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

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

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

[Quasar 20]

А, появилась неуверенность в голосе.

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

 

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

 

То есть:

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

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

 

[off]

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

 

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

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

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

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

есть железка с зашитым адресом 192.168.2.3, которую воткнули в локальную сеть 172.16.

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

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

 

[Aner 5]

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

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

[AlexandrY 3]

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

 

 

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

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

Ему больше не надо проблем.

Многим маршрутизаторы настраивает провайдер связи и с локалкой он же разруливает.

 

 

 

 

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

 

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

 

Невозможность аплодить произвольные файлы из мобильного Safari знает весь интернет.

Он же знает как это обойти.

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

[zltigo 1]

есть железка с зашитым адресом 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 20]

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

 

Невозможность аплодить произвольные файлы из мобильного Safari знает весь интернет.

Он же знает как это обойти.

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

 

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

 

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

 

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

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

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

 

[zltigo 1]

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

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

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

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

[AlexandrY 3]

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

 

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

 

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

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

[HardEgor 76]

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

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

Так что ваш сценарий реален.

[Quasar 20]

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

 

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