W dniu 14.12.2017 o 16:56, Marcin pisze:

> Czy ktos zana pood, dlaczego prosty przyklad:
>
> arm_rfft_fast_instance_f32 S;
> arm_cfft_radix4_instance_f32 cfft;
>
> static arm_rfft_instance_q15 Sq15;
>
> volatile static uint32_t result ;
> result = arm_rfft_init_q15(&Sq15, 128, 0, 1);
>
> for(int i=0; i < 128; i++){
> q15InData[i] = (q15_t)(sin3x[i] * 2048.0);
> }
>
> volatile static q15_t magnitude[128];
> arm_rfft_q15(&Sq15, (q15_t*)q15InData, (q15_t*)fft_results);
>
> arm_cmplx_mag_q15((q15_t*)fft_results, (q15_t*)magnitude, 128 );
>
>
> kompiluje sie do 10x wiekszego rozmiaru przy GCC ? Wiedzialem ze GCC jest mniej
zoptymalizowane, ale zeby 10x wiekszy kod generowac to juz przesada.

Nie podałeś z jakimi flagami kompilujesz program, czy włączyłeś
optymalizację, czy każesz kompilatorowi usunąć nieużywane funkcje i dane
z programu. Na początek dodaj flagi -Os -ffunction-sections
-fdata-sections do kompilacji oraz -Wl,--gc-sections do wywołania linkera.
Sprawdź też jak wygląda rozmiar po kompilacji na Cortexa M4. Jeśli wtedy
rozmiar mocno spadnie, to winna może być software'owa emulacja floatów.
Komercyjne pakiety (także te korzystające z gcc) mają często biblioteki
ręcznie dłubane w assemblerze i stąd różnica w prędkości/wielkości.