Adresy zmiennych w AVR-GCC

Patryk Sielski napisał(a):

Patryk Sielski napisał(a):

To nie tak, avr-nm musisz użyć na pliku wynikowym linkera. To co dostaniesz z pliku .o to offset w zmiennych tylko jednego modułu. Po zlinkowaniu wszystkich razem będziesz miał co innego. Weźmy na przykład plik:

int ala = 1, ma = 2, kota = 3;

int main(void) { return 0; }

Po skompilowaniu źródła do .o dostaniemy:

$ avr-gcc -mmcu=atmega8 test.c -c -o test.o $ avr-nm test.o | grep '\(ala\|ma\|kota\)' 00000000 D ala 00000004 D kota 00000002 D ma 00000000 T main

A po zlinkowaniu:

$ avr-gcc -mmcu=atmega8 test.o -o test $ avr-nm test | grep '\(ala\|ma\|kota\)' 00800060 D ala 00800064 D kota 00800062 D ma

Gdybyśmy dodali jeszcze inne moduły, to może wyjść coś takiego:

$ avr-gcc -mmcu=atmega8 bla.o test.o -o test $ avr-nm test | grep '\(ala\|ma\|kota\)' 00800064 D ala 00800068 D kota 00800066 D ma

Dlatego lepiej nie dodawaj offsetów, tylko bierz z wynikowej binarki.

w.

DJ napisał(a):

Cały "wynalazek" wynika z tego, że gcc (egcs) jest w sumie dość głupim kompilatorem znającym tylko jedną "rozdeptaną" liniową przestrzeń adresową. I nie jest w gruncie rzeczy dopasowany do procesorów o wielu przestrzeniach adresowych, w których identyczne adresy wskazywałyby na coś zupełnie innego (np. w procesorach DSP bardzo często jest rozdzielona pamięć programu i danych, mogą być też 2 niezależne pamięci danych X i Y). W procesorach AVR mamy właśnie taki przypadek: jest sobie pamięć programu (Flash) od adresu 0, jest i pamięć danych rozpoczynająca się od adresu 0 (od 0 leżą tak na prawdę rejestry a SFR i RAM startują nieco wyżej). No i aby nic się nie pozajączkowało kompilatorowi wymyślono, że adresy w RAMie będą przesunięte o magiczną stałą 0x800000 a adresy w EEPROMie o 0x810000. Bardzo ładnie to widać w pliku .map:

Memory Configuration

Name Origin Length Attributes text 0x00000000 0x00020000 xr data 0x00800060 0x0000ffa0 rw !x eeprom 0x00810000 0x00010000 rw !x

BTW: Kompilator gcc bardzo dobrze czuje się w środowiskach ze wspólną przestrzenią adresową, np. procesorach ARM. Tam niepotrzebne jest jakiekolwiek specjalne przesuwanie RAMu czy Flasha no i procesor może korzystać z całych 4 GB pamięci (zwykle i tak ogranicza to liczba nóg adresowych na zewn. interfejsie).

Hm, ten wynalazek to pamieta chyba jeszcze bardzo stare unixy i procesory, gdzie program trzeba bylo podzielic na logiczne segmenty

J.

Adam Dybkowski napisał(a):

Dzieki za objasneinie :) Juz o tym czytalem kiedys w manualu od avr-gcc, ale jak przychodzi wytlumaczyc innym o co chodzi to juz mi nie bardzo idzie ;)

Wlasnie tak patrze tez na swoje .map data origin 0x00800060 Nie wiem czemu mi sie zdawalo ze to 0x00800000... Ale patrze tez na .lss i widze ze jednak od adresow jest odjete

SRAM w AVR nie zaczyna sie od adresu 0, tylko 0x60, przestrzen adresowa

Cześć.

Dnia Wed, 21 Jun 2006 18:53:51 +0200, Wojtek Kaniewski napisał(a):

A nie lepiej zadeklarować własny segment i umieścić go w dobrze określonym miejscu? Bo tak to co kompilacja trzeba sprawdzać - linker może nawywijać, co chce :)

Pozdrawiam Marcin Stanisz