Pisze program (dla Atmega8) i dla celow testowych deklaruje tablice o duzym rozmiarze np: char aaa[2000];
Kompilator nie zwraca ¿adnego ostrze¿enia, nie mowi±c o bledzie, ze przekroczylem zakres pamiêci SRAM dostêpnej w mikrokontrolerze. Pewnie mo¿na wl±czyæ takie sprawdzanie odpowiedni± opcja kompilatora, tylko jaka to opcja?
Pozdrowienia
W artykule <brn473$jkb$ snipped-for-privacy@atlantis.news.tpi.pl> Jack00 napisal(a):
A próbowałeś ją inicjować, choćby pętlą for?
Pozdrawiam
Marcin Stanisz
Witam. Mam podobny problem. Chcê siê zapoznaæ z kompilatorem avr-gcc i pisze sobie testowy program na at90s8515 ( bo akurat taki mam ). Mikrokontroler ten ma 512 bajtów pamiêci ram. W projekcie deklaruje dwie tablice po 2kB ka¿da i kompilator nie zg³asza b³êdów. B³±d zosta³ zg³oszony dopiero jak zmieni³em rozmiar tablic tak, ¿e sumaryczny rozmiar wszystkich zmiennych przekroczy³ 64KB. Sugerowa³o by to, ¿e kompilator domy¶lnie zak³ada, ¿e do procesora jest do³±czona zewnêtrzna pamiêæ ram o rozmiarze
64kB. W pliku io8515.h znalaz³em parametr XRAMEND, ale zmiany na 0x0000 lub 0x25f nie przynios³y ¿adnej widocznej zmiany. Czy jest tak, ¿e je¶li sumaryczny rozmiar zmiennych nie przekracza 512 bajtów to s± one umieszczane w wewnêtrznej pamiêci programu, a po przekroczeniu tej wielko¶ci automatycznie jest u¿ywana pamiêæ zewnêtrzna ? A mo¿e da siê to konfigurowaæ, je¶li tak to jak? Dziêkujê, za wszelkie wskazówki. Pozdrawiam, Jacek.U¿ytkownik "Jack00" snipped-for-privacy@hoga.pl napisa³ w wiadomo¶ci news:brn473$jkb$ snipped-for-privacy@atlantis.news.tpi.pl...
Czesc
U¿ytkownik "jsz" snipped-for-privacy@of.pl napisa³ w wiadomo¶ci news:brn7o2$95d$ snipped-for-privacy@atlantis.news.tpi.pl...
je¶li
AFAIK tak wlasnie robi sprzetowo AVR z wlaczona magistrala xram - po wyjsciu poza wewnetrzny zakres ram zaczyna generowac odwolania przez magistrale ( dlatego tez nie da sie w pelni wykorzystac zewnetrznej pamieci 64k - poczatkowy obszar pokrywajacy sie z zasobami wewnetrznymi jest tracony ).
Jak sobie porozmieszczac w zasobach sekcje data, bss, noinit, malloc,stack - sa do tego dyrektywy linkera. Domyslnie gcc ustawia data zaraz za obszarem sfr. Potem idzie bss i noinit, dlaej masz miejsce na malloc. Wskaznik stosu jest ustawiany na RAMEND ( wiec jak to zmienisz to moga stos wziac diabli
- tak sie np. dzieje gdy skompilujesz dla at128 a chcesz puscic na kostce w trybie kompatybilnym ze 103 ). Szczegoly ( z rysunkami ) w dokumentacji avr-libc.
Czesc
U¿ytkownik "Marcin Stanisz" snipped-for-privacy@poczta.bzdury.onet.pl>
napisa³ w wiadomo¶ci news: snipped-for-privacy@COS13.ilf.com...
tablice o duzym
bledzie, ze
To nic nie zmienia. AFAIK linker po prostu nie ma wbudowanych takich ostrzezen. Co zreszta jest nawet logiczne - klopoty zaczna sie znacznie wczesniej zanim co do bajta przekroczysz ram
- gdzies przeciez musi miescic sie stos ( i ewentualne alokacje runtime ). Ale sie nie zarzekam - wypadaloby zapytac na liscie avrgcc Jesli mam racje , to pozostaje sprawdzac rozmiar zajetego ramu i patrzec co sie dzieje ( albo uzyc frontendu, ktory to na biezaco wylicza i wyswietla np. w % zuzycia ). Na temat stosu kompilator niestety nie daje zadnych informacji, mozna co najwyzej przepatrzec rozmiary ramek uzywane przez poszczegolne funkcje ( podawane w generowanych plikach *.s ) i probowac oszacowac uwzgledniajac najbardziej niekorzystne zagniezdzenia.
Witam.
Dziêkuje za nakierowanie, dla usprawiedliwienia mogê jedynie dodaæ, ¿e dotychczas pracowa³em jedynie na kompilatorze C18 dla procesorów PIC, oraz asembler dla '51. W obu procesorach pamiêæ zewnêtrzna jest traktowana jako oddzielna pamiêæ i z t±d pewne problemy w przestawieniu siê na AVR i GCC-AVR. Pozdrawiam, Jacek.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required