[klen 1]

свежак для Coretex-M3

 

довольно много свежего :

ветка gcc 4.5.0

новый релиз newlib 1.17.0

 

от себя добавил мультилиб специально оптимизированый под Cortex-M3, в нем немного поэксперементировал с оптимизацией

Недельку потестил на stm32f103rbt, крутим подтюненый FreeRTOS 5.2.0 c 6 задачками USB,UART, софтварный ARINC, debug trace facility... все работает без глюков.

пробуйте :)

 

http://www.klen.org/Files/DevTools/kgp_cor...1.0.20090413.7z

 

поскольку сборка только для кодогенерации под Cortex-M3 был проделан эксперемент : максимально компактный дистрибутив, для этого удалено все лишнее. В итоге сборка весит всего 7.07 мегабайт.

[AHTOXA 15]

Что-то ругается он у меня, пишет

 

ld.exe: cannot find -lgcc

 

Пустой проект, никаких инклюдов.

[ukpyr 0]

а нельзя ли собирать и под Linux ?

[klen 1]

2_AHTOXA

проверьте наличие файла libgcc.a в дериктории

ZZZ\lib\gcc\arm-kgp-elf\4.5.0\cortex-m3

где ZZZ - то куда Вы из архива все сложили.

 

2_ukpyr

в каком смысле под Linux, linux-target GCC или linux-host ?

короче для какой платформы код генерить это таргет, а на какой это хост.

[ukpyr 0]

:) хост конечно. Linux x86-32bit.

сейчас пользуюсь этим : http://www.codesourcery.com/sgpp/lite/arm/...?@template=lite

[AHTOXA 15]

2_AHTOXA

проверьте наличие файла libgcc.a в дериктории

ZZZ\lib\gcc\arm-kgp-elf\4.5.0\cortex-m3

где ZZZ - то куда Вы из архива все сложили.

 

Хм. Всё заработало... Наверное я в прошлый раз плохо вычистил предыдущую версию:-)

Прошу прощения за ложную тревогу.

[AHTOXA 15]

Продолжаю ковыряния:-) Дошёл до C++. Не работает:(

 

>arm-kgp-elf-g++ -v -c main.cpp
Using built-in specs.
Target: arm-kgp-elf
Configured with: ../../src/gcc/configure ../../src/gcc/configure --prefix=/kgp_arm 
--target=arm-kgp-elf --host=i686-pc-mingw32 --build=i686-pc-mingw32 
--disable-nls --disable-shared --disable-threads --disable-libssp 
--disable-libmudflap --disable-libgomp --enable-interwork --enable-multilib 
--with-newlib --with-headers=../../src/newlib/newlib/libc/include 
--with-float=soft --enable-languages=c,c++,fortran -v CC='distcc gcc -pipe'
Thread model: single
gcc version 4.4.0 20090207 (experimental) (GCC)
Klen's GCC package (KGP) for ARM/elf platform
see latest build in www.klen.orgCOLLECT_GCC_OPTIONS='-v' '-c' '-mfloat-abi=soft'

cc1plus -quiet -v -iprefix d:\kgp\bin\../lib/gcc/arm-kgp-elf/4.4.0/
-D__USES_INITFINI__ main.cpp -quiet -dumpbase main.cpp -mfloat-abi=soft -auxbas
e main -version -o C:/Temp/cci3DU9c.s
arm-kgp-elf-g++.exe: CreateProcess: No such file or directory

 

cc1plus-а нет в наборе. И почему 4.4.0 ?

 

 

Очень бы хотелось чтоб это заработало, потому что с Вашей сборкой у меня складываются отношения гораздо более удачно, чем со сборкой от CodeSourcery:)

 

------------

Ага, вот оно что. Вернул из заначки папки

\lib\gcc\arm-kgp-elf\4.4.0\

и

\libexec\gcc\arm-kgp-elf\4.4.0\

 

и файлы

 

\arm-kgp-elf\lib\libc.a

\arm-kgp-elf\lib\libm.a

\arm-kgp-elf\lib\libstdc++.a

 

- заработало. Даже ножкой дрыгает:)

Но меня немного смущает вся эта мешанина.

[AHTOXA 15]

- заработало. Даже ножкой дрыгает :)

 

Не, это я поспешил. Объекты не создаются, конструкторы не вызываются... Ножкой дрыгает только до первого обращения к какому-либо объекту.

:(

[Сергей Борщ 134]

Не, это я поспешил. Объекты не создаются, конструкторы не вызываются...

Объекты глобальные? Если да, то стартап свой или есть что-то в библиотеке? Если свой - есть ли в нем собственно вызов конструкторов?

[AHTOXA 15]

Объекты глобальные. Стартап свой, вернее, из примера 4-BlinkLeds порта scmRTOS под STM32 под gcc. (который c http://mercurial.intuxication.org/hg/scmrtos-cm3-gcc). Конструкторы вызываются. При компиляции тулчейном от CodeSourcery (arm-none-eabi-) пример даже работает, правда только с оптимизацией -O0. Меня это смущает:)

 

А arm-kgp-elf- здесь оплошал. ( Или я:) )

[klen 1]

Объекты глобальные. Стартап свой, вернее, из примера 4-BlinkLeds порта scmRTOS под STM32 под gcc. (который c http://mercurial.intuxication.org/hg/scmrtos-cm3-gcc). Конструкторы вызываются. При компиляции тулчейном от CodeSourcery (arm-none-eabi-) пример даже работает, правда только с оптимизацией -O0. Меня это смущает:)

 

А arm-kgp-elf- здесь оплошал. ( Или я:) )

 

не удивительно

я C++ ниразу не тестировал - тока C/fortran в реальных текущих разработках.

МЫСЛЬ испоьзовать С++ в микроконтроллерах просто ниразу НЕ ВЛЕЗЛА В МОЙ МОСК - РАЗМЕР ПРЕВЫШАЕТ ... куда катится мир?

 

итак. невызываются конструкторы? конструкторы каких объектов, как размещаете - cтатически или new?

посмотрим щас..

 

-------------------------------------------------

 

посмотрел:

#include "cplus_test.h"

 

#include "stm32f10x_gpio.h"

 

extern uint32_t _bss_end_ ;

uint32_t end = _bss_end_ ;

 

class blinker

{

private:

uint32_t ftimeout ;

uint32_t ftick_count ;

 

public:

blinker(uint32_t timeaut)

{

ftimeout = timeaut ;

}

 

~blinker()

{

};

 

void count_loop(uint32_t count)

{

ftick_count = xTaskGetTickCount();

for ( uint32_t acount = 0 ; acount < count ; acount ++ )

{

GPIOC->BRR = 0x0001000;

vTaskDelayUntil( &ftick_count , ftimeout);

GPIOC->BSRR = 0x0001000;

vTaskDelayUntil( &ftick_count , ftimeout);

}

}

 

void permanent_loop()

{

ftick_count = xTaskGetTickCount();

while(1)

{

GPIOC->BRR = 0x0001000;

vTaskDelayUntil( &ftick_count , ftimeout);

GPIOC->BSRR = 0x0001000;

vTaskDelayUntil( &ftick_count , ftimeout);

}

}

};

 

 

void test_constr_destr()

{

NOP();

blinker bl(50) ;

bl.count_loop(100) ;

NOP();

}

 

volatile portTickType tick_count ;

xTaskHandle cplus_debug_led_task_handle ;

void cplus_debug_led_task_code (void* param)

{

(void)param ;

blinker bl(250) ;

NOP();

test_constr_destr() ;

NOP();

bl.permanent_loop() ;

 

 

}

 

вот этот код работает

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

и даже работают

деструкторы не вызываются при выходе из функции в стеке которых они создались (причины на то есть)

 

тоесть глобальные оъекты можно использовать. тока зачем это нада? если все доелать(деструкторы) то в флеш еще потянется куча кода из libstdc++ и libsupc++ который обеспечивает например вызов деструкторов оъектов созданых в стеке функций... с этого места начнется полный завал.

[AHTOXA 15]

не удивительно

я C++ ниразу не тестировал - тока C/fortran в реальных текущих разработках.

МЫСЛЬ испоьзовать С++ в микроконтроллерах просто ниразу НЕ ВЛЕЗЛА В МОЙ МОСК - РАЗМЕР ПРЕВЫШАЕТ ... куда катится мир?

Ненене:-) Если аккуратно, то ничего не превышает, даже наоборот! Минимальный пример scmRTOS сильно меньше минимального примера FreeRtos:) Объекты -- статические, глобальные. В смысле - совсем глобальные, когда объект объвлен вне функции. То есть должен создаваться при инициализации. Плюс маленькие объектики на стеке, типа TCritSect. Они, конечно, должны разрушаться при выходе из функции. По-моему, стандартные библиотеки тут не при делах.

вот этот код работает

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

и даже работают

деструкторы не вызываются при выходе из функции в стеке которых они создались (причины на то есть)

Как компилировали? Голым свежаком 4.5.0? Или с либами от 4.4.0? То, что не вызываются деструкторы - это грустно. Если уж для MSP или даже для AVR это не является слишком тяжёлым бременем, то уж для АРМов-то это вообще семечки:)

тоесть глобальные оъекты можно использовать. тока зачем это нада? если все доелать(деструкторы) то в флеш еще потянется куча кода из libstdc++ и libsupc++ который обеспечивает например вызов деструкторов оъектов созданых в стеке функций... с этого места начнется полный завал.

Почему "доделывать"? Я не очень понимаю всю кухню, но разве в gcc этого нет?

[Сергей Борщ 134]

если все доелать(деструкторы) то в флеш еще потянется куча кода из libstdc++ и libsupc++ который обеспечивает например вызов деструкторов оъектов созданых в стеке функций... с этого места начнется полный завал.

Этот код тянется для деструкторов глобальных объектов. Почему именно этот код - не спрашивайте, не знаю. Там, действительно, подтягиваются и функции работы с файлами и куча еще всего кило на 20 примерно. Но обходится это довольно просто - не нужно делать деструкторы в глобальных объектах. Ибо они и не нужны - нормальная embedded-программа из main() не выходит и, значит, деструкторы никогда и не будут вызваны.

[klen 1]

Этот код тянется для деструкторов глобальных объектов. Почему именно этот код - не спрашивайте, не знаю. Там, действительно, подтягиваются и функции работы с файлами и куча еще всего кило на 20 примерно. Но обходится это довольно просто - не нужно делать деструкторы в глобальных объектах. Ибо они и не нужны - нормальная embedded-программа из main() не выходит и, значит, деструкторы никогда и не будут вызваны.

 

по поводу деструкторов погляжу как это все работает.

 

я уверен что все работает тока нада уметь ему об этом сказать!

[klen 1]

потратил время исследования вопросов from AHTOXA

 

как и я думал все работает, а именно:

глобальные объекты работают.

локальыне на стеке работают

динамические оъекты ТОЖЕ работают (new/delete). сделел обертки для api FreeRTOS, собрал и протестил на олимексовской STM32-H103

 

под словом работают имеется ввиду вызов конструктора и деструктора в соответствующие моменты.

 

чтоб все это заработала нада сделать определенные подготовительние телодвижения, по объему превышающие оные для проекта на чистом C.

 

в ближайште дни выложу свежак в котором будет новый фича - оптимизатор циклов Graphite. заодно распишу че де как C++ заюзать.