поиском пользовался, помогло мало.
я в тему бутлоадера ещё не въехал.
то есть как реализовать пока понятия не имею, и вопрос у меня пока ни в контретный строках кода,
а в алгоритме по которому это надо сделать.
в вэйвкоме памяти достаточно чтоб хранить прошивку для меги32, хотя можно и фрамку прикрутить.
сейчас они по и2с общаются но можно и на СПИ перевести.
вэйвком опрашивает мегу, та в свою очередь отдает массив 512 байт - это основная работа меги.
я думаю следить за валидностью прошивки и за целостностью мне нет необходимости,
хотя успешный результат программирования тоже интересен. (это проверить не сложно на вэйвкоме)
прошивать буду только по требованию (через СМС) и вот от сюда не знаю как делать дальше.
надо ли ресетить мегу, что куда подсовывать, куда писать, от куда читать.
гуглил на эту тему по делу мало вот нашел загрузчик через UART может получиться переделать под себя.
помогите советом. Рад буду любой помощи.

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

для справки вэйвком забирает прошивку по ФПТ через ГПРС и положит её куда надо будет.

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

Обычно алгоритм такой:
Прога в м32 состоит из 2 независимых частей: приложение и бут.
При запуске (ресете) запускается всегда бут. Он проверяет целостность приложения и если оно цело, то запускает его. Иначе ждёт загружаемого кода приложения.
При работе приложения нужно по какому-то алгоритму инициировать старт бута.
Бут работает по любому каналу (какой выбирете). Это может быть и I2C и SPI и RS485 и т.д. Есть понятие протокола, то есть как формируются пакеты, где команды указываются, как контрольная сумма считается, что делать если она неверна и т.д.

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

Возможно также прошивку хранить во внешней EEPROM. Например в I2C EEPROMе. То есть грузить туда, а при перестарте перезаливать во флэш. (Обычно это делается "на лету").

то есть проверяет целостность прямо у себя во флеши?

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

ну тут наверно стоит начинать изучать
http://www.gaw.ru/html.cgi/txt/doc/micros/...arh128/19_2.htm
http://www.gaw.ru/html.cgi/txt/app/micros/avr/AVR109.htm
я прав?

это будет

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

Спасибо модераторам, что убрали тему в самую задницу :>[
чайник в смысле создания микроконтроллерных систем с бутлоадером,
за плечами 4 серийных проекта, пусть небольшие но серийные, и сделаные мной!!!
аналоговая схемотехника, силовая преобразоват техника на ура.
вот с МК недавно, но не настолько чтоб задавать глупые вопросы.
ВЕРНИТЕ ВЕТКУ НА МЕСТО! судя по соседним темам,здесь мне уж точно не помогут .

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

Начну с того, что разработчик (в данном случае вы) волен сам выбирать решения. Их много. Любую задачу можно решить десятками способов. Я буду, для начала приводить общепринятые решения под фишкой "обычно".


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

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

1-ая ссылка совершенно не из той оперы. Это метод программирования контроллера с помощью внешнего контроллера.
2-ая - да. Это по теме. Можно ещё порекомендовать AVR231. Очень многие его брали за основу.
Если же говорить о протоколах, то лучше почитайте что-нибудь типа WakeUp. Простой, но дающий общую картину.

Можно и так.
Обычно так:
Передаём команду в приложение и по ней мега переходит на бут.
Передаём новый код приложения буту. Бут записывает.
по финишу бут контролирует и переходит назад на приложение. (новое)
Можно и так:
Передаём приложению новое приложение и мега складывает его в отдельную eeprom. Контролирует целостность.
По завершению передаём команду и переходим на бут. бут переносит приложение из eeprom во флэш. Перестартует.

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

Как раз по i2c это вполне возможно. Будет 2 мастера. Один записывает - второй читает. Только не одновременно, а попеременно.
С SPI придётся городить аппаратный мультиплексор выбора. В принципе не сложно. И ещё надо организовывать чтото типа признака занятости для каждого из процессоров. Тоже в принципе не сложно. Если это нужно конечно.

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


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

а алгоритм выбора откуда брать более свежую прошивку из своей флеши или из внешней - не претендует на звание "алгоритм года!"
и на этой стадии вопроса не является принципиальным

с уважением.

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

Обычно никто не ресетит мегу. Это лишнее. По команде (совтовой) проц сам переходит куда нужно. Например "rjmp 0" или путём зацикливания, при включенном WDT. Есть и куча других способов.

Почитайте всёже AVR231. Там всё по полочкам + шифрование AES.

Почему или? "rjmp 0" - это зацикливание :)

Да хомутнул. Имел ввиду "rjmp boot". Зацикливание типа "rjmp $".