Лучший метод - отключить всю оптимизацию и изучить код, генерируемый указанными функциями.

уже сделал. оптимизация не мешает - функции специфические. В примере 309 наворочили с адресами и заносом данных в буфер. в сделаное ими не въехал и засомневался. Но уже разобрался

Получается менять код. Есть тонкости:
по аплекейшену 2 Б адреса разделяются так: биты 0-4 это адрес слова в буфере, а с 5 по 11 - номер страници. Реально диапазон в буфере 0-63, т.е 0-5 биты. и адреса страниц с 6 - 12 биты. Это способ адресации в IAR, как я понял.
Прогу еще не закончил - интерфейс доделываю и алгоритм записи. Но уже вижу проблемы с размером загрузщика - в 1 КБ не уложусь, а место свободного мало.
Вот думаю, - А что если из основной программы убрать функции связи дублированные в загрузщике? Вот объявил я в main функцию и указать ее размещение? Или надо в одном проекте делать? Или еще есть варианты?
Я понимаю что Си не даст компактный код всравнении с asm, но хочется доделать все в Си.

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

вот моя апликуха по написанию загрузчика по итогом этой ветки. Высказывайте критеку.

Молодец! Первая ласточка в FAQ.

"необходимо отредактировать файл lnkm8s.xcl" - лучше все же скопировать его в папку проекта и редактировать копию - а то потом остальные проекты (которые использовали lnkm8s.xcl) перестанут работать. Еще можно добавить в какой папке искать этот файл (\avr\config).

-H1895 -h(CODE)1C00-1C25 /*Fill unused interrupt vector's with RETI */
Не нужно. Правильно написанная программа не должна влетать в ненужные вектора, а эту память можно использовать под код (загрузчик обычно стремится занять всю отведенную память и еще чуть-чуть:-)

"Тогда файл будет браться из Workspace проекта" - из папки проекта (гдe лежит .ewp). В Workspace обычно куча проектов из разных папок.

#include "inavr.h"
#include "iom8.h"
#include "stdio.h"
#include "flash.h"
1) первые три файла надо указать в угловых скобках.
2) вместо #include "iom8.h" #include <ioavr.h> - тогда нужный ioxxx.h будет подставлятся автоматически исходя из настроек проекта и исчезнет warning35 при линковке многофайловых пректов.
3) flash.h - файл явно не из комплекта компилятора, поэтому надо упомянуть где его брать.
цикл я бы сделал иначе:


И по ошибкам: "критЕку", "возможностями среда IAR", "что адре байта"
Buf_Adres -> Buf_Address, NumbePageWrite -> NumberPageWrite
P.S. с pgmspace.h так и не разобрались?
У меня получилось такое: (для AVR231):

спасибо! коечто поправлю, что то добавлю.
По поводу основного цикла: выглядит изящней, но после оптимизации выгрышь от применения указателя и декремента быть не должно. Эксперементировал с кодом и оптимизацией и заметил такую вещь. Мой вариант легче читается для новичков. приведу 2 варианта. Кстати, unsigned int в разных компиляторах имеет разный размер, а unsigned short везде 2 байта.

Упустил из вида. Можете кратко сказать с чем его едят?
поткоректирую - будет скоро готов.

Проверил. При оптимизации по размеру разница есть - 32/44 байта: вы твоем str+Buf_Adres вычисляется дважды внутри цикла, хотя +3 встроено в команду LDD: LDD Z+3. При оптимизации по скорости разница больше - 32 / 46 байт, хотя суммирование вынесено за цикл. И все равно остается сравнение с 64 в конце цикла. А если str передавать как параметр, да еще перед функцией __x поставить - мой вариант получается еще лучше - 26 байт, а твой так и остается в районе 40. (я делал только цикл).
Выигрыш получился имеено за счет указателя и того, что в результате вычисления Buf_Address-=2 сам собой получается флаг Z который тут же можно использовать для проверки окончания.

Тогда для улучшения наглядности рекомендую такой вариант:
Новичков надо сразу приучать писать оптимально. Раз str больше не нужен, нет смысла его хранить неизменным. Пусть указывает на текущий байт. Тогда одной командой LD Rn, X+ сразу делаем и загрузку и передвигаем указатель. Кстати, в последнем варианте цикл получился 30 байт независимо от оптимизации.
На эту тему много копий поломали с dxp в личной переписке (каждый остался при своем). Я не нашел в имеюмщемся у меня стандарте (ISO/IEC 9899) описания размеров данных. На всех известных мне компиляторах unsigned short действительно 2 байта. Но мне больше нравится подход с использованием заголовочного файла stdint.h. Объявленые в нем типы uint8_t, uint16_t, int8_t и т.д. имеют один и тот же размер всегда и везде.
"Говорю одно, делаю третье, думаю второе". Имел в виду intrinsics.h. Можно указать, что функции работы с флешкой описаны в файле intrinsics.h, тогда код будет самодостаточен - не нужны левые flash.h. Пришли (в почту) файл flash.h, я посмотрю как его макросы заменить на функции из intrinsics.h.

над циклом подумаю. файл прикладываю здесь - не смог приатачить к письму.
с intrinsics.h не ковырялся т.к. был дан flash файл и на нем зациклился и эксперементировал.

Выкладываю подправленую версию. Сергей Борщ, если с intrinsics.h что то получилось - сообщите

Модератор или кто статьями занимается - может в статьи поместить. Глядишь часть вопросов отпадет у людей.

Если люди умеют пользоваться поиском по форуму и внимательно читают темы, то у них и так вопросы не возникнут.
Да и что, собственно, плохого в вопросах.
По поводу статьи - почему бы и нет. Но это наверное к админам.

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

Основная идея - разместить по определенному адресу "заглушку", которую МК будет сам перепрограммировать и передавать ей управление.

Так вот вопрос: Как разместить функцию по четко заданному адресу в RWWS?

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

В примере весь код размещается в NRWWS. Там нет функциций размещенных в RWWS.


Со значением все ясно, я говорю о функциях.

В EWAVR_CompilerReference.pdf ниписано:

Добавил в файл lnkm16s.xcl (у меня mega16, memory - small) строки:

Пишу:
В результате:
Fatal Error[e72]: Segment MY_LOADER must be defined in a segment definition option (-Z, -b or -P)

Пишу:

результат тот же.

Пишу в Options->Linker->Extra Options:

В результате:
Error[e102]: No such segment type: -Z(CODE}MY_SOURCE=100-200

Где-то какая-то мелочь, а какая - не пойму.

Все, разобрался. Дело было как обычно в мельницах.

Если в Options->Linker->Extra Options поставить правильные скобки то все работает без проблем.

тут столько всего написано...Про функции самопрограммирования мне понятно(ну или может почти)...
Никак не могу понять как и что нужно настроить в ИАРе, чтобы все заработало.Мне нужно работать с 4 страницами во флеше меги 8.Читать могу, а вот записать не получается

Ничего особенного вроде как в настройках писать не пришлось - тип процессора, модель памяти (Small), фрмат генерируемого файла.
Еще я прописывал Options->Linker->Extra Options:
но это что б размещать код по определенным адресам.

Для записи использовал пример из AVR109, файл fаlash.h и брал за основу функцию Update_Page(), написанную arttabом в bootloader_IAR.pdf.

Использовал IAR 4.11A, МК ATmega32.

Я уже могу писать, но почему-то только в конце загрузчика.Как сделать, так, чтобы выделить под запись 2 страницы перед областью загрузчика?

что имеется в виду под "концом загрузчика" и "перед областью загрузчика"?

sergik_vrn
Наверное под "концом загрузчика" имеется ввиду конец NRWW section, а под "перед областью загрузчика" - RWW section.

Len_OK
В NRWW section писать не было необходимости - поэтому сказать ничего не могу, а вот с записью в RWW section проблемм не возникало - несколько раз менял расположение модифицируемой части и все было в порядке. Разве что в начале производилась запись не совсем туда, куда нужно, из-за того, что напутал где адрес в байтах, а где в словах. Может Вы тоже наступили на эта грабли?

всё никак не получается
пишу Options->Linker->Extra Options:
-Z(CODE)main = 01C0-1B00
-Z(CODE)loader = 1C26-1FFF

а мне в ответ:

Error[e12]: Unable to open file '= 01C0-1B00'

Пробелы лишние (а лучше все) поубирайте.

извините конечно!!! Но что это за ошибка?Подскажите,PLZ!!!!

Error[e16]: Segment CODE (size: 0x40c align: 0x1) is too long for segment definition. At least 0x32 more
bytes needed. The problem occurred while processing the segment placement command
"-Z(CODE)CODE=1C26-1FFF", where at the moment of placement the available memory ranges were
"CODE:1c26-1fff"
Reserved ranges relevant to this placement:
CODE:1c26-1fff CODE

Вроде ясно написано - получившийся сегмент CODE не влезает в отведенное для него место. Не хватает 0x32 байт

спасибо, я уже разобралась.Невнимательна немного!

Пытаюсь использовать функции записи во флеш из апнота avr106 для своего проекта (Mega324P). Хочу сохранять параметры в неиспользованной части бутлодера (от начала сектора NRWW до начала собственно бутлодера). В верхней NRWW области прошит бутлодер размером 1кб. Область NRWW для данного мк занимает 4кБ. Бутлодер создан отдельным проектом. Сделал так как указано в апноте:

...т.е. в описании и объявлении функции записи во флеш добавил @"BOOT_SEGMENT"
unsigned char WriteFlashByte(MyAddressType flashAddr, unsigned char data)@"BOOT_SEGMENT";

При вызове этой функции возникает ошибка:

Что я сделал не так? Вообще-то, мне необходимо разместить функции так, чтобы не они не "попали" в самый верхний килобайт памяти (загрузчик).

Я думаю, ему не понравилось FARCODE. Поаробуйте просто CODE, у вашего кристалла всего 32К флеша, там никакой FAR не нужен.

Прошу прощения. Ошибка вышла. Скопировал с апнота... У меня было -Z(CODE)... Так в чем же дело?

EEPROM не используется? Точнее, не так: Если используется eeprom, то задаются ли ей в программе начальные значения? Если да, то оставьте на вкладке выбора формата отладочный формат для C-SPY, а на вкладке extra options допишите

Сразу возник вопрос: вы это пытаетесь добавлять в проект с бутлоадером или в проект с прикладной программой?
Я попробовал на проекте на мега128 с бутлоадером. При добавлении в прикладную программу след. строк все линкуется без ошибок.

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

А такую ошибку я тоже уже видел:

Но возникает она, если пытаться вывести в hex файл одновременно и CODE и DATA (или EEPROM).

Еще раз повторюсь. Есть многофайловый проект на Мега324 (без бутлодера). Бутлодер создан отдельным проектом. В контроллер уже прошит загрузчик в последний килобайт флеша. Хочу использовать функции из avr106 для записи во флеш. В частности в неиспользованную область NRWW (до начала загрузчика). В области NRWW необходимо разместить только функции записи во флеш. Я в курсе, что такое сообщение возникает при попытке скомпилить с данными в ЕЕПРОМе. И эти опции тоже использую, если надо. Но в тот момент ЕЕПРОМ не использовал. Это сообщение возникает при ВЫЗОВЕ WriteFlashByte(); Если не вызывать данную функцию, линкуется без ошибок.

Тогда приведите кусок вашего .xcl. Вы показываете какой-то другой .xcl, и хотите телепатии. В вашем .xcl в определнии сегмента BOOT_SEGMENT используется _..X_FLASH_END? Если да, чему оно у вас равно?

Не вижу криминала... Линкеру точно этот файл подсовывается? А поставьте формат выходного файла "Отладочный для C-SPY" и включите генерацию .map. В его шапке увидите командную строку линкера и в самом конце будет таблица распределения по сегментам - возможно, что-то прояснится.

Откровенно говоря у меня нет острой необходимости использование именно флеш в качестве ЕЕПРОМ. Да и времени нет для экспериментов. Решил просто использовать внутренний ЕЕПРОМ для данной разработки. По старинке Просто хотел освоить новый (для меня) способ записи. С первого раза не пошло... Если есть еще предположения, пишите.

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


Это просто наложение ошибок. На вызов функции такое сообщение выдаваться не может.

я поимел большие проблемы в установлении причины почему не получается самопрограммирование из-за неверных фузов размера загрузчика. проверьте на всякий случай

При чем в данном случае фузы? Речь идет об ошибке на этапе линковки программы.

To Baser
Не совсем понимаю для чего необходимо создавать хексы для DATA и EEPROM?

Обязательно ли все функции размещать в "BOOT_SEGMENT" ? По-моему, достаточно разместить только те функции, которые непосредственно работают с SPM инструкцией. Так? Или также и функции, в которые входят эти функции (SPM) ? И зачем объявлять их как extern? Без модификатора extern все компилится без ошибок. И последнее, для чего root?

Про это вам, вообщем-то, Сергей Борщ говорил и относилось это к возникающей у вас ошибке линкера, которая могла быть следствием попытки вывести в Intel-hex файл одновременно два адресных пространства: CODE и EEPROM. А для чего получать два файла с хексами для DATA и EEPROM - чтобы затем прошить их в МК


Да, конечно, можно размещать только функции с SPM. Но это только в том случае, если вы все эти функции компилируете и пишете в МК вместе (а не отдельно функции с SPM в проекте бутлоадера, а другие функции в прикладной программе), иначе вам необходимо обеспечить нахождение точек вызова функций по абсолютным адресам.


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


__root служит для указания линкеру, что данная функция или переменная должна быть безусловно включена в код, даже если она нигде не используется. Поскольку пример был тестовый, я везде добавил __root , чтобы линкер не своевольничал

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

Возникла такая проблема - не работает АЕS бутлоадер для ATmega64. Стал упрощать код, еще и еще, пока не дошел просто до пустой функции main(void) - он в функцию входит но из нее не выходит и висит - что это может быть?

Где-то ошибка. Попробуйте получившийса .hex пройти по шагам в симуляторе AVRStudio. Сразу увидите - куда код входит и куда выходит.

Эмм ошибка в пустой функции??? Кстати в АврСтудио все норм, как и должно быть а в железе чушь ((( Уже 5 ночей бьюсь ничего не помогает... Контроллер скажете вы, увы, пробовал на 3-х - один результат.
Я грешу на настройки компилятора или фьюзы. Может есть какой нить заковыйрестый фьюзик?
Вообще был бы благодарен если бы кто нить откомпили пустую функцию main в IAR 4 - тогда сразу бы нашел у себя ошибку.

А что там у вас с M103C ?

Анатолий.

Был запрограммирован (PonyProg), щас распрограммировали и... ЗАРАБОТАЛО!!! Ребята вы боги!!!

Breese
были приколы с "пустой функции main(void)". она была заоптимизирована. можно указать чтоб она не оптимизировалась или вставить в нее переход по метки, расположенной в main

вот и у меня пришло время писать boot loader, начитавшись и натренировавшись столкнулся с такой проблемой... бут лоадер грузит программу с адреса 000000 и вроде запускает, первые команды проходят а дальше тишина, такое впечатление что не работают прерывания, может кто сталкивался с подобным - помогите - сижу уже битый час и все никак..
(компилятор IAR проц ATMega1280)

Или вы переключили вектора на нулевые адреса, но забыли отключить какое-то из прерываний загрузчика. В результате оно стало попадать на пустой обработчик, а часть прерываний (TXE, UDR) не сбрасываются просто от самого факта входа в обработчик. Поставьте заглушки на все неиспользуемые вектора и дергайте в каждой заглушке своей ногой. Легко найдете, в каком прерывании вы зацикливаетесь. Если свободных ног мало, но есть осциллограф, можно наблюдать разные затычки на одной ноге так.

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

------------------------------------------------------------------------------------------
__disable_interrupt();
char temp;
temp = MCUCR; // Get MCUCR
MCUCR = temp|(1<<IVCE); // Enable change of Interrupt Vectors
MCUCR = temp|(1<<IVSEL); // Move interrupts to Boot Flash section
-------------------------------------------------------------------------------------------
__disable_interrupt();
temp = MCUCR; // Get MCUCR
MCUCR = temp|(1<<IVCE); // Enable change of Interrupt Vectors
MCUCR = temp&(0<<IVSEL); // Move interrupts to 0x00000 Flash section

То есть как это? Вы его переключали, а он сопротивлялся?

типа того,
ошибся немного, было так
MCUCR = temp|(0<<IVSEL); // Move interrupts to 0x00000 Flash section