В некоторых версиях он выдавал warning "могут быть проблемы с отладкой на некоторых targets". Пока на такие проблемы не натыкался (внутрисхемной отладкой не пользуюсь), а уточнений - на каких именно targets и какие именно проблемы могут быть - не попадалось.

Здравствуйте уважаемые форумчане!

У меня проблемка нарисовалась с поддержкой ядер AVR с размером памяти 256к. При обращении к библиотечным функциям с переменным числом параметров (например fprint) компилятор встраивает вызовы к встроенным макросам пролог/эпилог (__prologue_saves__ / __epilogue_restores__ - если быть точным) из библиотеки libgcc.a. Беда в том, что данные для этих макросов, которые готовятся на этапе вызова функций, совершенно не учитывают размера памяти больше чем 128к (64к слов), то есть, инициализируются регистры Z (ZH,ZL), а в макросах используеться инструкция EIJMP, для полноценной работы которой надо еще установить регистр EIND.
Вот и получается, что если библиотечные функции с переменным числов параметров располагаються в адресах выше чем 128к, то вся програма перестает работать.

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

Может кто подскажет другой вариант?

Я перепробовал все версии WinAVR начиная с 20070122, привожу фрагменты листинга (при компиляции нету ни ошибок ни предупреждений):

Вот одна из библиотечных функций:

00020896 <fprintf_P>:

20896: a0 e0 ldi r26, 0x00 ; 0
20898: b0 e0 ldi r27, 0x00 ; 0
// здесь загружается адрес возврата
// из __prologue_saves__ - это должен быть
// адрес инструкции "ldd r16, Y+8" - 0х0208а2
// а у нас только 0х0451 х 2 = 0х08а2,
// а старшая часть адреса 0х02 нигде не фиксируется!!
2089a: e1 e5 ldi r30, 0x51 ; 81
2089c: f4 e0 ldi r31, 0x04 ; 4
2089e: 0d 94 d9 0c jmp 0x219b2 ; 0x219b2 <__prologue_saves__+0x1c>
208a2: 08 85 ldd r16, Y+8 ; 0x08
208a4: 19 85 ldd r17, Y+9 ; 0x09

а вот злополучная __prologue_saves__ :

00021996 <__prologue_saves__>:
21996: 2f 92 push r2
...
219b4: 1f 93 push r17
219b6: cf 93 push r28
219b8: df 93 push r29
219ba: cd b7 in r28, 0x3d ; 61
219bc: de b7 in r29, 0x3e ; 62
219be: ca 1b sub r28, r26
219c0: db 0b sbc r29, r27
219c2: 0f b6 in r0, 0x3f ; 63
219c4: f8 94 cli
219c6: de bf out 0x3e, r29 ; 62
219c8: 0f be out 0x3f, r0 ; 63
219ca: cd bf out 0x3d, r28 ; 61
219cc: 19 94 eijmp // естественно после этой инструкции мы "улетаем"
// по адресу 0х0008а2 (проверено в отладчике)!

Help!

Хм... посылали Эрику патч для решения этой проблемы но почему-то он его не
добавил... Ждите следующую версию WinAVR. А пока исключите из проекта функции
которые используют __prologue_saves__ / __epilogue_restores__ и выкинете
ключик -mcall-prologues если вы его использовали.

Можете еще поискать кого нибудь кто сможет вам собрать avr-libc внеся
изменения в файл avr-libc/devtools/gen-avr-lib-tree.sh:

-СFLAGS_SPACE="-mcall-prologues -Os"
+CFLAGS_SPACE="-Os"

Правда устанавливать avr-libc нужно будет ручками... хотя будет достаточно
заменить *.a файлы в директори /avr/lib/avr6/.

Анатолий.

Сообщение отредактировал aesok - Jun 30 2008, 19:06

К Анатолию

Спасибо за информацию о скором выходе нового WinAVR - буду ждать.

А пока выкручусь через "левое ухо" - выкинуть функции использующие пролог/эпилог я пока не готов - ведь им надо или писать или искать замену (слишком много дел), я скомпилировал проект в версии 20070122 с библиотеками libc версии 1.6.1 и ключом -Os. Получилось 128866 байт (в версии 20080610 - 143844). Таким образом проблема решилась - но проект постоянно растет и если патчи не будут учтены в новой версии WinAVR - беда!

А может есть способ заставить линкер собирать сначала библиотечные функциии (из libc.a libm.a libgcc.a) а потом остальные модули?

Сообщение отредактировал Chak - Jul 1 2008, 06:45

Есть строка вида (к примеру)

После компилирования получаю Project.elf
далее делаю avr.nm -n Project.elf > file.txt
и поиском ищу glob_menu_str....

в версии gcc 4.2.2 и более ранних получаю
т.е. если судить по символу t то оно легло в секцию с кодом

но когда я использую gcc 4.3.0 то получаю такую вот картину
оно легло во внешнее озу

Далее в коде используется strlen_P, strncpy_P, pgm_read_byte и тд, т.е. думается что мы работаем с переменными расположенными в секции кода...
З.Ы. При использовании GCC 4.2.2 (и более ранних) проект полностью рабочий!!!

Прочтите [TUT] [C] GCC and the PROGMEM Attribute , PART II - More advanced uses of PROGMEM.

Анатлий.

Простите, но я там не нашел ответа на свой вопрос, на что именно вы хотели мне указать???

Может я неправильно задал вопрос....Есть кусок кода

строку MenuItem1 GCC 4.2.2 ложит во flash, а GCC 4.3.0 ложит в ram!!! Как сделать, чтоб GCC 4.3.0 входящий в состав WinAVR-20080610, клал строку во flash (как это делала более ранняя версия)???

Или Вы запутались или одно из двух. В приведенном коде у Вас фигурировало константное выражение. Ессно мона его расположить где удобнее оптимайзеру

Но если пойти по приведенной aesok ссылке, то там некий товарищь, именно таким вот методом размещает константы не там где хочет оптимизатор, а там где нада!
У меня вызывает искреннее удивление, когда в новой версии компилятора, вдруг перестает работать код, который до этого работал много-много лет....Возможно я зациклился на том что код работал, и значит он корректен, и не вижу какой-то явной ошибки....

Полный код примера из описания avr-libc:

Это для WinAVR-20071221. Для новых версий не смотрел.

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

Заменил все prog_char на char имя_строки[] PROGMEM и без изменения кода функций вывода, все вдруг чудесно заработало...
Собсно, а что случилось с prog_char в новых версиях???
почему выражения
и
не равносильны???
Вроде это одно и тоже....

В первом случае указатель Punkt1 ссылается на const char с атрибутом "progmem", то есть на константную строку расположенную в памяти программ.

Во втором указатель Punkt1 с атрибутом "progmem" ссылается на const char, то есть Punkt1 расположен в памяти программ, а константная строка в RAM.

Для общего развития:


Анатолий.

Сообщение отредактировал aesok - Jul 1 2008, 17:08

Анатолий, спасибо за ответы, очень помогло!!!=)

Я пытаюсь разобраться, но все-равно есть некоторые вопросы...

есть массив строк


далее где-то в коде вызывается функция вывода на ЖКИ (на самом деле это функция копирования значения из памяти в массив данных, который затем уже будет куда-то выводится, не обязательно на ЖКИ)

ну и собственно сам код этой функции

Вроде все красиво, все в железе работает, но компилятор ругается
на все строки описанные подобным образом

Непонятно почему возникает такое предупреждение, скомпилировал код в более ранних версиях WinAVR - компилятор такого предупреждения не выдает...

Как я понял, этот вариант работает в WinAVR2008....
Но ведь таким образом расходуется драгоценная RAM.

Поставил сабж. Размер обоих проектов увеличился ровно на 32 байта каждый. Работоспособность не изменилась. Глупые строки вида
lds r24, 0x013A
lds r25, 0x013B
mov r18, r24
mov r19, r25
- остались. В чем отличие и кому нужны 32 байта - так и не понял.