[Rst7 5]

Есть еще одна маленькая тонкость - где лежит библиотека.

 

Разрабатывал я прибор, он в флеше программ хранил архив событий, соответственно код работы с архивом, прерываний, сидел в сегменте BOOT (который был определен в xcl). А библиотеку пришлось xlib'ом пришлось трахнуть: все функции перенести в сегмент LIBCODE (из CODE) и пристегнуть его к бутсектору (в xcl). Сегмент INTVEC - туда же, в бутсектор.

[NikolaKirov 0]

Пороботал над проблема и он оказался более сериознъи.

Значит боттлоадер сделаем. Ето не проблем.

Сделаем в другой проект. Там будем конфигурироват линкера с внешнии xcl файл.

И в примера от Атмел ето так. Потом запрограмируем процесор с проект боотлоадера и установим защиту на област боотлоадера.

 

Проблем получается потом. А в проекте где боотлоадер будем ползоват нада указат что верхная граница флаша ето начало боотлоадера. Иначе линкер может ползоват област боотлоадера и разположит там кое что. А для ето нада полности написат xcl фаил и конфигурироват линкер из него. Для маленкого проекта как боотлоадер не проблем сконфигурироват все из фаила. Но ето проблем при реалнъи проект. Я вручно так и не смог успешно конфигурироват мой проект.

 

Ест ли в IAR более простой метод сконфигурироват верхная граница флаш памяти?

[prottoss 0]

...Проблем получается потом. А в проекте где боотлоадер будем ползоват нада указат что верхная граница флаша ето начало боотлоадера. Иначе линкер может ползоват  област боотлоадера и разположит там кое что...

 

Проблема решается, что называется, в лоб:

 

перед функцией int main(void), в области, где, например, определяешь глобальные переменные пишем:

 

#define BOOT_LOADER_SIZE 0xFF // 256 байт, хотя можно сколь угодно

#pragma location = FLASHEND - BOOT_LOADER_SIZE

__root char __flash boot_loader_code[bOOT_LOADER_SIZE];

 

макрос FLASHEND определен в заголовочном модуле на примененный в проекте CPU. Например, в фйле для МК ATmega8515 - iom8515.h макрос FLASHEND имеет значение 0x1FFF

 

Естественно, перед прошивкой, массив boot_loader_code можно удалить. Однако, неоходимо проверять не увеличился ли код, после удаления массива. Размер сгенерированного кода можно увидеть, если в меню Tools->Options, на вкладке Messages в поле Show build messages установить пункт All

[NikolaKirov 0]

prottoss тъй показал мне хорошее решение. Оно навело меня на пут истиннъй.

 

Для тех кто тепер будут сталкиватся с етого опишу как сделат все.

 

Сначала делаем проект толко для боотлоадера. Пример из ATMEL достаточно нагляднъй.

 

Потом из hex фаил с помочи редактора записъиваем в бин файл област боотлоадера.

 

В проект в которъй нада боотлоадер поставит в опциях линкера добавляем

ето для АТмега16

 

-Z(CODE)BOOT=1C00-1FFF

--image_input=C:\boot.rnn,Bootloader,BOOT,2

-gBootloader

 

Первая опция создает сегмент BOOT , нада диапазон указат в соотсветствие с памяти соответного контролера.

Вторая опция load file C:\boot.rnn (ето бинарнъи фаил боотлоадера) в сегмент BOOT и присвоивает ему индентификатор Bootloader.

Третая опция разрешает линкера place Bootloader.

 

Ето и все.

[prottoss 0]

-Z(CODE)BOOT=1C00-1FFF

--image_input=C:\boot.rnn,Bootloader,BOOT,2

-gBootloader

 

Хм... Это получается, что все таки в проекте с основной программой будет компилится код бутлоадера?

[NikolaKirov 0]

Не будет компилироватся а поставляем в област боотфлаша готовъи машиннъи код.

Так является что в изходнъй файл проекта присуствует и боотлоадер и если област боотфлаша не защитена прописъивается и он. Мне кажется что етот вариант удобнъй.

[prottoss 0]

Не будет компилироватся а поставляем в област боотфлаша готовъи машиннъи код.

Так является что в изходнъй файл проекта присуствует и боотлоадер и если област боотфлаша  не защитена прописъивается и он. Мне кажется что етот вариант удобнъй.

<{POST_SNAPBACK}>

 

Может быть так и на самом деле удобней, на вкус и цвет товарищей нет

[ObitJr 0]

Сколько писал, но никогда не видел что линкер "случайно" положит "что-нить" в верхние адреса...

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

[NikolaKirov 0]

И как просто оформит bootloader как библиотеку? Включения боотлоадера в проект приводит к необходимости конфигурироват все опции проекта из xlc фаила а ето неудобно и сложно.

Я вообще не понимаю почему IAR не сделали работа с боотлоадера боолее удобной. И в документации вообще молчат по етой теме.

[prottoss 0]

И как просто оформит bootloader как библиотеку? Включения боотлоадера в проект приводит к необходимости  конфигурироват все опции проекта из xlc фаила а ето неудобно и сложно.

Я вообще не понимаю почему IAR не сделали работа с боотлоадера боолее удобной. И в документации вообще молчат по етой теме.

<{POST_SNAPBACK}>

 

Вам же еще в самом начале топика говорли, что вообще не зачем бутлоадер включать в проект. В этом ПРИНЦИПИАЛЬНО нет необходимости. Бутлоадер сидит в микросхеме. Вы пишете новый проект, или, что более естественно, обновляете старый. Компилируете его. Естественно у вас есть программа для РС, не ажно для какой операционной системы, которая знает как общатся с Вашим бутлоадером. Эта программа Ваш новый код передает бутлоадеру, который, в свою очередь, записывает этот код поверх старого, то есть обновляет действующее ПО микроконтроллера.

И, по моему даже незачем парится со вставкой разных массивов (что я предлагал выше) и кода бутлоадера. Сам себя бутлоадер преписать не сможет - его область защищена от записи. Вам же достаточно только произвести контроль объема кода, что легко выполняется в ИАРе.

Зачем создавать себе много проблем из пустого места.

А обновить бутлоадер можно имея под рукой любой доступный программатор АВРов, который скорее всего у Вас есть, раз Вы общаетесь в этом разделе форума.

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

Удачи.

[prottoss 0]

1