Witam
Temat dotyczy optymalizacji kompilatora gcc dla uC AVR, dodam jeszcze że nie mam wielkiego doświadczenia w programowaniu w tym środowisku.
A więc problem jest taki - przykładowy program poniżej:
#define F_CPU 8000000
#include <avr/io.h>
#include <util/delay.h>
int main(void)
{
DDRB = 0xff;
PORTB = 0X00;
uint8_t x=1;
while(1)
{
PORTB = x;
_delay_us(x++);
}
return(0);
}
generuje plik .HEX o wielkosci 4KB (2042 lini asm)
Co wydaje mi sie wielkością olbrzymią jak na tak prostą funkcję.
Tym bardziej że inny kompilator stworzył plik .HEX o wielkości 42 bajtów czyli średnio 100 razy mniejszy - programu robiącego dokładnie to samo.
(Flaga optymalizacji w pliku Makefile jest ustawiona na -s )
Program ze stałym argumentem funkcji _delay_us() tworzy .HEX o wielkości 111 bajtów.
Pytanie wiec gdzie tkwi przyczyna tak dużego kodu w pierwszym przypadku - czy problem stanowi tu parametryzacja funkcji _delay_us()
czy popełniłem gdzieś trywialny błąd?
Temat dotyczy optymalizacji kompilatora gcc dla uC AVR, dodam jeszcze że nie mam wielkiego doświadczenia w programowaniu w tym środowisku.
A więc problem jest taki - przykładowy program poniżej:
#define F_CPU 8000000
#include <avr/io.h>
#include <util/delay.h>
int main(void)
{
DDRB = 0xff;
PORTB = 0X00;
uint8_t x=1;
while(1)
{
PORTB = x;
_delay_us(x++);
}
return(0);
}
generuje plik .HEX o wielkosci 4KB (2042 lini asm)
Co wydaje mi sie wielkością olbrzymią jak na tak prostą funkcję.
Tym bardziej że inny kompilator stworzył plik .HEX o wielkości 42 bajtów czyli średnio 100 razy mniejszy - programu robiącego dokładnie to samo.
(Flaga optymalizacji w pliku Makefile jest ustawiona na -s )
Program ze stałym argumentem funkcji _delay_us() tworzy .HEX o wielkości 111 bajtów.
Pytanie wiec gdzie tkwi przyczyna tak dużego kodu w pierwszym przypadku - czy problem stanowi tu parametryzacja funkcji _delay_us()
czy popełniłem gdzieś trywialny błąd?
