Self-programming из application Опции

[_Артём_]

День добрый.

Такой вопрос: есть ли возможность перепрограммировать программную память в ходе работы программы.
Программу предполагается расположить по адресам от 0 и подпрограммы самопрограммирования в области бута.
При необходимости перешить программу будут вызываться соответствующие подпрограммы (page erase, page write и тп).
Будет ли такое работать?

[SAWushka]

Конечно будет, бут для того и нужен. Другой вопрос, что нужно как то следить за тем чтобы контекст не потерялся... если для вас это важно. И есть еще одни момент, опасный для вашего случая. Если в область бута вы попадаете только из основной программы.... и в момент перезаписи произошел сбой/ пропало питание и т.д. это может плохо кончится. А так, да из области бута вы сможете постранично перепрашивать флэш.

Сообщение отредактировал IgorKossak - Nov 2 2012, 18:04

Причина редактирования: ненужное цитирование

[_Артём_]

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

Что вы называете контекстом?

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

Попадаю также по старту.
Если программа сама себя переписывает, тогда опасно.

А так, да из области бута вы сможете постранично перепрашивать флэш.

Хорошо если так.

[SAWushka]

Что вы называете контекстом?

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

[_Артём_]

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

Нужное количество push-pop должны помочь...

Если вы можете себе позволить сбросить процессор после перезаписи - так проще. Пройдете инициализацию заново и вперед.

Думаю сбрасывать незачем.

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

внешняя еепром не предполагается.

Если что-то не так, откат обеспечен.

Стадию процесса надо ещё сохранять как-то.

[_Pasha]

внешняя еепром не предполагается.

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

Стадию процесса надо ещё сохранять как-то.

Это даже не обсуждается - и так понятно.

[_Артём_]

Такой момент ещё не ясен: позволяет ли система команд АВР получить possition independent код.
То есть можно ли расположить функции отвечающие за self-programming на странице номер N, скопировать этот код на страницу с заданным номером и вызывать функции записи с нового адреса?

Делал ли кто-нибудь такое?

[Xenia]

Такой момент ещё не ясен: позволяет ли система команд АВР получить possition independent код.
То есть можно ли расположить функции отвечающие за self-programming на странице номер N, скопировать этот код на страницу с заданным номером и вызывать функции записи с нового адреса?

Расположить код, отвечающий за self-programming, можно на любой странице, только проблема вся в том, что этот код работает только из области бута. Причина этого в том, сами команды, стирающие и записывающие страницы флэша, способны работать только, будучи расположенными в boot-области. Граница, за которой начинается boot-область, в каких-то пределах передвигается (например, посредством установки соответствующих фузов), тем не менее, эти команды способны работать только из boot-области. Поэтому все равно фунцию-загрузчик придется размещать в boot-области.

Наибольшая здесь проблема с таблицей прерываний, содержащией адреса, куда перескакивает управление, когда возникает соотвествующее прерывание. Замена прошивки меняет эти адреса вместе с таблицей прерываний. Однако "лабильность" таблицы прерываний зачастую не дает возможности загрузчику пользоваться прерываниями в процессе загруза, а эта возможность была бы желательна для связи загрузчика с "внешним миром". Ведь должен же он откуда-то принимать ту прошивку, которую загружает? Ясно, что в boot-области эта вся прошивка не поместится, а ОЗУ/SRAM у AVR-ок по объему заведомо меньше флеша, и потому тоже не может разместить в себе загружаемую прошивку целиком. Вот и получается, что загрузчик/прошивальщик вынужден будет вести внешний обмен, чтобы откуда-то извне читать эту прошивку по частям. Причем, любой сбой во время чтения способен сделать МК неработоспосбным, т.к. старая прошивка уже начала затираться новой (на младших страницах флеша), а для старших страниц информация еще не пришла.

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

Выход из этого положения можно поискать на путях создания второй таблицы прерываняи в области бута. Есть даже средства (аппаратные и программные) переключаться с одной таблицы на другую вместе с точкой запуска. Вот только реализовать этот механизм мне лично не удалось. Так и не смогла переключиться с нижней таблицы прерываний на верхнюю. Видимо не хватило усердия в этом разобраться.

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