Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: WinAVR-20080610
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
Страницы: 1, 2
haker_fox
Скачал. Установил.
Приятно удивил результат.
Проект скомпилированный на WinAVR-20070525 занимает 6452 байт. Работает. Проект скомпилированный новым компиляторм занимает 5396 байт. Полностью не работает. Детальный анализ пока не проводил. Серьезных багов не видел.
makefile используется один и тот же, только пути разные подставляются для вызова разных версий утилит.
Самое интересное, что при очистке проекта
Код
make clean
вылетает такая ошибка
Код
0 [main] rm 3292 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
111988 [main] rm 3292 open_stackdumpfile: Dumping stack trace to rm.exe.stackdump
make.exe: *** [clean] Error -1073741819

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

P.S.
Версия WinAVR-20071221 полет нормальный. Только очистка вылетает с такой же ошибкой.

Свои makefile прикрепляю на всякий случай. Они абсолютно одинаковы, за исключением путей к утилитам пакетов WinAVR.
733259
По сравнению с 3.4.6 по прежнему проигрывает.

ЗЫ Залил одну прошивку, все работает.
kurtis
Цитата(haker_fox @ Jun 24 2008, 06:57) *
.....
Самое интересное, что при очистке проекта
Код
make clean
вылетает такая ошибка
.....

У меня та же самая проблема, но только я поставил WinAVR-20071221, а до этого стоял(и продолжает стоять) WinAVR-20070525. Причем в том же месте где лежит makefile создается еще rm.exe.stackdump. Так что видимо проблема не в новом релизе
haker_fox
Цитата(733259 @ Jun 24 2008, 16:56) *
По сравнению с 3.4.6 по прежнему проигрывает.

ЗЫ Залил одну прошивку, все работает.

Хм. В чем же дело у меня? Видимо придется листинги смотреть, но времени пока нет. Проект хоть не горит, но делать надо...

Цитата(kurtis @ Jun 24 2008, 17:48) *
У меня та же самая проблема, но только я поставил WinAVR-20071221, а до этого стоял(и продолжает стоять) WinAVR-20070525. Причем в том же месте где лежит makefile создается еще rm.exe.stackdump. Так что видимо проблема не в новом релизе

Странно,что проблема не устраняется уже полгода. Может быть такая ошибка возникает, если стоят предыдущие версии? Но вроде не должно...
viakon
Цитата(haker_fox @ Jun 24 2008, 08:57) *
Полностью не работает.

Разобраться бы почему. У меня тоже проекты все на winavr-20070525 писаны, при переходе на новые версии начинаются глюки. Есть подозрение , что дело в оптимизации.
haker_fox
Цитата(viakon @ Jun 25 2008, 12:53) *
Разобраться бы почему. У меня тоже проекты все на winavr-20070525 писаны, при переходе на новые версии начинаются глюки. Есть подозрение , что дело в оптимизации.

А у Вас с какой версии проблемы начинаются? С 20071221?
А почему оптимизация?
733259
ИМХО это уже не раз обсуждалось, в четверке новые методы оптимизации, в том числе - "GCC can now do a form of partial dead code elimination (PDCE) that allows code motion of expressions to the paths where the result of the expression is actually needed. This is not always a win, so the pass has been limited to only consider profitable cases."
Выкидывает код, может где volatile не хватает, может глюки.

ИМХО на четверку для AVR вооще нет смысла переходить, прошивка всегда больше, скорость меньше.
Был бы рад узнать, что не так.
haker_fox
Цитата(733259 @ Jun 25 2008, 13:33) *
ИМХО это уже не раз обсуждалось, в четверке новые методы оптимизации, в том числе - "GCC can now do a form of partial dead code elimination (PDCE) that allows code motion of expressions to the paths where the result of the expression is actually needed. This is not always a win, so the pass has been limited to only consider profitable cases."
Выкидывает код, может где volatile не хватает, может глюки.

ИМХО на четверку для AVR вооще нет смысла переходить, прошивка всегда больше, скорость меньше.
Был бы рад узнать, что не так.

Сейчас проверил, что даже при отключенной оптимизации не работает код.
На данный момент стабильно работают версии WinAVR-20070525, WinAVR-20071221. Последняя генерит код байт на 300 меньше.
Программа, написанная мной, активно использует классы, наследование и т.д. Может быть это является камнем предкновения? Обычный Си код не проверял.
733259
Эти 20070525, 20071221 никакой инфы о компилере не несут, avr-gcc -v
haker_fox
Код
>c:\winAVR-20070525\bin\avr-gcc --version
avr-gcc (GCC) 4.1.2 (WinAVR 20070525)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


>c:\winAVR-20071221\bin\avr-gcc --version
avr-gcc (GCC) 4.2.2 (WinAVR 20071221)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


>c:\winAVR-20080610\bin\avr-gcc --version
avr-gcc (WinAVR 20080610) 4.3.0
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
viakon
А пользую только С никаких С++, так что дело вряд ли в этом. ставил я апрельскую версию этого года, один проект частично заработал когда на переменные volatile поставил, но полностью это не помогло. Склоняюсь, что дело в оптимизаторе, надо понять что ему не нравится. Разбираться некогда, вернул старую версию.
haker_fox
Цитата(733259 @ Jun 25 2008, 13:33) *
ИМХО это уже не раз обсуждалось, в четверке новые методы оптимизации

Прошу пролщения, а о какой четверке идет речь? Эти три версии все 4.x.x
Четверки во второй цифре версии вообще нет.
PS
Могу полностью выложить свой проект. Коммерческой тайны пока не представляет, но очень громоздок. Может быть это поможет улучшить компилятор или мои мозги)
Проект заточен для управления движком. Но его достаточно зашить в МК. При сбросе в UART на скорости 19200 выведется строка
Код
[Motor Controller "FREESTYLE-1", v. 0.01]

Еслит компилировать новой версией, то сразу при сбросе выводится вот прмерно такой мусор
Код
’¤2±Щ?a¤a?aА’¬;±a?aИaРaА"—ю”Г-A5NE?”
                                          
                                           ”C-
                                              ”‘‘y‘o‘_‘O‘?‘/‘ѕ•’’¶’$/”?”O”
_”o”””Ÿ”Ї”?”i”y”?”П”I·Ю·
a’a”¦П‘?‘y‘i‘?‘Ї‘Ÿ‘‘y‘o‘_‘O‘?‘/‘ѕ•’’¶’$/”?”O”_”o”””Ÿ”Ї”?”i”y”?”П”I·Ю·ˆ‘†
?ˆ”†ˆ‘‡?ˆ”‡ˆ‘?ˆ”
a’a”?П‘?‘y‘i‘?‘Ї‘Ÿ‘‘y‘o‘_‘O‘?‘/‘
aesok
Цитата(viakon @ Jun 25 2008, 09:29) *
А пользую только С никаких С++, так что дело вряд ли в этом. ставил я апрельскую версию этого года, один проект частично заработал когда на переменные volatile поставил, но полностью это не помогло. Склоняюсь, что дело в оптимизаторе, надо понять что ему не нравится. Разбираться некогда, вернул старую версию.


Все сборки WinAVR 2008 года (с avr-gcc 4.3) до майской могут не сохранять используемые регистры в обработчиках прерываний.

Анатолий.
viakon
интересно, и уменя проблемы c UART были. Работал c GPRS модемом и все команды ответы выводились на консоль. С новой версией при инициализации с какойто команды начинал валиться мусор. А часть проходила нормально.

Цитата(aesok @ Jun 25 2008, 10:41) *
Все сборки WinAVR 2008 года (с avr-gcc 4.3) до майской могут не сохранять используемые регистры в обработчиках прерываний.

Анатолий.

Читал про это. Пробовал я и майскую, тоже самое sad.gif
Недогадался попробовать оптимизацию выключить.
aesok
Цитата(viakon @ Jun 25 2008, 09:43) *
Читал про это. Пробовал я и майскую, тоже самое sad.gif


Пожалуйста покажие проблемный код.

Анатолий.
viakon
попробую выгрызть, но не на этой неделе точно.
haker_fox
Цитата(viakon @ Jun 25 2008, 14:43) *
интересно, и уменя проблемы c UART были. Работал c GPRS модемом и все команды ответы выводились на консоль. С новой версией при инициализации с какойто команды начинал валиться мусор. А часть проходила нормально.
Читал про это. Пробовал я и майскую, тоже самое sad.gif
Недогадался попробовать оптимизацию выключить.

C UART просто более наглядно наверное + прерывания используются. Если без них, то может проблем и не будет. Хотя кроме юартовских есть несколько других прерываний.
Вот еще что интересно, разительно отличаются секции data по размеру.
Код
20071221
   text       data        bss        dec        hex    filename
   6312          0        152       6464       1940    mcontrol.out

20080610
   text       data        bss        dec        hex    filename
   5918        452        152       6522       197a    mcontrol.out
733259
Цитата
Прошу пролщения, а о какой четверке идет речь? Эти три версии все 4.x.x
Четверки во второй цифре версии вообще нет.
Виноват, не слежу за 200xxxxx.
Обычно сравниваю с 3.4.6 и вижу только недостатки и сырость.
Речь конечно шла о первой цифре.
kurtis
Попробовал скомпилировать проект в сабжевой версии WinAVR, но использовал утилиты(rm, cp, mkdir и тд...) из версии 20070525. На железе проект запустился, размер кода возрос, а на ЖКИ вместо обычных букв - абракадабра и размер используемого ОЗУ возрос где-то на 1к При изменении уровня оптимизации абракадабра на ЖКИ меняется. Известно что железо полностью исправно и программа на 99% рабочая!!!В чем проблема незнаю, нету желания разбираться....
haker_fox
Видимо все-таки сыроват этот новый WinAVR...
У меня тоже пока нет желания разбираться, да и опыта анализа ассемблерных листингов нет(
viakon
Новый проект откомпилил на SUBJ работает. Только он на 100 байт больше оказался чем 20070525
solosh
Цитата(viakon @ Jun 27 2008, 11:29) *
Новый проект откомпилил на SUBJ работает. Только он на 100 байт больше оказался чем 20070525


Попробуйте ключик --param inline-call-cost, если вам важен размер. Например, "--param inline-call-cost=0"

см. http://electronix.ru/forum/index.php?s=&am...st&p=393595
haker_fox
Цитата(viakon @ Jun 27 2008, 17:29) *
Новый проект откомпилил на SUBJ работает. Только он на 100 байт больше оказался чем 20070525

А что изменилось по сравнению с Вашим старым проектом?
kurtis
Заметил что компилятор все символьные строки запихнул в ОЗУ, хотя они объявлены как prog_char, и из-за этого и фигня на ЖКИ влезла...в более ранних версиях GCC (4.2.2) такого небыло.
aesok
Цитата(kurtis @ Jun 28 2008, 22:50) *
Заметил что компилятор все символьные строки запихнул в ОЗУ, хотя они объявлены как prog_char, и из-за этого и фигня на ЖКИ влезла...в более ранних версиях GCC (4.2.2) такого небыло.


Тестовый пример пожалуйста приведите.

Анатолий.
Hmm
Когда-то, некоторое время, вел проекты параллельно в iar и winavr. Когда доверие к winavr утвердилось - остановился. После 20070527 обновляться перестал (некогда, работа однако). Выбрав свободный часок опробовал версию 2008 года (~май). Проект собрался без ошибок и предупреждений, но в изделии не заработал. Причем по железу все боле менее, а с матем. расчетами проблемы. Разбираться не стал (работа однако).
viakon
Цитата(kurtis @ Jun 28 2008, 23:50) *
Заметил что компилятор все символьные строки запихнул в ОЗУ

У меня все нормально, лежат во флеш.

Подпрограмма вызываемая 1 раз подставлена инлайн соответственно получилось 2 копии. Из-за этого и длина больше. попробую ключик
--param inline-call-cost
aesok
Цитата(viakon @ Jun 30 2008, 07:59) *
Подпрограмма вызываемая 1 раз подставлена инлайн соответственно получилось 2 копии. Из-за этого и длина больше. попробую ключик
--param inline-call-cost

Лучше объявите эту функцию как static.

Анатолий.
Сергей Борщ
Цитата(aesok @ Jun 30 2008, 12:21) *
Лучше объявите эту функцию как static.
или --ffunction-sections, -Wl,--gc-sections. Ведь часто исходник кочует из проекта в проект, в каком-то используются одни функции, в каком-то другие, или написали функцию, попользовали ее в другом файле, потом в процессе эволюции необходимость в функции пропала. Если линкер может выкинуть неиспользуемый код - пусть он это делает.
aesok
про --gc-sections где-то читал что могут быть проблеммы с отладкой. вечером поищю где про это написано.

Анатолий.
Сергей Борщ
Цитата(aesok @ Jun 30 2008, 12:35) *
про --gc-sections где-то читал что могут быть проблеммы с отладкой. вечером поищю где про это написано.
В некоторых версиях он выдавал warning "могут быть проблемы с отладкой на некоторых targets". Пока на такие проблемы не натыкался (внутрисхемной отладкой не пользуюсь), а уточнений - на каких именно targets и какие именно проблемы могут быть - не попадалось.
Chak
Здравствуйте уважаемые форумчане!

У меня проблемка нарисовалась с поддержкой ядер 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! help.gif
aesok
Цитата(Chak @ Jun 30 2008, 22:03) *
Help! help.gif


Хм... посылали Эрику патч для решения этой проблемы но почему-то он его не
добавил... Ждите следующую версию 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/.

Анатолий.
Chak
К Анатолию

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

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

А может есть способ заставить линкер собирать сначала библиотечные функциии (из libc.a libm.a libgcc.a) а потом остальные модули?
kurtis
Цитата(aesok @ Jun 28 2008, 21:55) *
Тестовый пример пожалуйста приведите.

Анатолий.


Есть строка вида (к примеру)
Код
const prog_char glob_menu_str[3][14]=
{
    "Строка 1",
    "Строка 2",
    "Строка 3",
};

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

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

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

Далее в коде используется strlen_P, strncpy_P, pgm_read_byte и тд, т.е. думается что мы работаем с переменными расположенными в секции кода...
З.Ы. При использовании GCC 4.2.2 (и более ранних) проект полностью рабочий!!!
aesok
Цитата(kurtis @ Jul 1 2008, 12:13) *
Есть строка вида (к примеру)
Код
const prog_char glob_menu_str[3][14]=
{
    "Строка 1",
    "Строка 2",
    "Строка 3",
};


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

Анатлий.
kurtis
Цитата(aesok @ Jul 1 2008, 11:53) *

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

Может я неправильно задал вопрос....Есть кусок кода
Код
const char MenuItem1[] PROGMEM = "Menu Item 1";
int main()
{
    unsigned int a;
    a = pgm_read_word(&MenuItem1[4]);
    mTest1  = a;
.............
return 0;
}

строку MenuItem1 GCC 4.2.2 ложит во flash, а GCC 4.3.0 ложит в ram!!! Как сделать, чтоб GCC 4.3.0 входящий в состав WinAVR-20080610, клал строку во flash (как это делала более ранняя версия)???
_Pasha
Цитата(kurtis @ Jul 1 2008, 12:42) *
строку MenuItem1 GCC 4.2.2 ложит во flash, а GCC 4.3.0 ложит в ram!!! Как сделать, чтоб GCC 4.3.0 входящий в состав WinAVR-20080610, клал строку во flash (как это делала более ранняя версия)???


Или Вы запутались или одно из двух. В приведенном коде у Вас фигурировало константное выражение. Ессно мона его расположить где удобнее оптимайзеру smile.gif
kurtis
Но если пойти по приведенной aesok ссылке, то там некий товарищь, именно таким вот методом
Код
const char MenuItem1[] PROGMEM = "Menu Item 1";
размещает константы не там где хочет оптимизатор, а там где нада!
У меня вызывает искреннее удивление, когда в новой версии компилятора, вдруг перестает работать код, который до этого работал много-много лет....Возможно я зациклился на том что код работал, и значит он корректен, и не вижу какой-то явной ошибки....
mdmitry
Цитата(kurtis @ Jul 1 2008, 16:59) *
Но если пойти по приведенной aesok ссылке, то там некий товарищь, именно таким вот методом
Код
const char MenuItem1[] PROGMEM = "Menu Item 1";
размещает константы не там где хочет оптимизатор, а там где нада!
У меня вызывает искреннее удивление, когда в новой версии компилятора, вдруг перестает работать код, который до этого работал много-много лет....Возможно я зациклился на том что код работал, и значит он корректен, и не вижу какой-то явной ошибки....

Полный код примера из описания avr-libc:
Код
#include <avr/pgmspace.h>

const char foo[] PROGMEM = "Foo";
const char bar[] PROGMEM = "Bar";

PGM_P array[2] PROGMEM = {
    foo,
    bar
};

int main (void)
{
    char buf[32];
    PGM_P p;
    int i;

    memcpy_P(&p, &array[i], sizeof(PGM_P));
    strcpy_P(buf, p);
    return 0;
}

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

aesok скорее всего указывал на массив строк
Код
PGM_P array
, а не на определения строк.
kurtis
Заменил все prog_char на char имя_строки[] PROGMEM и без изменения кода функций вывода, все вдруг чудесно заработало...
Собсно, а что случилось с prog_char в новых версиях???
почему выражения
Код
const   prog_char   Punkt1[]   =   {"Строка"};
и
Код
const   char   Punkt1[]   PROGMEM   =   {"Строка"};
не равносильны???
Вроде это одно и тоже....
aesok
Цитата(kurtis @ Jul 1 2008, 19:48) *
почему выражения
Код
const   prog_char   Punkt1[]   =   {"Строка"};
и
Код
const   char   Punkt1[]   PROGMEM   =   {"Строка"};
не равносильны???
Вроде это одно и тоже....


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

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

Для общего развития:
Цитата
Код
const Pointers

The keyword const for pointers can appear before the type, after the type, or in both places. The following are legal declarations:

const int * ptr1;       /* A pointer to a constant integer:
                             the value pointed to cannot be changed  */
int * const ptr2;       /* A constant pointer to integer:
                             the integer can be changed, but ptr2
                             cannot point to anything else           */
const int * const ptr3; /* A constant pointer to a constant integer:
                             neither the value pointed to
                             nor the pointer itself can be changed   */

Declaring an object to be const means that the this pointer is a pointer to a const object. A const this pointer can by used only with const member functions.


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

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

есть массив строк
Код
const char glob_menu_str[8][14] PROGMEM =
{
    "1.Строка1",
    "1.Строка1",
    ......
};


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

ну и собственно сам код этой функции
Код
void LCD_abc1(const char * [b]_str[/b], uint8_t _pos)
{
    uint8_t i = _pos;
    //size_t _strlen;
    uint8_t _strlen;
    uint8_t lcd_temp[32];
    _strlen=strlen_P([b]_str[/b]);
    
    if(_strlen>(32-_pos)) _strlen=32-_pos;

    strncpy_P((char*)(&lcd_temp),[b]_str[/b],_strlen+1);

    while(i<32)
    {
        if(lcd_temp[i-_pos]==0x00)
            break;
        LCD_str[i] = pgm_read_byte(&LCD_simb[lcd_temp[i-_pos]]);
        ++i;
    }
//LCD_str[i] - Временные массив, где хранится текущий "экран"
//LCD_simb - Таблица символов для ЖКИ
}

Вроде все красиво, все в железе работает, но компилятор ругается
Цитата
warning: only initialized variables can be placed into program memory area
на все строки описанные подобным образом
Код
const char glob_menu_str[8][14] PROGMEM =

Непонятно почему возникает такое предупреждение, скомпилировал код в более ранних версиях WinAVR - компилятор такого предупреждения не выдает...
haker_fox
Цитата(aesok @ Jul 2 2008, 02:07) *
Во втором указатель Punkt1 с атрибутом "progmem" ссылается на const char, то есть Punkt1 расположен в памяти программ, а константная строка в RAM.
Анатолий.

Как я понял, этот вариант работает в WinAVR2008....
Но ведь таким образом расходуется драгоценная RAM.
777777
Поставил сабж. Размер обоих проектов увеличился ровно на 32 байта каждый. Работоспособность не изменилась. Глупые строки вида
lds r24, 0x013A
lds r25, 0x013B
mov r18, r24
mov r19, r25
- остались. В чем отличие и кому нужны 32 байта - так и не понял.
aesok
Цитата(777777 @ Jul 18 2008, 11:02) *
Глупые строки вида
lds r24, 0x013A
lds r25, 0x013B
mov r18, r24
mov r19, r25
- остались.


Исходники компилятора находятся здесь: http://gcc.gnu.org/. Сделать компилятор менее глупым в ваших силах.

Цитата(777777 @ Jul 18 2008, 11:02) *
В чем отличие и кому нужны 32 байта - так и не понял.


На этом форуме было несколько рекомендаций как заставить avr-gcc 4.3 гененрировать более компактный код, поищите. (--param inline-call-cost, атрибут OS_main...)

Анатолий.
777777
Цитата(aesok @ Jul 18 2008, 14:53) *
Исходники компилятора находятся здесь: http://gcc.gnu.org/. Сделать компилятор менее глупым в ваших силах.

А поточнее можно ссылочку? Может и правда стоит попробовать... Когда-то давно с энтузиазмом дорабатывал компилятор Small-C для процессора 8080, он у меня стал полностью соответствовать стандарту, не понимал только элипсисы (...) Там даже оптимизатор был неслабый. Прада, он был pure-C...
Цитата(aesok @ Jul 18 2008, 14:53) *
На этом форуме было несколько рекомендаций как заставить avr-gcc 4.3 гененрировать более компактный код, поищите. (--param inline-call-cost, атрибут OS_main...)

param inline-call-cost есть, а OS_main - это что? Надо сказать, документация у WinAVR весьма неудачно сделана, все разбросано по каким-то закоулкам.
MrYuran
Цитата(777777 @ Jul 18 2008, 14:56) *
Надо сказать, документация у WinAVR весьма неудачно сделана, все разбросано по каким-то закоулкам.

А мне наоборот, очень понравилась, хотя бы тем, что она вообще есть
kaf
Цитата(MrYuran @ Jul 18 2008, 18:03) *
А мне наоборот, очень понравилась, хотя бы тем, что она вообще есть

c WinAvr идет документация по avr-libc, а остальную документацию нужно искать, как сказали выше, на http://gcc.gnu.org и на http://sources.redhat.com/binutils/
MrYuran
Ну уж не знаю, что тогда считать документацией...
Щас специально глянул - в папке WinAVR лежит папочка DOC (32 метра) - это чё - не документация?
Нажмите для просмотра прикрепленного файла
ну вы ребята зажрались...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.