Спасибо огромное! Получилось!
Смешал немного советы и получилось так.
Всё заработало!
Полная версия этой страницы: свежак KGP win32/arm/avr/mips/m68k
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26
свежак под масдай
ARM:
http://www.klen.org/Files/DevTools/kgp_arm_eabi_20100725.7z
AVR:
http://www.klen.org/Files/DevTools/kgp_avr_20100725.7z
MIPS:
http://www.klen.org/Files/DevTools/kgp_mips_elf_20100725.7z
MINGW32:
http://www.klen.org/Files/DevTools/kgp_mingw32_20100725.7z
чуть пожже положу сборку MINGW64, нада устранить несколько шероховатостей
ARM:
http://www.klen.org/Files/DevTools/kgp_arm_eabi_20100725.7z
AVR:
http://www.klen.org/Files/DevTools/kgp_avr_20100725.7z
MIPS:
http://www.klen.org/Files/DevTools/kgp_mips_elf_20100725.7z
MINGW32:
http://www.klen.org/Files/DevTools/kgp_mingw32_20100725.7z
чуть пожже положу сборку MINGW64, нада устранить несколько шероховатостей
Прошу помощи, очень нужен syscalls.c для kgp-mips-elf
Цитата(Konkere @ Jul 28 2010, 12:49) 
Прошу помощи, очень нужен syscalls.c для kgp-mips-elf
информации не достаточно.
вам что нужно - заглушки или реализации.
Цитата(klen @ Jul 27 2010, 20:29)
In file included from defaults.h:17:0,
from main.c:64:
c:\_gcc\bin\../lib/gcc/avr/4.6.0/../../../../avr/include/avr/boot.h:107:20: fatal error: limits.h: No such file or directory
Тоесть, ошибка с разбором пути вернулась взад и мешает компилить код с boot.h
Цитата(klen @ Jul 28 2010, 17:19)
информации не достаточно.
вам что нужно - заглушки или реализации.
вам что нужно - заглушки или реализации.
Компилятор выдаёт ошибку undefined reference по 7 функциям, я нашёл syscalls у codesourcery lite, но они используют переменные, которые неопределены в коде, а если эти переменные определить либо убрать, то появляется новая ошибка по тем же 7 функциям: multiply reference.
Опять в последней версии для АРМ какая-то ошибка. Проект не собирается.
d:/develop/winarm/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/bin/ld.exe: cannot find -lstdc++
d:/develop/winarm/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/bin/ld.exe: cannot find -lstdc++
[УДАЛЕНО]
Кросспост.
Кросспост.
Цитата(inco @ Jul 30 2010, 10:50)
Опять в последней версии для АРМ какая-то ошибка. Проект не собирается.
d:/develop/winarm/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/bin/ld.exe: cannot find -lstdc++
d:/develop/winarm/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/bin/ld.exe: cannot find -lstdc++
мдя. мой косяг. недоглядел - когда дистрибутив делал не все файлы... ;( , в следующей сборке починим.
это хорошо что Ыв косяки находите - сначала я все кроме редактирования кода делал ручками - конфигурация -сборка-пакетирование, постепенно автоматизирую систему сборки тулсов, в них тоже естб ошибки
... но мы их искореним
Цитата(klen @ Aug 2 2010, 18:46)
это хорошо что Ыв косяки находите - сначала я все кроме редактирования кода делал ручками - конфигурация -сборка-пакетирование, постепенно автоматизирую систему сборки тулсов, в них тоже естб ошибки ... но мы их искореним
... но мы их искоренимОбязательно.
Юзаю большей частью avr и x86.
Я проверяю собираемость моих текущих проектов в обязательном порядке. На изменения в объёме "+- немного" сильно внимания не обращаю. Но если надо для статистики, то могу записывать.
Скорострельности проекты не требуют, но реакция в пределах 1 мс обязана быть, так что если возникают грубые косяки со скоростью, будут замечены. Тестирую собранное в бою на нескольких десятках железок сразу, так что вот так )
свежак
для ARM
www.klen.org/Files/DevTools/kgp_arm_eabi_20100802.7z
с++ не проверял, нет под рукой проекта, проверьте чтоб не было так как с прошлой сборкой.
для AVR
www.klen.org/Files/DevTools/kgp_avr_20100802.7z
проблем с хидерами теперь быть не должно, была ошибка в системе сборки.
для ARM
www.klen.org/Files/DevTools/kgp_arm_eabi_20100802.7z
с++ не проверял, нет под рукой проекта, проверьте чтоб не было так как с прошлой сборкой.
для AVR
www.klen.org/Files/DevTools/kgp_avr_20100802.7z
проблем с хидерами теперь быть не должно, была ошибка в системе сборки.
Да, теперь вроде всё нормально! Проект для арма собирается. Спасибо!
Klen, не работает последняя версия сборки для AVR.
почему-то не может найти линкер:
откопал старую сборку (avr-gcc.exe (GCC) 4.4.0 20090323 (experimental)), запустил - работает!
Еще такой вопрос, нельзя ли чтоб в Ваших сборках avr-size умел выводить размеры полученного кода так же, как тот, что находится в WinAVR ?
почему-то не может найти линкер:
Код
..linking
avr-gcc -Os -Wl,-Map=Output/bin/main.map,--cref,--gc-sections -lm Output/obj/handlers.o Output/obj/main.o -o Output/bin/main.elf
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find &B: No such file or directory
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find 5B: No such file or directory
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find JB: No such file or directory
collect2: ld returned 1 exit status
make: *** [Output/bin/main.elf] Error 1
avr-gcc -Os -Wl,-Map=Output/bin/main.map,--cref,--gc-sections -lm Output/obj/handlers.o Output/obj/main.o -o Output/bin/main.elf
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find &B: No such file or directory
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find 5B: No such file or directory
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find JB: No such file or directory
collect2: ld returned 1 exit status
make: *** [Output/bin/main.elf] Error 1
откопал старую сборку (avr-gcc.exe (GCC) 4.4.0 20090323 (experimental)), запустил - работает!
Еще такой вопрос, нельзя ли чтоб в Ваших сборках avr-size умел выводить размеры полученного кода так же, как тот, что находится в WinAVR ?
Цитата(injen-d @ Aug 10 2010, 20:16)
Klen, не работает последняя версия сборки для AVR.
почему-то не может найти линкер:
откопал старую сборку (avr-gcc.exe (GCC) 4.4.0 20090323 (experimental)), запустил - работает!
Еще такой вопрос, нельзя ли чтоб в Ваших сборках avr-size умел выводить размеры полученного кода так же, как тот, что находится в WinAVR ?
почему-то не может найти линкер:
Код
..linking
avr-gcc -Os -Wl,-Map=Output/bin/main.map,--cref,--gc-sections -lm Output/obj/handlers.o Output/obj/main.o -o Output/bin/main.elf
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find &B: No such file or directory
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find 5B: No such file or directory
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find JB: No such file or directory
collect2: ld returned 1 exit status
make: *** [Output/bin/main.elf] Error 1
avr-gcc -Os -Wl,-Map=Output/bin/main.map,--cref,--gc-sections -lm Output/obj/handlers.o Output/obj/main.o -o Output/bin/main.elf
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find &B: No such file or directory
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find 5B: No such file or directory
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find JB: No such file or directory
collect2: ld returned 1 exit status
make: *** [Output/bin/main.elf] Error 1
откопал старую сборку (avr-gcc.exe (GCC) 4.4.0 20090323 (experimental)), запустил - работает!
Еще такой вопрос, нельзя ли чтоб в Ваших сборках avr-size умел выводить размеры полученного кода так же, как тот, что находится в WinAVR ?
кто не может найти линкер???....
еслиб это ктото ненаходил линкер, то он ( иметтся в виду линкер, внимательно смотрим вывод) бы вам не смог бы на писать что чегото найти не может.
чтото смотрю на опции линковки и кажется гдето параметрах -Wl есть косяг.
попробуйте для начала так собрать avr-gcc -lm Output/obj/handlers.o Output/obj/main.o -o Output/bin/main.elf
дайте проект, поробую посмотреть.
Цитата(klen @ Aug 11 2010, 01:33)
попробуйте для начала так собрать avr-gcc -lm Output/obj/handlers.o Output/obj/main.o -o Output/bin/main.elf
пробовал даже avr-gcc handlers.o main.o -o main.elf - результат тот же!
Опции линковки тут не причем.
Повторяю: WinAVR и ваши старые сборки работают без проблем.
А вот если вызывать линкер непосредственно:
avr-ld -Map=Output/bin/main.map --cref --gc-sections Output/obj/handlers.o Output/obj/main.o -o Output/bin/main.elf
то ошибок нет, но при этом не подключается автоматом стартовый код со всеми вытекающими.
я так думаю, что у avr-gcc не получается нормально вызвать ld.exe, который находится в \avr\bin
Цитата(injen-d @ Aug 11 2010, 17:24)
пробовал даже avr-gcc handlers.o main.o -o main.elf - результат тот же!
Опции линковки тут не причем.
Повторяю: WinAVR и ваши старые сборки работают без проблем.
А вот если вызывать линкер непосредственно:
avr-ld -Map=Output/bin/main.map --cref --gc-sections Output/obj/handlers.o Output/obj/main.o -o Output/bin/main.elf
то ошибок нет, но при этом не подключается автоматом стартовый код со всеми вытекающими.
я так думаю, что у avr-gcc не получается нормально вызвать ld.exe, который находится в \avr\bin
Опции линковки тут не причем.
Повторяю: WinAVR и ваши старые сборки работают без проблем.
А вот если вызывать линкер непосредственно:
avr-ld -Map=Output/bin/main.map --cref --gc-sections Output/obj/handlers.o Output/obj/main.o -o Output/bin/main.elf
то ошибок нет, но при этом не подключается автоматом стартовый код со всеми вытекающими.
я так думаю, что у avr-gcc не получается нормально вызвать ld.exe, который находится в \avr\bin
у меня как то ведь работает. еще раз повторяю - давайте проект, буду смотреть. лучше маленький кастрированный воспроизводящий ошибку
Выкладываю workspace (Eclipse-galileo-SR2) урезанный дальше некуда.
Вот все, что у меня выводится в консоль:
Нажмите для просмотра прикрепленного файла
Вот все, что у меня выводится в консоль:
Код
**** Build of configuration Default for project test ****
make all
avr-gcc.exe (Klen's GCC package (KGP) for AVR/elf platform) 4.6.0 20100802 (experimental)
Copyright (C) 2010 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
avr-gcc -c -Wall -mmcu=atmega8535 -gdwarf-2 -Os -fpack-struct -fshort-enums -I. -ffunction-sections -fdata-sections -Wundef -mshort-calls -MD -DF_CPU=7370000UL -Wa,-adhlns=Output/lst/main.lst -fno-exceptions -fno-rtti -x c++ main.cpp -o Output/obj/main.o
..linking
avr-gcc -Os -Wl,-Map=Output/bin/main.map,--cref,--gc-sections -lm Output/obj/main.o -o Output/bin/main.elf
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find &B: No such file or directory
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find 5B: No such file or directory
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find JB: No such file or directory
collect2: ld returned 1 exit status
make: *** [Output/bin/main.elf] Error 1
make all
avr-gcc.exe (Klen's GCC package (KGP) for AVR/elf platform) 4.6.0 20100802 (experimental)
Copyright (C) 2010 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
avr-gcc -c -Wall -mmcu=atmega8535 -gdwarf-2 -Os -fpack-struct -fshort-enums -I. -ffunction-sections -fdata-sections -Wundef -mshort-calls -MD -DF_CPU=7370000UL -Wa,-adhlns=Output/lst/main.lst -fno-exceptions -fno-rtti -x c++ main.cpp -o Output/obj/main.o
..linking
avr-gcc -Os -Wl,-Map=Output/bin/main.map,--cref,--gc-sections -lm Output/obj/main.o -o Output/bin/main.elf
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find &B: No such file or directory
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find 5B: No such file or directory
c:/kgp/avr/bin/../lib/gcc/avr/4.6.0/../../../../avr/bin/ld.exe: cannot find JB: No such file or directory
collect2: ld returned 1 exit status
make: *** [Output/bin/main.elf] Error 1
Нажмите для просмотра прикрепленного файла
вопрос снимается.
просто я забыл добавить -mmcu=atmega8535 в опции линкера.
теперь все работает.
Но на второй вопрос Вы не ответили: "нельзя ли чтоб в Ваших сборках avr-size умел выводить размеры полученного кода так же, как тот, что находится в WinAVR?"
просто я забыл добавить -mmcu=atmega8535 в опции линкера.
теперь все работает.
Но на второй вопрос Вы не ответили: "нельзя ли чтоб в Ваших сборках avr-size умел выводить размеры полученного кода так же, как тот, что находится в WinAVR?"
Цитата(injen-d @ Aug 11 2010, 20:13)
вопрос снимается.
просто я забыл добавить -mmcu=atmega8535 в опции линкера.
теперь все работает.
Но на второй вопрос Вы не ответили: "нельзя ли чтоб в Ваших сборках avr-size умел выводить размеры полученного кода так же, как тот, что находится в WinAVR?"
просто я забыл добавить -mmcu=atmega8535 в опции линкера.
теперь все работает.
Но на второй вопрос Вы не ответили: "нельзя ли чтоб в Ваших сборках avr-size умел выводить размеры полученного кода так же, как тот, что находится в WinAVR?"
это уже сделано в winAVR - берите оотуда эту утилитку.
на этот раз нечто новое.
свежак GCC для хоста - масдай x86_64, я проверил на Win7 64bit, на висте 64 не пробывал.
для arm
http://klen.org/Files/DevTools/kgp-arm-eab..._64_20100904.7z
для mingw64
http://klen.org/Files/DevTools/kgp-x86_86-...w32_20100904.7z
!!! эти пакеты скомпилены для x86_64, на 32 битных виндах работать не будут. последний нативно под этуже платформу генерит код
свежак GCC для хоста - масдай x86_64, я проверил на Win7 64bit, на висте 64 не пробывал.
для arm
http://klen.org/Files/DevTools/kgp-arm-eab..._64_20100904.7z
для mingw64
http://klen.org/Files/DevTools/kgp-x86_86-...w32_20100904.7z
!!! эти пакеты скомпилены для x86_64, на 32 битных виндах работать не будут. последний нативно под этуже платформу генерит код
Хочу сказать Спасибо klen-у.
Свежие сборки очень хороши.
И задать уважаемому all вопрос по ARM GCC C++
Может, кто нибудь знает, как бороться с malloc и new?
беда такая: достался мне в наследство проект под AT91SAM7A3, написан на С++ и использует new.
(IAR 4.30) ~30K flash.
Решил перевести его на лицензионный
GCC от Klen-а
Тестовая прожка:
#include <malloc.h>
class cll { int sss; };
cll* c1;
void* xxx = 0;
int main( void ) {
xxx = malloc( 8 ); *1
c1 = new cll; *2
}
чистый main (без *1 и *2):
text data bss dec hex filename
492 0 1368 1860 744 ./SKT7_REC.elf
всё нормально - стеки, кучи дают 1368 bss.
включаю malloc (*1):
text data bss dec hex filename
3292 2104 1424 6820 1aa4 ./SKT7_REC.elf
из непонятно откуда появилось 2104 байта data ??????, text терпимо
включаю new (*2):
text data bss dec hex filename
92716 2184 3756 98656 18160 ./SKT7_REC.elf
!!!!!!!!!! 90К текста, 2K data, +2K bss.
это при том, что IAR давал на полном проекте 30К text + 30К bss, где десятки new, FreeRTOS и др.
Посоветуйте пожалуйста, что с этим делать!!!
P.S. Конечно есть syscalls.c, и функция void * _sbrk_r(.
(оставльные функции пустые)
Свежие сборки очень хороши.
И задать уважаемому all вопрос по ARM GCC C++
Может, кто нибудь знает, как бороться с malloc и new?
беда такая: достался мне в наследство проект под AT91SAM7A3, написан на С++ и использует new.
(IAR 4.30) ~30K flash.
Решил перевести его на лицензионный
GCC от Klen-аТестовая прожка:
#include <malloc.h>
class cll { int sss; };
cll* c1;
void* xxx = 0;
int main( void ) {
xxx = malloc( 8 ); *1
c1 = new cll; *2
}
чистый main (без *1 и *2):
text data bss dec hex filename
492 0 1368 1860 744 ./SKT7_REC.elf
всё нормально - стеки, кучи дают 1368 bss.
включаю malloc (*1):
text data bss dec hex filename
3292 2104 1424 6820 1aa4 ./SKT7_REC.elf
из непонятно откуда появилось 2104 байта data ??????, text терпимо
включаю new (*2):
text data bss dec hex filename
92716 2184 3756 98656 18160 ./SKT7_REC.elf
!!!!!!!!!! 90К текста, 2K data, +2K bss.
это при том, что IAR давал на полном проекте 30К text + 30К bss, где десятки new, FreeRTOS и др.
Посоветуйте пожалуйста, что с этим делать!!!
P.S. Конечно есть syscalls.c, и функция void * _sbrk_r(.
(оставльные функции пустые)
Цитата(AlexeyVoroshen @ Sep 7 2010, 22:48)
включаю new (*2):
text data bss dec hex filename
92716 2184 3756 98656 18160 ./SKT7_REC.elf
!!!!!!!!!! 90К текста, 2K data, +2K bss.
text data bss dec hex filename
92716 2184 3756 98656 18160 ./SKT7_REC.elf
!!!!!!!!!! 90К текста, 2K data, +2K bss.
ошибочка вышла. 90K со старым yagartoo
c последним от клёна ~65K текста.
но всё равно, GCC тащит всё, что не надо (unwind, sprint....)
для сравнения IAR даёт на похожем примере ~1,5K + 1,5K
и где-же грабли закопаны????
Цитата(AlexeyVoroshen @ Sep 8 2010, 00:55)
ошибочка вышла. 90K со старым yagartoo
c последним от клёна ~65K текста.
но всё равно, GCC тащит всё, что не надо (unwind, sprint....)
для сравнения IAR даёт на похожем примере ~1,5K + 1,5K
и где-же грабли закопаны????
c последним от клёна ~65K текста.
но всё равно, GCC тащит всё, что не надо (unwind, sprint....)
для сравнения IAR даёт на похожем примере ~1,5K + 1,5K
и где-же грабли закопаны????
грабли тянутся из библиотечного маллока из newlib, нужно переопределить new delete со своим нормальным человеческим аллокатором. unwind я для армов убрал, не должно быть этого кода.
И не забыть про ключики
-fno-exceptions -fno-rtti
-fno-exceptions -fno-rtti
Цитата(AlexeyVoroshen @ Sep 8 2010, 00:48)
включаю malloc (*1):
text data bss dec hex filename
3292 2104 1424 6820 1aa4 ./SKT7_REC.elf
из непонятно откуда появилось 2104 байта data ??????
Попросите линкер сгенерить map-файл - там будет написано, что и почему прилинковано.text data bss dec hex filename
3292 2104 1424 6820 1aa4 ./SKT7_REC.elf
из непонятно откуда появилось 2104 байта data ??????
Цитата(AlexeyVoroshen @ Sep 8 2010, 01:55)
но всё равно, GCC тащит всё, что не надо (unwind, sprint....)
Тащит не GCC, а линкер. Линкер работает очень просто - он загружает секцию из библиотеки если имеются ссылки на определенные в ней символы. Ненужное он не тянет. Если Вы считаете, что какая-то из загруженных линкером секций не должна быть прилинкована, смотрите map-файл. Там будет написано, для разрешения какого символа была прилинкована эта секция, и где ссылка на этот символ встретилась. После этого разбирайтесь, почему там ссылаются на не нужный по вашему мнению код. В данном примере sprintf действительно линковаться не должен. Смотрите в map-файле, кто на него сослался.По unwind - почему считаете, что не надо? Вы используете оператор new, который может бросить исключение. Насколько я понимаю, unwind используется именно для обработки исключений.
Цитата(klen @ Sep 8 2010, 02:41)
грабли тянутся из библиотечного маллока из newlib, нужно переопределить new delete со своим нормальным человеческим аллокатором.
??? Чем плох newlib'овский аллокатор? Использую его много лет в куче разных проектов, с проблемами не сталкивался...
Цитата(alx2 @ Sep 8 2010, 10:19)
По unwind - почему считаете, что не надо? Вы используете оператор new, который может бросить исключение. Насколько я понимаю, unwind используется именно для обработки исключений.
??? Чем плох newlib'овский аллокатор? Использую его много лет в куче разных проектов, с проблемами не сталкивался...
??? Чем плох newlib'овский аллокатор? Использую его много лет в куче разных проектов, с проблемами не сталкивался...
у меня такая позиция
1. С++ исключения - это такая хрень которая в маленьких системках является архитектурным маразмом, код целевых алгоритмов будет обычно в разы меньше чем код эксепшенов. можно написать грамотно без эксепшенов сильнее напрягая моск. При мысли сколько чего происходит при вбросе эксешена волосы встают дыбом - это точчно не для маленьких систем
2. newlib-аллокатор на системке из 20к памяти? тоже самое - громоздко.
3. естественно инструмент по задаче нада мерить
AHTOXA:
И не забыть про ключики
-fno-exceptions -fno-rtti
если используются пользовательские библиотеки тоже должны быть собраны с этими ключами а то линкер до них unwind приятнет.
опции есть:
CPPFLAGS_LIST = -fno-exceptions -fno-rtti -Wa,-adhlns=$(OUTDIR)/$(<F:.cpp=.lst)
но из библиотеки тянется много всего:
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(new_op.o)
main.o (operator new(unsigned int))
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(eh_personality.o)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(new_op.o) (__gxx_personality_v0)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(eh_catch.o)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(eh_personality.o) (__cxa_begin_catch)
..........................
и даже unwind
...
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0\libgcc.a(unwind-arm.o)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(eh_personality.o) (__aeabi_unwind_cpp_pr0)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0\libgcc.a(libunwind.o)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0\libgcc.a(unwind-arm.o) (restore_core_regs)
...
и т.д.
версия: kgp_arm_eabi_20100802.7z
т.е. боюсь придётся свой new/delete делать
CPPFLAGS_LIST = -fno-exceptions -fno-rtti -Wa,-adhlns=$(OUTDIR)/$(<F:.cpp=.lst)
но из библиотеки тянется много всего:
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(new_op.o)
main.o (operator new(unsigned int))
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(eh_personality.o)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(new_op.o) (__gxx_personality_v0)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(eh_catch.o)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(eh_personality.o) (__cxa_begin_catch)
..........................
и даже unwind
...
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0\libgcc.a(unwind-arm.o)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0/../../../../arm-kgp-eabi/lib\libstdc++.a(eh_personality.o) (__aeabi_unwind_cpp_pr0)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0\libgcc.a(libunwind.o)
c:/programs/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.0\libgcc.a(unwind-arm.o) (restore_core_regs)
...
и т.д.
версия: kgp_arm_eabi_20100802.7z
т.е. боюсь придётся свой new/delete делать
Цитата(klen @ Sep 8 2010, 12:06)
1. С++ исключения - это такая хрень которая в маленьких системках является архитектурным маразмом,
2. newlib-аллокатор на системке из 20к памяти? тоже самое - громоздко.
Бесспорно. Но у Алексея система на ARM процессоре, и я поэтому предположил, что памяти в системе достаточное количество, чтобы не дрожать над каждым "лишним" килобайтом...2. newlib-аллокатор на системке из 20к памяти? тоже самое - громоздко.
Цитата(AHTOXA @ Sep 8 2010, 13:20)
И да, перепишите new/delete, примерно как здесь.
В обрамлении вызова malloc() мутексом нет смысла, так как newlib'овский malloc() уже имеет все это внутри. Главное не забыть реализовать __malloc_lock() и __malloc_unlock(), как это и написано в документации. Если нужен всего лишь оператор new, не бросающий исключений, достаточно этого: void * operator new(size_t n) throw() { return malloc(n); }
А что, вызов стандартного оператора new без исключений (new(std::nothrow) cll) не помогает?
Цитата(alx2 @ Sep 9 2010, 11:55)
В обрамлении вызова malloc() мутексом нет смысла, так как newlib'овский malloc() уже имеет все это внутри. Главное не забыть реализовать __malloc_lock() и __malloc_unlock(), как это и написано в документации.
Это решение получается мало того, что компиляторозависимым, так ещё и зависимым от реализации malloc(). А в случае явного прописывания мутекса - универсальным. Я, например, использую с этим кодом bget.
Цитата
Если нужен всего лишь оператор new, не бросающий исключений, достаточно этого:
void * operator new(size_t n) throw() { return malloc(n); }
void * operator new(size_t n) throw() { return malloc(n); }
Если устраивает стандартный malloc(), то да.
Цитата
А что, вызов стандартного оператора new без исключений (new(std::nothrow) cll) не помогает?
Так неудобно же!
Спасибо за помощь.
Буду использовать
>> void * operator new(size_t n) throw() { return malloc(n); }
(расширю под FreeRTOS).
или bget
а (new(std::nothrow) cll) у меня никоим образом не скомпилировался, как бы я не переписывал.
P.S. У меня часто бывают мелкие с-мы, поэтому вопрос и важен.
Буду использовать
>> void * operator new(size_t n) throw() { return malloc(n); }
(расширю под FreeRTOS).
или bget
а (new(std::nothrow) cll) у меня никоим образом не скомпилировался, как бы я не переписывал.
P.S. У меня часто бывают мелкие с-мы, поэтому вопрос и важен.
Уважаемый Klen, ответьте пожалуйста на вопрос по поводу сборки kgp_arm_eabi_20100802:
Ваша сборка использует libstdc++-6.dll с размером 712718байт.
эта версия конфликтует с DLL от Qt (4.6.x) с размером 812032байта.
Я нашёл 1 решение: перенести libstdc++-6.dll с размером 712718байт в каталог
kgp_arm_eabi\libexec\gcc\arm-kgp-eabi\4.6.0\
всё заработало (и kgp_arm_eabi_20100802 и Qt).
Правильно ли я сделал? необходимо ли использовать DLL в Ваших сборках или вы можете собирать сборки без DLL?
Заранее Спасибо.
Ваша сборка использует libstdc++-6.dll с размером 712718байт.
эта версия конфликтует с DLL от Qt (4.6.x) с размером 812032байта.
Я нашёл 1 решение: перенести libstdc++-6.dll с размером 712718байт в каталог
kgp_arm_eabi\libexec\gcc\arm-kgp-eabi\4.6.0\
всё заработало (и kgp_arm_eabi_20100802 и Qt).
Правильно ли я сделал? необходимо ли использовать DLL в Ваших сборках или вы можете собирать сборки без DLL?
Заранее Спасибо.
Цитата(AlexeyVoroshen @ Sep 20 2010, 20:27)
Уважаемый Klen, ответьте пожалуйста на вопрос по поводу сборки kgp_arm_eabi_20100802:
Ваша сборка использует libstdc++-6.dll с размером 712718байт.
эта версия конфликтует с DLL от Qt (4.6.x) с размером 812032байта.
Я нашёл 1 решение: перенести libstdc++-6.dll с размером 712718байт в каталог
kgp_arm_eabi\libexec\gcc\arm-kgp-eabi\4.6.0\
всё заработало (и kgp_arm_eabi_20100802 и Qt).
Правильно ли я сделал? необходимо ли использовать DLL в Ваших сборках или вы можете собирать сборки без DLL?
Заранее Спасибо.
Ваша сборка использует libstdc++-6.dll с размером 712718байт.
эта версия конфликтует с DLL от Qt (4.6.x) с размером 812032байта.
Я нашёл 1 решение: перенести libstdc++-6.dll с размером 712718байт в каталог
kgp_arm_eabi\libexec\gcc\arm-kgp-eabi\4.6.0\
всё заработало (и kgp_arm_eabi_20100802 и Qt).
Правильно ли я сделал? необходимо ли использовать DLL в Ваших сборках или вы можете собирать сборки без DLL?
Заранее Спасибо.
правильно - это моей сборкой собрать QT из исходников. тогда Qt будект слинкована и грузить libstdc++-6.dll из моего пакета. если по какимто причинам собирать не хочется - то правильно так как заработает, но тогда может гденибудь вызезти косяки.. а может и не вылезти.
свежак для арм
для 32 битной винды:
http://klen.org/Files/DevTools/kgp_arm_eab..._32_20101006.7z
для 64 битной:
http://klen.org/Files/DevTools/kgp_arm_eab..._64_20101006.7z
в принципе они ничем не должны отличатся ..., первая будет работать на обоих платформах.
как обычтно dyenhb имеется openocd
смешно но факт - вчерашнее состояние исходников binutils не разрешает кортексу-M3 использовать инструкцию SWI - но я это поправил, это народ прикручивает M0 м M1. есть просьба к тем кто их может проверить - проверить компиллер и сообщить об успешности или наоборот.
для 32 битной винды:
http://klen.org/Files/DevTools/kgp_arm_eab..._32_20101006.7z
для 64 битной:
http://klen.org/Files/DevTools/kgp_arm_eab..._64_20101006.7z
в принципе они ничем не должны отличатся ..., первая будет работать на обоих платформах.
как обычтно dyenhb имеется openocd
смешно но факт - вчерашнее состояние исходников binutils не разрешает кортексу-M3 использовать инструкцию SWI
- но я это поправил, это народ прикручивает M0 м M1. есть просьба к тем кто их может проверить - проверить компиллер и сообщить об успешности или наоборот.
Уважаемые Клен. Ваши архивы повреждены!
Пожалуйста, исправьте их!
Спасибо!
Пожалуйста, исправьте их!
Спасибо!
Цитата(spasbyspas @ Oct 6 2010, 22:18)
Уважаемые Клен. Ваши архивы повреждены!
Пожалуйста, исправьте их!
Спасибо!
Пожалуйста, исправьте их!
Спасибо!
как Вы определили что архивы битые. я сейчас скачал и проверил, архивы целые. оба. мож компилятор не работает - это тогда не архивы виноваты а я чтото недоложил. укажите симптомы. и еще, если вы будите пытатся запустить бинарники для 64 битной винды из под 32 битной - то она скажет что файлы повреждены или не являются исполняймыми.
Пожалуйста, простите меня. После замены версии с нового вер. архиватора - все извлечено!
Клен, а ты делаешь сборки тулчейной для linux? или быть может выложишь исходники (исходники или патчи) с краткой инструкцией по самостоятельной сборке (опции сборки, ...) Меня интересует тулчейн для армов
Меня интересует тулчейн для армов
Проблема у меня таже, что у AlexeyVoroshen (несколько постов тому назад) - накидал мне компилятор/линковщик всякого барахла под 50КБ во флеху.
До определенного момента все было ок (размер кода вроде соответствовал тому, что я писал)....
А потом - шаг влево, шаг вправо (даже при добавлении вызова ПУСТОЙ ф-ции) - захламляет флеха не пойми чем.
А перед этим говорит, "undefined reference to `_exit' ", "undefined reference to `_sbrk' " "undefined reference to `_sbrk' ", и т.д...
Ну на тебе заглушку syscalls.c.... Компилит... Вроде все нормуль... Но размер кода махом увеличивается на 50КБ! А проект- то пока еще пустой...
Операторы типа new,... и др. не использовал подавно.
.... Собрал тулчейн собственными силами вот из этого {gcc-4.5.1 | binutils-2.20 | newlib-1.18 | gdb-7.2 | openocd-0.5.0}
Причем, newlib собирал с опцией --disable-newlib-supplied-syscalls (сказать по правде, немного не понимаю - то ли при этом вообще должны запрещаться системные вызовы, то ли компилятор начинает искать их реализацию в других исходниках)....
Ну ладно, в любом случае проблема остается - непомерно великий код. хотя размер целевого кода не должен вылезти за пределы 32К флеши
(решил перейти с MSP430 на STM32, а заодно и перенести (переписать) существующий проект, который на первом занял менее 10КБ).
Брать STM32 со 128КБ флешой ради 50КБ ховнятены (прошу прощения за мой французский) - стремно.
Как же мне вразумить компилятор не тащить то, че он не должен тащить (не нужны мне системные вызовы, обработчики исключений, ... - без них как то работал на MSP-шнике)?!!!!!!!!!!!!!!!
С какими ключами можно собрать компилятор, чтобы тот размещал в памяти исключительно целевой код и самый минимум из необходимого, не относящегося к целевому коду?!!!!!!!!!!!!!!!
До определенного момента все было ок (размер кода вроде соответствовал тому, что я писал)....
А потом - шаг влево, шаг вправо (даже при добавлении вызова ПУСТОЙ ф-ции) - захламляет флеха не пойми чем.
А перед этим говорит, "undefined reference to `_exit' ", "undefined reference to `_sbrk' " "undefined reference to `_sbrk' ", и т.д...
Ну на тебе заглушку syscalls.c.... Компилит... Вроде все нормуль... Но размер кода махом увеличивается на 50КБ! А проект- то пока еще пустой...
Операторы типа new,... и др. не использовал подавно.
.... Собрал тулчейн собственными силами вот из этого {gcc-4.5.1 | binutils-2.20 | newlib-1.18 | gdb-7.2 | openocd-0.5.0}
Причем, newlib собирал с опцией --disable-newlib-supplied-syscalls (сказать по правде, немного не понимаю - то ли при этом вообще должны запрещаться системные вызовы, то ли компилятор начинает искать их реализацию в других исходниках)....
Ну ладно, в любом случае проблема остается - непомерно великий код. хотя размер целевого кода не должен вылезти за пределы 32К флеши
(решил перейти с MSP430 на STM32, а заодно и перенести (переписать) существующий проект, который на первом занял менее 10КБ).
Брать STM32 со 128КБ флешой ради 50КБ ховнятены (прошу прощения за мой французский) - стремно.
Как же мне вразумить компилятор не тащить то, че он не должен тащить (не нужны мне системные вызовы, обработчики исключений, ... - без них как то работал на MSP-шнике)?!!!!!!!!!!!!!!!
С какими ключами можно собрать компилятор, чтобы тот размещал в памяти исключительно целевой код и самый минимум из необходимого, не относящегося к целевому коду?!!!!!!!!!!!!!!!
Цитата(dimay192 @ Oct 11 2010, 13:38)
А потом - шаг влево, шаг вправо (даже при добавлении вызова ПУСТОЙ ф-ции) - захламляет флеха не пойми чем.
О каждом модуле, загруженном линкером, линкер отчитывается в map-файле - из-за какого символа модуль был загружен, и кто (какой модуль) на этот символ ссылался. Там же указаны все размеры всех загруженных в выходной файл секций. Как может быть "не пойми чем", если линкер отчитывается за каждый байт?Цитата(dimay192 @ Oct 11 2010, 13:38)
Как же мне вразумить компилятор не тащить то, че он не должен тащить (не нужны мне системные вызовы, обработчики исключений, ... - без них как то работал на MSP-шнике)?!!!!!!!!!!!!!!!
Во-первых, компилятор скорее всего ни при чем. Ссылки на системные вызовы, как правило, берутся из стандартных библиотек (в данном случае newlib). Вероятно, Вы используете библиотечные функции, требующие наличия системных вызовов, вот линкер их и подгружает.Во-вторых, давайте разговаривать более предметно. Покажите ваш map-файл и перечислите модули, которые по вашему мнению не должны были загружаться линкером. Попробуем совместными усилиями разобраться, почему он это сделал. Без знания конкретных подробностей вряд ли можно сказать что-либо для Вас полезное.
Цитата(dimay192 @ Oct 11 2010, 13:38)
С какими ключами можно собрать компилятор, чтобы тот размещал в памяти исключительно целевой код и самый минимум из необходимого, не относящегося к целевому коду?!!!!!!!!!!!!!!!
У меня компилятор всегда генерил только целевой код. Собираю как описано в документации.На каком языке пишете?
проект в студию, будем искать виноватых.... и мы их обязателно выберем в итоге
0. добавить в проект опции -fno-exceptions -fno-rtti, если их небыло
1. проверить результат и доложить.
2. обновить мою сборку, я наковырял небольшой породокс которым научился управлять но немогу пока объяснить - в новых сборках это учтено.
для 32 битной винды:
http://klen.org/Files/DevTools/kgp_arm_eab..._20101006_v2.7z
для 64 битной:
http://klen.org/Files/DevTools/kgp_arm_eab..._20101006_v2.7z
3. опять проверить и сравнить, результаты доложить.
4. будем детально разбиратся - 50кб на пустом месте это просто треш, это так оставлять нельзя - искать причину и жеч каленым железом.
некоторые размышления: если проект на С++ то еще както я могу разумно предположить куда копать(парадокс которыый я нашел), если С - то ваще абзац.... ниченипанятна
сейсас у меня демо проект в двух вариантах - один на С++ другой на С, содержит код FreeRTOS + несколько задач ( светодиод, USB, UART, тестовые сложные вычисления ) - в обои варантах получаю 10к++, С++ дает несколько процентов больше (есть виртуальные функции в обертках FreeRTOS вызовов) - такая ситуация то к чему я стремлю компиллер, у коллеги получилось 50к на пустом месте.... нестыковачка гдето...
0. добавить в проект опции -fno-exceptions -fno-rtti, если их небыло
1. проверить результат и доложить.
2. обновить мою сборку, я наковырял небольшой породокс которым научился управлять но немогу пока объяснить - в новых сборках это учтено.
для 32 битной винды:
http://klen.org/Files/DevTools/kgp_arm_eab..._20101006_v2.7z
для 64 битной:
http://klen.org/Files/DevTools/kgp_arm_eab..._20101006_v2.7z
3. опять проверить и сравнить, результаты доложить.
4. будем детально разбиратся - 50кб на пустом месте это просто треш, это так оставлять нельзя - искать причину и жеч каленым железом.
некоторые размышления: если проект на С++ то еще както я могу разумно предположить куда копать(парадокс которыый я нашел), если С - то ваще абзац.... ниченипанятна
сейсас у меня демо проект в двух вариантах - один на С++ другой на С, содержит код FreeRTOS + несколько задач ( светодиод, USB, UART, тестовые сложные вычисления ) - в обои варантах получаю 10к++, С++ дает несколько процентов больше (есть виртуальные функции в обертках FreeRTOS вызовов) - такая ситуация то к чему я стремлю компиллер, у коллеги получилось 50к на пустом месте.... нестыковачка гдето...
Значит такс:
1.проект на С++
В общем, структура кода приблизительно такова:
Главная ф-ция:
Содержит два класса
Первый, базовый
второй, наследник
2.опции -fno-exceptions -fno-rtti использовал!
3.Компилил проект четырьмя сборками компилятора
а. CodeSourcery
б. kgp_arm_eabi_x86_32_20101006
в. Собственная сборка
г. Собственная сборка (newlib собирал с опцией (среди прочих, оптимизирующих размер кода) --disable-newlib-supplied-syscalls, с использованием файла-заглушки syscalls.c)
Результаты получились такие (размер секции .text в байтах):
CodeSourcery - 57936
kgp_arm_eabi_x86_32_20101006 - 5008
Собственная сборка (в) - 10636
Собственная сборка (г) - 7784
При определении класса PlatformAbstractionLayer как абстрактный:
ситуация меняется так (размер секции .text в байтах):
CodeSourcery - 57936
kgp_arm_eabi_x86_32_20101006 - 41716
Собственная сборка (в) - 65664
Собственная сборка (г) - 64728
1.проект на С++
В общем, структура кода приблизительно такова:
Главная ф-ция:
Код
ResourceManager RM;
int main(void)
{
/*!< At this stage the microcontroller clock setting is already configured,
this is done through SystemInit() function which is called from startup
file (startup_stm32f10x_xx.s) before to branch to application main.
To reconfigure the default setting of SystemInit() function, refer to
system_stm32f10x.c file
*/
RM.start();
}
int main(void)
{
/*!< At this stage the microcontroller clock setting is already configured,
this is done through SystemInit() function which is called from startup
file (startup_stm32f10x_xx.s) before to branch to application main.
To reconfigure the default setting of SystemInit() function, refer to
system_stm32f10x.c file
*/
RM.start();
}
Содержит два класса
Первый, базовый
Код
class PlatformAbstractionLayer
{
public:
PlatformAbstractionLayer();
virtual ~PlatformAbstractionLayer();
inline void confGPIO(void);
inline void confConnection(void);
inline bool confSystemTimer(void);
protected:
...
};
inline void PlatformAbstractionLayer::confGPIO(void)
{
//Единственное место, где я задействовал библиотеку STM32F10x_StdPeriph_Lib_V3.3.0
...
GPIO_InitTypeDef GPIO_InitStructure;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_All;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AIN;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;
GPIO_Init(GPIOA, &GPIO_InitStructure);
GPIO_Init(GPIOB, &GPIO_InitStructure);
GPIO_Init(GPIOC, &GPIO_InitStructure);
GPIO_Init(GPIOD, &GPIO_InitStructure);
...
}
inline bool PlatformAbstractionLayer::confSystemTimer(void)
{
return !SysTick_Config(SystemCoreClock / 1000);
}
!!!Остальные методы класса пусты!!!
{
public:
PlatformAbstractionLayer();
virtual ~PlatformAbstractionLayer();
inline void confGPIO(void);
inline void confConnection(void);
inline bool confSystemTimer(void);
protected:
...
};
inline void PlatformAbstractionLayer::confGPIO(void)
{
//Единственное место, где я задействовал библиотеку STM32F10x_StdPeriph_Lib_V3.3.0
...
GPIO_InitTypeDef GPIO_InitStructure;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_All;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AIN;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;
GPIO_Init(GPIOA, &GPIO_InitStructure);
GPIO_Init(GPIOB, &GPIO_InitStructure);
GPIO_Init(GPIOC, &GPIO_InitStructure);
GPIO_Init(GPIOD, &GPIO_InitStructure);
...
}
inline bool PlatformAbstractionLayer::confSystemTimer(void)
{
return !SysTick_Config(SystemCoreClock / 1000);
}
!!!Остальные методы класса пусты!!!
второй, наследник
Код
class ResourceManager: public PlatformAbstractionLayer
{
public:
ResourceManager();
virtual ~ResourceManager();
inline void start(void);
inline void softTimersDecrement(void);
private:
uint32 SoftTimerTicks[SOFT_TIMER_CNT];
uint32 SoftTimerPeriod[SOFT_TIMER_CNT];
uint32 SoftTimerFlags;
inline void confHardware(void);
inline void confSoftware(void);
};
inline void ResourceManager::start(void)
{
this->confHardware();
this->confSoftware();
while(1)
{}
}
inline void ResourceManager::softTimersDecrement(void)
{
uint16 idx;
for(idx = 0; idx < SOFT_TIMER_CNT; idx++)
{
if((this->SoftTimerTicks[idx] != 0) && (--(this->SoftTimerTicks[idx]) == 0))
{
this->SoftTimerTicks[idx] = this->SoftTimerPeriod[idx];
this->SoftTimerFlags |= BV32(idx);
}
}
}
inline void ResourceManager::confHardware(void)
{
this->confGPIO();
this->confConnection();
this->confSystemTimer();
}
inline void ResourceManager::confSoftware(void)
{
}
{
public:
ResourceManager();
virtual ~ResourceManager();
inline void start(void);
inline void softTimersDecrement(void);
private:
uint32 SoftTimerTicks[SOFT_TIMER_CNT];
uint32 SoftTimerPeriod[SOFT_TIMER_CNT];
uint32 SoftTimerFlags;
inline void confHardware(void);
inline void confSoftware(void);
};
inline void ResourceManager::start(void)
{
this->confHardware();
this->confSoftware();
while(1)
{}
}
inline void ResourceManager::softTimersDecrement(void)
{
uint16 idx;
for(idx = 0; idx < SOFT_TIMER_CNT; idx++)
{
if((this->SoftTimerTicks[idx] != 0) && (--(this->SoftTimerTicks[idx]) == 0))
{
this->SoftTimerTicks[idx] = this->SoftTimerPeriod[idx];
this->SoftTimerFlags |= BV32(idx);
}
}
}
inline void ResourceManager::confHardware(void)
{
this->confGPIO();
this->confConnection();
this->confSystemTimer();
}
inline void ResourceManager::confSoftware(void)
{
}
2.опции -fno-exceptions -fno-rtti использовал!
3.Компилил проект четырьмя сборками компилятора
а. CodeSourcery
б. kgp_arm_eabi_x86_32_20101006
в. Собственная сборка
г. Собственная сборка (newlib собирал с опцией (среди прочих, оптимизирующих размер кода) --disable-newlib-supplied-syscalls, с использованием файла-заглушки syscalls.c)
Результаты получились такие (размер секции .text в байтах):
CodeSourcery - 57936
kgp_arm_eabi_x86_32_20101006 - 5008
Собственная сборка (в) - 10636
Собственная сборка (г) - 7784
При определении класса PlatformAbstractionLayer как абстрактный:
Код
class PlatformAbstractionLayer
{
public:
PlatformAbstractionLayer();
virtual ~PlatformAbstractionLayer();
inline void confGPIO(void);
inline void confConnection(void);
inline bool confSystemTimer(void);
protected:
virtual inline void softTimersDecrement(void)=0;
...
};
{
public:
PlatformAbstractionLayer();
virtual ~PlatformAbstractionLayer();
inline void confGPIO(void);
inline void confConnection(void);
inline bool confSystemTimer(void);
protected:
virtual inline void softTimersDecrement(void)=0;
...
};
ситуация меняется так (размер секции .text в байтах):
CodeSourcery - 57936
kgp_arm_eabi_x86_32_20101006 - 41716
Собственная сборка (в) - 65664
Собственная сборка (г) - 64728
осталось только понять чем абстрактный клас от виртуального отличается в нашем отдельн взятом случае.
полюбому дайте исходник одним файлом , код методов выкиньте, тут явно видно что дело не в целевом коде а в C++ подтяжках.
нужно смотреть *.map и листинги - посмотреть что за код прилазит.
есть вариант что зачемто (нам это предстоит выяснить зачем) прилинковывается new delete которые могут использоватся внутренним кодом stdlibc++.
предоагаю еже один тесть - переопределите операторы new и delete - хотябы заглушки сделайте. Насколько я помню в stdlibc++ по умолчанию через new тянет свой стандартный аллокатор памяти - это жопа для микроконтроллеров, он страшный.... а вот если свой подсунуть в определении new то может эти 50кб и отвалятся... попробуйте.
а ведь интересные грабли имеем, не так ли коллеги?
полюбому дайте исходник одним файлом , код методов выкиньте, тут явно видно что дело не в целевом коде а в C++ подтяжках.
нужно смотреть *.map и листинги - посмотреть что за код прилазит.
есть вариант что зачемто (нам это предстоит выяснить зачем) прилинковывается new delete которые могут использоватся внутренним кодом stdlibc++.
предоагаю еже один тесть - переопределите операторы new и delete - хотябы заглушки сделайте. Насколько я помню в stdlibc++ по умолчанию через new тянет свой стандартный аллокатор памяти - это жопа для микроконтроллеров, он страшный.... а вот если свой подсунуть в определении new то может эти 50кб и отвалятся... попробуйте.
а ведь интересные грабли имеем, не так ли коллеги?
Цитата(klen @ Oct 12 2010, 19:05)
а ведь интересные грабли имеем, не так ли коллеги?
Как скажете, маэстро.
(не смог сдержаться
)
Цитата(dimay192 @ Oct 12 2010, 17:23)
Значит такс:
...
...
Код
virtual inline void softTimersDecrement(void)=0;
Кхм! Не устаю повторять
Ну и от деструкторов, тем более виртуальных, в эмбеддед-приложениях, имхо, надо избавляться.
Цитата(AHTOXA @ Oct 12 2010, 22:39)
Кхм! Не устаю повторять
Ну и от деструкторов, тем более виртуальных, в эмбеддед-приложениях, имхо, надо избавляться.
Ну и от деструкторов, тем более виртуальных, в эмбеддед-приложениях, имхо, надо избавляться.
а как от них избавишся если уничтожаеш экземпляр приведенный к базовому? тогда не вызовется деструктор потомка..
вопрос в дркгом - откуда стоько кода? пройтись по табличке VMT нужны такты и не так много как думают, а кода тут не нада - он тотже как при вызове виртуальныйх функций - механизм един.
Цитата(klen @ Oct 12 2010, 21:57)
вопрос в дркгом - откуда стоько кода? пройтись по табличке VMT нужны такты и не так много как думают, а кода тут не нада - он тотже как при вызове виртуальныйх функций - механизм един.
Может я ошибаюсь, но на pure virtual функции, ставятся заглушки, которые могут потянуть за собой какой-то код exeptions, который за собой найдёт что потянуть. Не глядя на то, что ключ no-exceptions стоит — он на генерацию кода влияет, а не на то, что из библиотеки тянется.
логичное объяснение. можно предложить так - генерить вызов какого либо пользовательского обработчика. это будет не по стандарту но для контроллеров пойдет.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.