[AHTOXA 15]

:laughing:

зато работают исключения (которые нам нах ненужны на контроллерах)

:) Не, исключения - штука в принципе отличная. Но места и памяти - жалко.

будет время залезу внутрь и посмотрю че происходит по fno-exceptions, во всяком случае после прересборки мои проекы на 600% ужались.

Если бы оно (fno-exceptions) всегда работало, всё было бы чудесно. Хочет человек эксепшны - пожалуйста, не хочет - не надо. Но этот pure virtual портит всю малину.

нахер все это нада вырубать.

Ну, совсем-то наверное не надо:) А вот по fno-exceptions - да.

ктонить объяснит? есть ситуации когда без исключений не написать кода?

В принципе исключения - это стандарт Си++. Обойтись без них можно, видимо просто в недрах стандартных библиотек они в каком-то месте используются безусловно.

[klen 1]

В принципе исключения - это стандарт Си++. Обойтись без них можно, видимо просто в недрах стандартных библиотек они в каком-то месте используются безусловно.

 

О! идея.

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

[Terminator 0]

я добавил к проекту следующие файлы и с no-exception, no-rtti ничего лишнего не подключается.

 

malloc и free свои

sys.zip

[klen 1]

я добавил к проекту следующие файлы и с no-exception, no-rtti ничего лишнего не подключается.

 

malloc и free свои

 

у меня также, после введения в проекте синонимов malloc free на свои реализации. я писал что -600% по размеру.

остается вопрос - если эксепщены и RTTI выключены то кто malloc free тянет?

я всетаки соберу две версии libctdc++ одну нормально а вторую с no-exception, no-rtti. а там сравним че получится.

[AHTOXA 15]

я добавил к проекту следующие файлы и с no-exception, no-rtti ничего лишнего не подключается.

 

О, супер! Хватило только первого файла (sys.c), и всё стало отлично.

 

2 klen: наверное так и должны выглядеть эти __cxa_xx() при -fno-exceptions. Остальное, судя по всему, в либах правильно.

[klen 1]

свежак для ARM

 

www.klen.org/Files/DevTools/kgp_arm_cortex-m3_20090901.7z - обрезанна, для кортекса.

www.klen.org/Files/DevTools/kgp_arm_full_20090901.7z - полня

[alexander iz 0]

свежак для ARM

 

www.klen.org/Files/DevTools/kgp_arm_cortex-m3_20090901.7z - обрезанна, для кортекса.

www.klen.org/Files/DevTools/kgp_arm_full_20090901.7z - полня

 

Ситуация такая:

установлен WinAVR.

PATH сначала указывает на кучку свежаков, потом на winavr.

С крайтим свежаком для arm при сборке проекта вываливается mkdir с ошибкой обращения к памяти. С предыдущей сборкой такой ошибки нет, проект собирается корректно (mkdir.exe подсасывается из winavr\utils\bin определённо, потому что более его нигде нет).

 

C AVR досадно, но не работает avr-size из крайней сборки для avr (хотя, из winavr считает объёмы корректно).

 

c:\gcc\bin\avr-size.exe: unrecognized option `--mcu=atmega324p'

Usage: c:\gcc\bin\avr-size.exe [option(s)] [file(s)]

Displays the sizes of sections inside binary files

If no input file(s) are specified, a.out is assumed

The options are:

-A|-B --format={sysv|berkeley} Select output style (default is berkeley)

-o|-d|-x --radix={8|10|16} Display numbers in octal, decimal or hex

-t --totals Display the total sizes (Berkeley only)

--common Display total size for *COM* syms

--target=<bfdname> Set the binary file format

@<file> Read options from <file>

-h --help Display this information

-v --version Display the program's version

 

Как-то так.

 

Определённо, я что-то делаю не так. Только не пойму, что именно.

 

ЗЫ можно, для облегчения жизни, бросать ссылки на крайние сборки в первый пост?

[ReAl 0]

C AVR досадно, но не работает avr-size из крайней сборки для avr (хотя, из winavr считает объёмы корректно).

...

Определённо, я что-то делаю не так. Только не пойму, что именно.

Просто при сборке WinAVR донакладывают свои патчи. Почему (из каких соображений) они не попадают в ствол - я не знаю. Способность avr-size принимать конкретный тип контроллера и выдавать с процентом использования - один из таких давно существующих патчей.

[alexander iz 0]

Просто при сборке WinAVR донакладывают свои патчи. Почему (из каких соображений) они не попадают в ствол - я не знаю. Способность avr-size принимать конкретный тип контроллера и выдавать с процентом использования - один из таких давно существующих патчей.

 

Спасибо.

Подумаю, как лучше поступить..

 

А с mkdir решилось установкой winavr от 20090313 (был 200812xx).

Компилируется теперь без косяков.

Остаётся понять, в чём была проблема.

[NikAn 0]

Уважаемый Klen

 

Скажите, пожалуйста, для чего нужна libiconv-2.dll, и, как сделать так, чтобы arm-kgp-elf-g++.exe её находил.

 

Также буду весьма благодарен, если Вы выложите примеры make-файлов, который можно использовать для

компиляции standalone-приложений (.bin) для процессоров ARM7 (LPC2478) и Cortex-M3 (LPC1768)

 

И еще вопрос: поддерживает ли предложенный Вами openocd примитивный программатор типа Wiggler?

 

 

Заранее благодарен

[klen 1]

>Скажите, пожалуйста, для чего нужна libiconv-2.dll, и, как сделать так, чтобы arm-kgp-elf-g++.exe её находил.

это внешняя библа для того подержки кодировок разных языков

тут написано http://www.gnu.org/software/libiconv/

вообщето я ее в архив кладу(но мог както пропустить). оно должно лежать в /bin

 

>Также буду весьма благодарен, если Вы выложите примеры make-файлов, который можно использовать для

>компиляции standalone-приложений (.bin) для процессоров ARM7 (LPC2478) и Cortex-M3 (LPC1768)

 

..ммм .. я даже не знаю че сказать :unsure:

мэйкфайлы вообщето не для процессоров а для сборки конкретного приложения и у всех они могут быть разными.

 

максимум чем я могу помоч так это отослать вас к манам по make и положить пример для STM32F103RET6 в котором демонстрируется в числе прочего как юзать функциональность make. но МАНЫ ВПЕРЕД!!!

 

 

>И еще вопрос: поддерживает ли предложенный Вами openocd примитивный программатор типа Wiggler?

ага, сам виглером шил поначалу. есть особенность. Вы должны поставить стронние дрова для паралельного порта. это процедура в инете описана.

[NikAn 0]

Добрый вечер (ночь/утро/день) !

 

..ммм .. я даже не знаю че сказать :unsure:

мэйкфайлы вообщето не для процессоров а для сборки конкретного приложения и у всех они могут быть разными.

 

Я не правильно поставил вопрос. Я хотел узнать ключи компилятора, по которым он определяет для какого процессора

генерировать код. Это конечно можно в интернете узнать и проверить на железке, но как раз ее у меня пока инет.

 

ага, сам виглером шил поначалу. есть особенность. Вы должны поставить стронние дрова для паралельного порта. это процедура в инете описана.

 

У меня в конфигурационном файле для openocd есть такие слова:

#interface

interface parport

parport_port 0x378

parport_cable wiggler

 

На этот конфиг, я натравливал приложение с именем openocd-pp.exe. И драйвер какой-то был установлен.

Теперь, если запустить Ваш openocd, появляется сообщение:

Error: The specified JTAG interface was not found (parport)

The following JTAG interfaces are available:

1: ft2232

2: presto

 

То есть параллельный порт как бы и не подразумевается этим openocd, если я правильно понял.

Непонятно. Нужна такая dll'ка, чтобы параллельный порт "прикинулся" ft2232, что ли?

Вы говорите, что "эта процедура в инете описана". Напишите ссылку, пожалуйста.

 

Заранее благодарен

[klen 1]

увидите какие ключи говорят для какого проца компилить

arm-kgp-elf-gcc --target-help

 

косяг у меня - я конфигурил oocd без поддержки LPT.

дособираю новую сборку - там будет oocd рулить lpt. Вы как раз и протестируете.

[NikAn 0]

увидите какие ключи говорят для какого проца компилить

arm-kgp-elf-gcc --target-help

 

косяг у меня - я конфигурил oocd без поддержки LPT.

дособираю новую сборку - там будет oocd рулить lpt. Вы как раз и протестируете.

 

 

Добрый вечер (ночь/утро/день)!

 

Как у Вас обстоят дела с новой сборкой? Не терпится протестировать!

[klen 1]

Добрый вечер (ночь/утро/день)!

 

Как у Вас обстоят дела с новой сборкой? Не терпится протестировать!

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

 

я щас добавляю LTO оптимизацию для mingw32-host arm-target порта GCC. тут есть проблемки - нада ручками писать код - релизовать врапер unix системных вызовов из sys/mman.h ( mmap() munmap() mlock()..... ) средствами Win32 API. это отображение механизм файлов. Если кто знает готовый врапер для mingw32 тыкните носом - дело ускорится.

 

результатом будет оптимизация при линковке (LinkTimeOptimization - LTO ), поидее еще болще мусора должно выкидыватся но самое главное линкер сможет двигать куски кода более свободно, например рядом распологать взаимосвязанные функции и и спользовать короткие и более быстрые вызовы, капример rcall вместо call в AVR или чтото в этом роде. Нада разбиратся детально как это с умом приложить http://gcc.gnu.org/wiki/LinkTimeOptimization