Перейти к содержанию
    

обновление прошивки через эзернет-чо требуется.

Запускать обмен по ARP, устанавливать TCP-сессию и прочее-прочее - всё равно нужно.

То что "унутри железный" - это наоборот минус. Когда обнаружится баг в нём железном, то исправить Вы его уже не сможете. Поэтому такое "железное" лучше не использовать.

Ни ARP поддерживать, ни устанавливать TCP сессию на нем не надо. Все это реализует железка.

Для TCP cервера надо поднять серверный  сокет( прописать его MAC, IP и порт для прослушивания.И активировать парочку клиентских сокетов. Дальше или ручной опрос сокетов на наличие данных или включить прерывания.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 минуты назад, jcxz сказал:

Зачем?

Это увеличивает сложность загрузчика, соответственно (неминуемо) - уменьшает вероятность его безглючной работы. А баг в загрузчике - он много хуже чем баг в основном ПО.

Что бы кирпич оживить. См. смартфоны. В принципе я солгасен что эзернет в бутлоадере это жирно, но если из коробки устройства торчит только сетевой разъем выхода кмк нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Народ, вся прелесть этой железки что эзернет железный и ресурсов практически не жрет-только буфер

в ОЗУ для считывания принятого пакета из сокета.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 минуты назад, Kabdim сказал:

Что бы кирпич оживить. См. смартфоны. В принципе я солгасен что эзернет в бутлоадере это жирно, но если из коробки устройства торчит только сетевой разъем выхода кмк нет.

Кирпич оживляется элементарно подключением и прошивкой по JTAG или UART, так как заводской ROM-загрузчик никто не отменял.

Я это говорю не на пустом месте: у нас был печальный опыт: сделали баг в загрузчике, который проявился только гораздо позже, когда устройство находилось уже в серийном производстве: вышла новая ревизия микросхем SPI-флешь (в которые сохранялась прошивка) и если со старой ревизией баг не проявлялся, то в новой он проявился. Когда устройств было выпущено уже довольно много и они уже стояли на объектах заказчика. И это при том, что этот загрузчик был минимальным! Только переписывал прошивку из SPI-флешь во флешь программ.

А если загрузчик многократно сложнее - с приёмом и обработкой протокола обмена? Насколько вырастает вероятность бага?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 Arlleex - а зачем из основного приложения деинить контроллер и перешивать.

Установить признак во флэше и уйти на перезагрузку - а при старте смотреть кого стартовать-бутлоалер или

рабочее приложение?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 минуты назад, KRTPC сказал:

Народ, вся прелесть этой железки что эзернет железный и ресурсов практически не жрет-только буфер

в ОЗУ для считывания принятого пакета из сокета.

Когда наступите на грабли в этом железном эзернете, вот тогда в реале ощутите всю его "прелесть".   :-D

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вы производителям железа совсем не доверяете? В частности errate?

З.Ы. Встроенная собака в нем работает нормально. Да я и в AVR не жаловался...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

8 минут назад, KRTPC сказал:

Вы производителям железа совсем не доверяете? В частности errate?

З.Ы. Встроенная собака в нем работает нормально. Да я и в AVR не жаловался...

Ну а Вы сами посмотрите на errata - если там в железе уже столько багов, то сколько ещё не выявленных? И сколько ещё во встроенном ПО их? Вы разве не видели ПО (на компе) которое обновляется годами - баги исправляются и исправляются? Думаете что в Wiznete сидят идеальные программёры никогда не делающие багов?  ;))))

Не доверяю, так как за свою практику уже многократно наступал на них. И коллеги наступали. И вообще стараюсь придерживаться правила: "Если в составе устройства есть что-то, имеющее встроенное ПО, то это ПО должно быть обновляемо через стандартный интерфейс обновления прошивки устройства". Именно так мы в последнее время и делаем, и уже не раз удалённо обновляли прошивки в GSM-модулях, в PLC-модулях (покупных), которые стоят в наших устройствах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, KRTPC said:

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

Установить признак во флэше и уйти на перезагрузку - а при старте смотреть кого стартовать-бутлоалер или

рабочее приложение?

Из основного деинициализировать не нужно - зачем? А вот насчет перешивать... Ну вот как дать железке понять в процессе работы основного приложения, что ей пора бы паковать чемоданы обновиться? Естественно по этому же самому интерфейсу Ethernet послать команду - "Please, тут прошивочка есть новая, ее как бы надо бы прошить, типа...", для чего (с учетом вышеописанного механизма) по приему этой самой команды МК устанавливает флаг-признак "надо обновиться" и делает сброс. А при перезагрузке - штатная работа, описанная мною во втором посте (МК смотрит на флаг, видит, что надо обновиться, выходит в main() загрузчика и дальше работает протокол обновления прошивки). Естественно, что следует ответственно продумать логику перехода на основное приложение, ведь если основного приложения нет, кому передавать управление? Правильно, надо оставаться в загрузчике. Условий тут множество, на самом деле. У меня еще одним из условий является корректность доступа к EEPROM, в которой лежит флажок.

Но имея только лишь один интерфейс наружу, помимо всего прочего нужно продумать, как бы из основного приложения с запоротым механизмом перехода в загрузчик все-таки туда попасть. Можно после обновления, например, перейти в боевую прошивку, и ожидать там некоторое "время подтверждения связи", в течение которого пользователь со стороны ПК должен нажать кнопочку "ОК", по которой придет та же самая команда, как при "CONNECT". И только сейчас флажок-признак можно будет сбросить. Но тогда логику флажка в загрузчике поменять. В общем, вариантов много. Сейчас мне пока что некогда, но я доберусь еще до своего загрузчика и сделаю так, чтобы даже при запоротом приложении можно было перешиться, не вскрывая корпус девайса.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 minutes ago, Arlleex said:

У меня еще одним из условий является корректность доступа к EEPROM, в которой лежит флажок.

А смысл класть флажок в EEPROM, если RAM есть?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, aaarrr said:

А смысл класть флажок в EEPROM, если RAM есть?

Так а если в процессе перешивки (стирание, запись) питание отвалится, или еще какая непредвиденная штука - как узнаем, что прошилось все успешно?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 minute ago, Arlleex said:

Так а если в процессе перешивки (стирание, запись) питание отвалится, или еще какая непредвиденная штука - как узнаем, что прошилось все успешно?

Так CRC основной части ПО надо проверять перед передачей управления из загрузчика.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

13 минут назад, Arlleex сказал:

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

Достаточно держать бэкап предыдущей прошивки. И по некоторому условию делать откат.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, aaarrr said:

Так CRC основной части ПО надо проверять перед передачей управления из загрузчика.

Так и есть. Проверяется CRC32 и только если она совпадает - стираю флаг и сбрасываюсь (после сброса загрузчик уже передаст управление в основную программу). Это признак, что все прошилось корректно.

Если же разместить флаг в ОЗУ, то, например, происходит следующая последовательность действий:

1. Работает основное ПО. Пришла команда на обновление ПО. Установили флаг-признак "необходимо обновиться" и сделали сброс (или переход в загрузчик другим образом).

2. Загрузчик видит в ОЗУ установленный флаг, что нужно перейти в загрузчик - и переходит в него.

3. Работает протокол обмена, стерли Flash, начали записывать... Пропало питание.

4. Появилось питание, МК загружается, проверяет флажок - а там он сброшен, он же в ОЗУ был. Значит обновляться не надо. Значит штатная работа - переходим на основное приложение. Если, к тому же, сделать элементарную проверку, что там не мусор лежит (проверяем значение MSP и вектора сброса основного приложения на хоть какую-то корректность), то покажется, что все хорошо и передавать управление можно основному ПО. Но дописать то мы не успели (см. п. 3). Получили кирпич.

Но можно, конечно, в образе прошивки хранить CRC32 этой прошивки и при старте загрузчика сравнивать всю прошивку с CRC32 во Flash. И тогда можно делать флажок в ОЗУ. Но, как мне кажется, проверять CRC32 всей прошивки всегда в загрузчике - расточительство... Хотя имеет место быть. ИМХО.

 

Just now, jcxz said:

Достаточно держать бэкап предыдущей прошивки. И по некоторому условию делать откат.

Так и будет, скорее всего. SD карточка на борту есть, поэтому виден свет в конце тоннеля =)

Изменено пользователем Arlleex

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...