Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: WinAVR-20100110
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
Страницы: 1, 2, 3
_Pasha
Цитата(Сергей Борщ @ Mar 17 2010, 03:25) *
До первой найденой ошибки или добавления еще одной функции в протокол.

Обойти можно - в #ifdef-ах исходника предусмотреть часть, которая просто копирует страницы флеша из одного места в другое, обновляя только биос.
А прямее путь кто-нить знает?
ReAl
Цитата(_Pasha @ Feb 12 2010, 19:49) *
Еще прикол. Кто нибудь знает, как избавиться от неправильного назначения регистровых пар?
...
Компилер немедленно взялся за ум и функция изрядно похудела, т.к. пошли в ход инструкции LDD/STD
cranky.gif Неужели эту фигню никогда не причешут?
А у KGP как с этим дела? (Нету времени попробовать...)
Тоже так и не попробовал, но наткнулся недавно на avrfreaks на линк сюда
https://www.mikrocontroller.net/topic/65923#530326
Костыль, конечно, но на всякий случай запасся.
ARV
а я вот не увидел в этой версии компилятора опции -relax... или я куда-то не туда смотрю?
Сергей Борщ
Цитата(ARV @ Mar 25 2010, 10:45) *
или я куда-то не туда смотрю?
Это опция линкера.
LDFLAGS += -Wl,-relax
ARV
во блин... странно... вчера вроде не получалось обнаружить эффект, а сегодня получилось... извините за беспокойство - я прошляпил...

P.S. что это опция линкера - я и был в курсе...
Клим
Возможно уже такой вопрос был, сходу не нашел.
WINAVR 20100110:
Код
000006a0 <.do_clear_bss_start>:
     6a0:    a2 3f           cpi    r26, 0xF2; 242
     6a2:    b1 07           cpc    r27, r17
     6a4:    e1 f7           brne    .-8      ; 0x69e <.do_clear_bss_loop>
     6a6:    0e 94 b3 03     call    0x766; 0x766 <main>
     6aa:    0c 94 0c 3d     jmp    0x7a18; 0x7a18 <_exit>

Ну и собственно:
Код
int main (void)
{
     766:    2f 92           push    r2
     768:    3f 92           push    r3
     76a:    4f 92           push    r4
     76c:    5f 92           push    r5
     76e:    6f 92           push    r6
     770:    7f 92           push    r7
     772:    8f 92           push    r8
     774:    9f 92           push    r9
     776:    af 92           push    r10
     778:    bf 92           push    r11
     77a:    cf 92           push    r12
     77c:    df 92           push    r13
     77e:    ef 92           push    r14
     780:    ff 92           push    r15
     782:    0f 93           push    r16
     784:    1f 93           push    r17
     786:    cf 93           push    r28
     788:    df 93           push    r29

Зачем call main и зачем так загаживать стек ?
В старых версиях, если не ошибаюсь, был rjmp main.
Каким образом можно это победить ?
SysRq
Цитата(Клим @ Aug 19 2010, 17:22) *
Каким образом можно это победить ?
Использовать атрибуты OS_main, OS_task? http://electronix.ru/forum/index.php?s=&am...st&p=441344
Клим
Цитата(SysRq @ Aug 19 2010, 16:46) *
Использовать атрибуты OS_main, OS_task? http://electronix.ru/forum/index.php?s=&am...st&p=441344

Спасибо, помогло. OS_main убирает ненужные заталкивания в стек, но call main все равно остается )
_Pasha
Цитата(Клим @ Aug 19 2010, 18:40) *
call main все равно остается )

Это уже из области стартапа. Поменяйте в стартапе rcall на rjmp
_Pasha
Кто-нибудь может объяснить феномен. -Os
CODE

#include <avr/io.h>
int main(void);
volatile uint32_t interf;
int main(void)
{
while(PINB & 4)
{
uint32_t data=0;
for(uint8_t msk=0;msk < 24; msk++)
{
PORTB |= 0x80;
if(PINB & 0x40) data |= 1;
data <<= 1;
PORTB &= 0x7F;
}
interf = data;
}
return 0;
}

Листинг правильный - его не привожу, т.к. все тривиально
Дальше, если это сделать в таком виде
CODE

#include <avr/io.h>
int main(void);
volatile uint32_t interf;
int main(void)
{
while(PINB & 4)
{
uint32_t data;
for(uint8_t msk=0,data=0;msk < 24; msk++)
{
PORTB |= 0x80;
if(PINB & 0x40) data |= 1;
data <<= 1;
PORTB &= 0x7F;
}
interf = data;
}
return 0;
}

Листинг - конец света. Выкинул, родимый, все на корню.
CODE

int main(void)
{
44: 0f c0 rjmp .+30 ; 0x64 <main+0x20>
while(PINB & 4)
46: 80 e0 ldi r24, 0x00 ; 0
{
uint32_t data;
for(uint8_t msk=0,data=0;msk < 24; msk++)
{
PORTB |= 0x80;
48: c7 9a sbi 0x18, 7 ; 24
if(PINB & 0x40) data |= 1;
4a: 96 b3 in r25, 0x16 ; 22
data <<= 1;
PORTB &= 0x7F;
4c: c7 98 cbi 0x18, 7 ; 24
int main(void)
{
while(PINB & 4)
{
uint32_t data;
for(uint8_t msk=0,data=0;msk < 24; msk++)
4e: 8f 5f subi r24, 0xFF ; 255
50: 88 31 cpi r24, 0x18 ; 24
52: d1 f7 brne .-12 ; 0x48 <main+0x4>
PORTB |= 0x80;
if(PINB & 0x40) data |= 1;
data <<= 1;
PORTB &= 0x7F;
}
interf = data;
54: 10 92 60 00 sts 0x0060, r1
58: 10 92 61 00 sts 0x0061, r1
5c: 10 92 62 00 sts 0x0062, r1
60: 10 92 63 00 sts 0x0063, r1
#include <avr/io.h>
int main(void);
volatile uint32_t interf;
int main(void)
{
while(PINB & 4)
64: b2 99 sbic 0x16, 2 ; 22
66: ef cf rjmp .-34 ; 0x46 <main+0x2>
PORTB &= 0x7F;
}
interf = data;
}
return 0;
}
68: 80 e0 ldi r24, 0x00 ; 0
6a: 90 e0 ldi r25, 0x00 ; 0
6c: 08 95 ret


Что же такого крамольного в for(uint8_t msk=0,data=0;msk < 24; msk++) ? cranky.gif
SysRq
Цитата(_Pasha @ Feb 8 2011, 10:48) *
Что же такого...
Глобальную за локальной не видать. А локальная не используется, вот и выкинул...
_Pasha
Цитата(SysRq @ Feb 8 2011, 12:37) *
Глобальную за локальной не видать. А локальная не используется, вот и выкинул...

Кого? Он жеж глобальную по отношению к циклу и выкинул.
AHTOXA
Цитата(_Pasha @ Feb 8 2011, 15:55) *
Кого? Он жеж глобальную по отношению к циклу и выкинул.

Если объявить
Код
int i=0, j=0;

, то тут понятно, что объявлено две переменные. А если сделать то же самое в инициализации цикла for:
Код
for (int i=0, j=0;...)

, то догадаться уже сложнее sm.gif
demiurg_spb
Цитата(SysRq @ Feb 8 2011, 12:37) *
Глобальную за локальной не видать. А локальная не используется, вот и выкинул...

Точняк!
И даже больше локальная переменная внутри тела цикла не 32-битная, а 8-ми.
Так вот всё будет однозначно:
Код
        uint32_t data;
        uint8_t msk;
        
        for (msk=0, data=0; msk<24; msk++)


Цитата(_Pasha @ Feb 8 2011, 13:55) *
Кого? Он жеж глобальную по отношению к циклу и выкинул.

А вас что, он не предупреждал:
Код
main.c:28: warning: 'data' may be used uninitialized in this function
_Pasha
Цитата(demiurg_spb @ Feb 8 2011, 14:13) *
А вас что, он не предупреждал:

В том и дело, что если инициализировать и в начале и в цикле, предупреждения не будет, но овнокод тот же.

Цитата(AHTOXA @ Feb 8 2011, 14:01) *
, то догадаться уже сложнее sm.gif

Вот! Компилер живет своей жизнью, и надо его попросить сделать правильный код. Может, денег хочет?
demiurg_spb
Да ладно! Он честно ругнулся - вы игнорировали.
Ход его рассуждений тоже понять можно, раз уж программисту неважна эта переменная (её значеие),
то я забью на неё и связанное с ней биг-болтsm.gif

Цитата(_Pasha @ Feb 8 2011, 14:19) *
В том и дело, что если инициализировать и в начале и в цикле, предупреждения не будет, но овнокод тот же.

В том и дело что в цикле Вы инитите уже другую локальную переменную с тем же именем.
По идее warning по отношению ко внешней относительно цикла переменной должен бы был остаться... Похоже на багу в этой версии avr-gcc 4.3.3.

Проверил на 4.4.3 - уже пофиксили - даёт warning.

Так-что не надо катить бочку на святое! :-)
_Pasha
Цитата(demiurg_spb @ Feb 8 2011, 14:32) *
тоже понять можно, раз уж программисту неважна эта переменная (её значеие),
то я забью на неё и связанное с ней биг-болтsm.gif

Дык низзя жеж понять - магическая запятая - и все пропало ©!!! Давайте тогда ваще все выкинем(б), даже если(!) есть обращения к volatile - и... короче,ето багофича, как ея правильно сформулировать?
demiurg_spb
что сказать, переходите на версию посвежее ...
повторюсь - на avr-gcc 4.4.3 всё пучком.
_Pasha
Цитата(demiurg_spb @ Feb 8 2011, 14:48) *
на avr-gcc 4.4.3 всё пучком.

Это клёновская?
demiurg_spb
Цитата(_Pasha @ Feb 8 2011, 14:50) *
Это клёновская?


Нет это атмеловская.
http://www.atmel.com/dyn/resources/prod_do...2.win32.x86.exe

К ней правда какой то древний binutils прикручен (не весь древний, что характерно).
Я собрал для себя из 2 - компилятор и avr-libc от avr-toolchain-installer а всё остально от WinAVR.

Клён уже скачет впереди планеты всей на gcc-4.6.0
AHTOXA
Цитата(_Pasha @ Feb 8 2011, 16:19) *
Вот! Компилер живет своей жизнью, и надо его попросить сделать правильный код. Может, денег хочет?

Дык, кто ж не хочет? sm.gif
На самом деле, я тоже не сообразил, что там новая локальная переменная образуетсяsm.gif Теперь бум знать.
demiurg_spb
Цитата(demiurg_spb @ Feb 8 2011, 14:57) *
..это атмеловская.
http://www.atmel.com/dyn/resources/prod_do...2.win32.x86.exe

К ней правда какой то древний binutils прикручен (не весь древний, что характерно).
Ошибся я с выводами в прошлый раз, это не binutils в тулчейне старый а coreutils.

Судя по всему, они используют этот раритет:
http://gnuwin32.sourceforge.net/packages/coreutils.htm

А есть гораздо (на 6 лет) свежее:
http://ftp.gnu.org/gnu/coreutils/
ARV
как заставить компилятор помещать в elf-файл полные пути к исходникам для отладки "по коду"? по умолчанию туда суются относительные пути от корня проекта и в итоге при определенном стечении обстоятельств отладчик "находит" не те исходники...
отладочная информация формата dwarf-2
SysRq
Спасите мудрым советом, ибо не знаю куда копать sad.gif

Несколько проектов собираются правильно и без ошибок с любым уровнем оптимизации (s, 0-3) на всех доступных мне компах (включая виртуальные; WinAVR везде одинаковый), но не собираются с оптимизацией по размеру (s) на основном рабочем ноуте, хотя раньше собирались (на нём и написаны были, собственно).

Makefile стандартный, созданный софтинкой MFile.

Ошибка:
Цитата
-------- begin --------
avr-gcc (WinAVR 20100110) 4.3.3
Copyright © 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.


Compiling C: main.c
avr-gcc -c -mmcu=atmega8535 -I. -gdwarf-2 -DF_CPU=7372800UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -ffunction-sections -Wa,-adhlns=./main.lst -std=gnu99 -MMD -MP -MF .dep/main.o.d main.c -o main.o
In file included from main.h:10:
c:/winavr/lib/gcc/../../avr/include/avr/interrupt.h:38:20: error: calling fdopen: No such file or directory
In file included from main.h:12:
c:/winavr/lib/gcc/../../avr/include/avr/pgmspace.h:82:20: error: calling fdopen: No such file or directory
In file included from main.h:13:
c:/winavr/lib/gcc/../../avr/include/avr/eeprom.h:38:20: error: calling fdopen: No such file or directory
make.exe: *** [main.o] Error 1

> Process Exit Code: 2
> Time Taken: 00:00

Куда копать, что и где могло поломаться? Переустановка WinAVR ничего не дала.
WinAVR действительно установлен в C:\WinAVR, пути к файлам правильные.
Сергей Борщ
QUOTE (SysRq @ Mar 31 2011, 12:31) *
WinAVR действительно установлен в C:\WinAVR, пути к файлам правильные.
Возможно на других компах установлена другая версия программ из тех, что лежат в WinAVR/utils и путь к этой другой версии прописан в path первым. Переименуйте эту папку, если компиляция будет продолжать проходить - ищите, откуда берутся эти утилиты и копируйте их на "больной" комп. Или наоборот - найдите, откуда эти утилиты берутся на "больном" и уберите этот путь из path.
SysRq
Цитата(Сергей Борщ @ Apr 1 2011, 13:03) *
...найдите, откуда эти утилиты берутся на "больном" и уберите этот путь из path.
Команда which %exename%.exe для всех *.exe из C:\WinAVR\utils\bin и C:\WinAVR\bin выдаёт эти же пути, т.е. ничего стороннего не запускается.
Файлы на больном и остальных компах идентичны.
--

Оно починилось. Но причину поломки так и не знаю sad.gif
Переустановка поверх не излечивала, а вот удалить\поставить излечило.

Смена системной даты могла повлиять? Выставлял год как-то аж до 1991 (так надо было), и мог в это время WinAVR использовать.
Даты доступа\создания\изменения файлов WinAVR не додумался проверить до удаления\установки sad.gif
halfdoom
Попросил заказчик использовать gcc-4.5.1 (тот, что из avr-toolchain-installer-3.3.1.1020-win32.win32.x86). На сабже размер кода для меги8 был 4338 байт, на новом 4872 байт. Спрашивается, откуда такая разница? Ответ - везде понемногу, причем раскладка по регистрам совершенно другая, поэтому точное сравнение невозможно. Для меги168 пока вообще не вмещается во флэш...
_Pasha
Цитата(halfdoom @ Aug 5 2012, 10:44) *
Попросил заказчик использовать gcc-4.5.1

А у меня из-под убунты
Код
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.5.3/lto-wrapper
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=i686-linux-gnu --host=i686-linux-gnu --target=avr
Thread model: single
gcc version 4.5.3 (GCC)

и под масдаем - сабж
Отличий при сборках вообще нету. Наверное, это не нормально. Попробую пересобрать с десяток проектов и сравнить.
Genadi Zawidowski
Цитата(halfdoom @ Aug 5 2012, 11:44) *
Попросил заказчик использовать gcc-4.5.1 (тот, что из avr-toolchain-installer-3.3.1.1020-win32.win32.x86). На сабже размер кода для меги8 был 4338 байт, на новом 4872 байт. Спрашивается, откуда такая разница? Ответ - везде понемногу, причем раскладка по регистрам совершенно другая, поэтому точное сравнение невозможно. Для меги168 пока вообще не вмещается во флэш...


У меня при компиляции avr-toolchain-installer-3.4.0.1146-win32.win32.x86.exe по сравнению с 1020 код подрос код заметно. В моём случае на 32 килобайтах около 300 байт.
Причём, сабжёвый компилятор проигрывает сильно 1020-й и 710-й сборкам.

Попробуйте выборочным запрещением инлайна функций поиграться, static у функций поставить где надо.
halfdoom
В общем, нашел основной источник роста: излишне "умный" компилятор позаменял везде, где смог дотянуться, обращения через указатели на lds/sts. На некоторых кусках, где используется конструкции вида p=pp;*p++=a; *p++=b; *p++=c;fn(p) получаем 3 sts'a и еще арифметику для pp+3. Переменных (в структурах) в этом проекте очень много, отсюда и заметный прирост в объеме.
_Pasha
Цитата
-mfaster-structs
With -mfaster-structs, the compiler assumes that structures should have 8 byte alignment. This enables the use of pairs of "ldd" and "std" instructions for copies in structure assignment, in place of twice as many "ld" and "st" pairs. However, the use of this changed alignment directly violates the SPARC ABI . Thus, it's intended only for use on targets where the developer acknowledges that their resulting code will not be directly in line with the rules of the ABI .

ГЦЦ погряз в маразме, в нек-рых аспектах касательно 8 битников. Спецом выдавливают, мсм
halfdoom
Цитата(_Pasha @ Aug 5 2012, 18:46) *
Спецом выдавливают, мсм

Уже не помню кто, писал, что проблемы с 8-битниками у gcc принципиальные и радикальных улучшений не предвидится, т.к. основные разработчики ориентируются на 32/64-битные системы.
_Pasha
Собсна из 8-битов одни АВРки sm.gif
SDCC чистой культурой ГЦЦ аж никак не назвать, но даже там, в далеких пампасах чуднОго вИденья компилятора,
умудряются, например, беречь как зеницу ока концепцию SW стэка для пиков.
В то время как оформление всех переменных как static - единственный ключ к сохранению производительности. Странно это всё...
Genadi Zawidowski
Цитата(halfdoom @ Aug 5 2012, 19:11) *
В общем, нашел основной источник роста: излишне "умный" компилятор позаменял везде, где смог дотянуться, обращения через указатели на lds/sts. На некоторых кусках, где используется конструкции вида p=pp;*p++=a; *p++=b; *p++=c;fn(p) получаем 3 sts'a и еще арифметику для pp+3. Переменных (в структурах) в этом проекте очень много, отсюда и заметный прирост в объеме.

Это ради скорости, вероятно? Если так - пусть живёт... Если нет - как отключить, не знаете?
demiurg_spb
Цитата(halfdoom @ Aug 5 2012, 20:26) *
Уже не помню кто, писал, что проблемы с 8-битниками у gcc принципиальные и радикальных улучшений не предвидится, т.к. основные разработчики ориентируются на 32/64-битные системы.
Отнюдь, avr-gcc 4.7.1 весьма и весьма неплох: -3 Кб на проекте размером 70Кб, при переходе на него с последнего WinAvr (avr-gcc 4.3.3).
И это ещё без LTO (косяки в avr-libc не позволяют его пока использовать), но ситуация уже очень скоро изменится к лучшему с выходом avr-libc-1.8.1.
ReAl
Цитата(demiurg_spb @ Aug 8 2012, 08:50) *
Отнюдь, avr-gcc 4.7.1 весьма и весьма неплох
Если бы ещё кто-то не поленился собирать-выкладывать свежие сборки под линукс...
А то мне как-то лень разбираться, а Keln тоже утратил интерес к AVR.
demiurg_spb
Ни чем не могу помочь... Разве только под win:
http://sourceforge.net/projects/mobileches...hots%20(Win32)/
halfdoom
Цитата(Genadi Zawidowski @ Aug 8 2012, 02:03) *
Это ради скорости, вероятно? Если так - пусть живёт... Если нет - как отключить, не знаете?

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

Цитата(demiurg_spb @ Aug 8 2012, 08:50) *
Отнюдь, avr-gcc 4.7.1 весьма и весьма неплох

Может быть, но вот изъятие поддержки типа "typedef int16_t PROGMEM prog_int16_t;" несколько расстраивает.
demiurg_spb
Цитата(halfdoom @ Aug 8 2012, 18:30) *
Может быть, но вот изъятие поддержки типа "typedef int16_t PROGMEM prog_int16_t;" несколько расстраивает.
Напрасно расстраиваетесь, если нужна совместимость со старыми дедовскими методами нужно объявить глобально или до включения pgmspace.h
Код
#define __PROG_TYPES_COMPAT__

Все эти PGMы уже больше не нужны ввиду наличия гораздо более удобного механизма с ключевым словом __flash.
Будут вопросы - спрашивайте, я самую малость причастен к avr-libc и в частности pgm_read_float в pgmspace.h накалякалsm.gif
ReAl
(сверните кто-нибудь строку в 78 сообщении, а то она в монитор 1600 по горизонтали не лезет, надо на 1920 попробовать)

Ещё руки не дошли пробовать, но если я правильно понял обсуждения, то __flash сейчас только в С-шном форнт-энде, в С++-ном его нет (пространства памяти в С-шном стандарте появились, а не в С++-ном).
Буду рад ошибиться.

Но typedef int16_t PROGMEM prog_int16_t по сути никогда и не работал. Т.е. тип при этом не создавался.
Я даже не говорю об обращении по адресу переменной типа prog_int16_t, но ведь даже контроля типов при передаче в функцию не было.
Так что такой typedef только сокращал писанину (её и #define-ом сократить можно), но ничем не отличался от
Код
int16_t  ip PROGMEM;
Genadi Zawidowski
Цитата(demiurg_spb @ Aug 9 2012, 09:10) *
... наличия гораздо более удобного механизма с ключевым словом __flash.


Отлично!

1) указатель на данные во flash, расположенный во flash?
2) указатель на данные в RAM, расположенный во flash?
3) указатель на данные во flash, расположенный в RAM?

Как выглядят описания?


ps: что-то применение этого ключевого слова приводит к классическому
../tc1.c:294:16: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'const'
demiurg_spb
думаю что где-то так
Код
#define flash const __flash
или
typedef const __flash flash;

1) flash void* flash
2) void* flash
3) flash void*


http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
+ гляньте доку на IAR, как это не странно звучит, но там вы найдёте ответы на все ваши 3 вопроса.

Цитата(Genadi Zawidowski @ Aug 9 2012, 11:53) *
ps: что-то применение этого ключевого слова приводит к классическому
../tc1.c:294:16: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'const'

CSTANDARD = -std=gnu99
Genadi Zawidowski
Цитата(demiurg_spb @ Aug 9 2012, 12:28) *
CSTANDARD = -std=gnu99


Стоит (ключик в командной строке компилятора, если я правильно понял намёк).

В какой версии avr gnu toolchain это (ключевое слово __flash) работает?

Цитата
найдёте ответы на все ваши 3 вопроса

То что это по применению похоже на квалификаторы, я догадался. Я не пойму, куда это поставить, чтобы работало. У меня не получается.
demiurg_spb
Цитата(Genadi Zawidowski @ Aug 9 2012, 12:39) *
Стоит (ключик в командной строке компилятора, если я правильно понял намёк).
хорошо
Цитата
В какой версии avr gnu toolchain это (ключевое слово __flash) работает?
начиная с 4.7.0, правда изначально его называли __pgm, поэтому для первых сборок 4.7.0 нужно ещё и это:
#define __flash __pgm
Genadi Zawidowski
Использую вот отсюда
http://electronix.ru/forum/index.php?showt...t&p=1082499
demiurg_spb
Цитата(Genadi Zawidowski @ Aug 9 2012, 13:04) *
Использую вот отсюда
http://electronix.ru/forum/index.php?showt...t&p=1082499

И я тоже:
Код
avr-gcc -v

Using built-in specs.
COLLECT_GCC=c:\gcc\avr-gcc\bin\avr-gcc.EXE
COLLECT_LTO_WRAPPER=c:/gcc/avr-gcc/bin/../libexec/gcc/avr/4.7.1/lto-wrapper.exe
Target: avr
Configured with: ../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr --prefix=/local/gnu/install/gcc-4.7-mingw32 --host=i386-mingw32 --build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared --with-dwarf2 : (reconfigured) ../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr --prefix=/local/gnu/install/gcc-4.7-mingw32 --host=i386-mingw32 --build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared --with-dwarf2
Thread model: single
gcc version 4.7.1 20120606 (prerelease) (GCC)

HINT: в этой сборке avr-size не пропатченый поэтому возмите его из последнего WinAVR или из атмеловской сборки.
Genadi Zawidowski
Это что-то!
На 32-х килобайтном проекте получил почти пять килобайт выигрыша по объёму FLASH - это здорово (-Os)!
Просто перекомпилировал.

Попробовал с квалификатором __flash поиграться - странно, присвоение указателей на объекты с различием в этом квалификаторе не вызывает даже предупреждения... грустно. На "ручном управлении" работает, но это получается весьма опасный текст...

Не удаётся заставить работать из-под AvrStudio 4.19, только запуская make в каталоге проекта.
upd: заставил, только отключив использование AVR TOOLCHAIN и выбрав make из yagarto tools
Лучше иметь установленным atmel gnu tools поновее - gcc plugin поновее полезен.
halfdoom
Цитата(demiurg_spb @ Aug 9 2012, 08:10) *
Напрасно расстраиваетесь, если нужна совместимость со старыми дедовскими методами нужно объявить глобально или до включения pgmspace.h

Да я не расстраиваюсь, наоборот, всячески приветствую появление __flash, учитывая то, что предлагая включить подобное расширение лет 8 назад, услышал много всякого в ответ.

А в режиме совместимости с первого раза не собралось, поэтому и "расстроился".
Genadi Zawidowski
Нашёл ещё одну сборку - уже с инсталлятором -
http://www.makehackvoid.com/node/578/release

Цитата
C:\Program Files\MHV AVR Tools\bin>avr-gcc -v
Using built-in specs.
COLLECT_GCC=C:\Program Files\MHV AVR Tools\bin\avr-gcc.EXE
COLLECT_LTO_WRAPPER=c:/program files/mhv avr tools/bin/../libexec/gcc/avr/4.7.1/lto-wrapper.exe
Target: avr
Configured with: ../gcc-4.7.1/configure --prefix=/c/mhvavrtools/mhvavrtools/mhvavrtools --host=i686-pc-mingw32 --target=avr --enable
-languages=c,c++ --with-dwarf2 -enable-win32-registry=MHV-AVR-Tools --enable-lto --with-gmp=/c/mhvavrtools/mhvavrtools/build/bin --with-mpfr=/c/mhvavrtools/mhvavrtools/build/bin --with-mpc=/c/mhvavrtools/mhvavrtools/build/bin --disable-libssp
Thread model: single
gcc version 4.7.1 (GCC)
demiurg_spb
Я её тоже находил, но и также находил инфу что с ней что-то не так, возможно уже пофиксили.
В ней binutils какой-то экспериментальный
Код
Binutils 2.22.52.20120702 (development snapshot)
и вот с ним что-то не совсем чисто.
Так что я бы её не советовал использовать в боевых условиях.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.