B??d podczas kompilacji pliku w C

Tu masz napisane o co chodzi, sekcja "text" to kod programu, brakło miejsca we flashu.

W dniu 2010-09-09 07:19, slawek7 pisze:

Tak

Lemon

Zabraklo miejsca w pamięci. Spróbuj dodać opcje kompilatora -Os jesli juz jej nie masz.

Było kompilowane z -Os. Dziwne, ponieważ powinno być wszystko dobrze, poniewaz zostało to ściagniete z EdW a tam podobno sie kompiluje bez kłopotów

On 2010-09-09 19:44, slawek7 wrote: > Było kompilowane z -Os. > Dziwne, ponieważ powinno być wszystko dobrze, poniewaz zostało to > ściagniete z EdW a tam podobno sie kompiluje bez kłopotów

Pokaż polecenia kompilacji i dumpowania hex-a, może poza .text do flash ląduja jakies inne sekcje.

Dodatkowo zainteresuj się:

avr-objdump -S -h <main.elf >main.lst

Bedzie widac co tyle zajmuje.

No i jesli flash był wypełniony na maxa to zmaiana kompilatora mogła spowodowac kłopoty z pomieszczeniem się bo generuje się inny kod.

W dniu 2010-09-09 19:44 slawek7 napisał(a):

Zmień na chwilę procesor na większy (dla kompilatora). Zobaczysz ile przekroczył program w stosunku do możliwości MCU, pod który obecnie kompilujesz. Zajrzyj też do pliku .map, który wypluwa linker. Może wystarczy coś małego wyciąć, skorzystać z prostszej wersji funkcji printf itp.

Do kompilacji używam AVRStudio w połączeniu z WinAVR. Zminiłem procesor na Atmega32 i za to pojawia się inny błąd:

c:/winavr/bin/../lib/gcc/avr/4.3.0/../../../../avr/lib/ avr5\libc.a(fp_powsodd.o): In function `__fp_powsodd': (.text.fplib+0x10): relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in c:/winavr/bin/../ lib/gcc/avr/4.3.0/avr5\libgcc.a(_mul_sf.o) c:/winavr/bin/../lib/gcc/avr/4.3.0/../../../../avr/lib/ avr5\libc.a(fp_powsodd.o): In function `__fp_powsodd': (.text.fplib+0x20): relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in c:/winavr/bin/../ lib/gcc/avr/4.3.0/avr5\libgcc.a(_mul_sf.o) Build failed with 1 errors and 1 warnings...

Jeżeli było kompilowane starszą wersja gcc, to mogło być mniejsze. gcc ma niestety taką przykrą cechę, że wraz ze wzrostem numeru wersji generowany kod jest coraz gorszy i coraz większy, trafia tam kupa bezsensownych operacji, typu "pogrubianie zmiennych", czyli zapisywanie kilka razy tego samego i to do rejestrów które potem nie są używane, ale jakby tego było mało, to jeszcze jest kawałek kodu, który sprawdza, czy aby na pewno zapisało się to co miało.

A może mi ktoś pomóc rozszyfrowac to co tam wyskoczyło w błędzie?

Ściągnij stare WinAVR, zainstaluj i skompiluj, problem z głowy w 10 minut. Prawdopodobnie nie linkujesz biblioteki z funkcjami zmiennoprzecinkowymi (libm) i kompilator dodaje własne z glibc, które są 36,1 razy gorsze (bo pisane w z C, aczkolwiek tym z libm też daleko do rewelacyjności) Pokaż Makefile (skąd go masz?) i kod. Próbowałeś w ogóle wpisać fragmenty tych komunikatów w ulubioną wyszukiwarkę?, bo ja tak.

W dniu 2010-09-10 12:34, slawek7 pisze:

Wystaw archiwum z programem na jakimś publicznym serwerze, to może jakaś dobra dusza się zlituje i ci pomoże to skompilować.

Bardziej mi zalezy aby sie czegos nauczyc np co oznaczaja błedy i jak sobie z nimi radzić. Instalacja starej wersji to wiecej niz 10min bo musialbym poustawiac z powrtotem kilka rzeczy np pliki wsadowe. To juz łatwiej zmienic program aby poszło na nowszej wersji.

Nie wiem jak zmienic te bibloteki?

1000*cos(latstopnie*3.1415/180)

To nie jest najlepszy pomysł na mikrokontroler. Zobacz jak wiele symboli plik gpc.c probuje dociągnąć:

000011da T __addsf3x 00001256 T cos 00001262 T __divsf3 00001268 T __divsf3x 000012ee T dtostrf 000013fe T __fixsfsi 000013fe T __fixunssfsi 00001424 T __fp_lneg 00001434 T __floatunssisf 00001438 T __floatsisf 0000144c T fmod

i wiele więcej. Ten "cos" to twój dodatek?

W dniu 2010-09-10 18:05 Sebastian Biały napisał(a):

Dlaczego by nie? Jeżeli potrzeba to przecież jest dostarczana biblioteka matematyczna, wystarczy ją dolinkować opcją -lm. Kwestia tylko czy wszystkie funkcje potrzebne do zadziałania tego jednego cosinusa wejdą do Flasha.

Własnie sobie odpowiedzialeś na własne pytanie. Targetem do tego projektu jest atmega8. Całość niezbędnej biblioteki matematycznej zajmuje nieco mniej niz 4kB (w/g pliku map). Poświęcasz więc 50% pamięci uC na implementację cos. To duzo i to średni pomysł, z kodu wynika że tego cosinusa można równie dobrze ztablicować bo i tak sa tam robione brudne sztuczki typu x = x*0.001 więc dokładnośc tych obliczeń jest do bani, ponadto obliczenia robione sa na floatach a może wcale nie muszą. Innymi słowy jest sporo przestrzeni na optymalizację.

Do autora pierwszego postu: prawdopodobnie najszybciej było by zmienić procesor z ATMega8 na ATMega168, o ile pamiętam jest pinologicznie identyczny (niech mnie ktoś poprawi), trzeba by jednak troche poprawić kod, rejestry się pozmieniały (acz nie jakoś strasznie, w 5 minut do poprawy).

W dniu 2010-09-10 23:51 Sebastian Biały napisał(a):

W razie czego jest jeszcze ATmega328, też w takich samych obudowach jak cała seria ATmeg 48/88/168.

Ściągaj starą wersję. Wcale nie łatwiej zmienić program, kodu jest dużo, poza tym jest kiepskiej jakości. Wygląda jakby autor próbował uskuteczniać BASCOM w C.