ARM RIDE7 sekcje text, data i bss

Chciałem powrocic do tematu objetosci pamieci po kompilacji ale tym razem w RIDE7 bo tu troche inaczej jest to podawane. Po kompilacji sa takie sekcje text, data, bss Czy one oznaczaja to samo co podaje kompilator dla AVRow? Nie wiem z jakiego kompilatora korzysta RIDE7 (czy GCC) bo instaluje sie jako RKit Nie moge doszukac sie wyjasnienia. Z gory prosze o wyrozumialosc dla poczatkujacego :-)

Reply to
slawek7
Loading thread data ...

W dniu 2012-01-19 08:13, slawek7 pisze:

Jeśli to GCC: text + bss = FLASH data + bss = RAM

Reply to
Elektrolot

A nie tak:

text + data = FLASH data + bss = RAM

BSS jest sekcja zerowana wiec po co kopia we FLASH

Krystian

Reply to
Krystian

Ale to chyba nie jest GCC. Wydaje mi się że RIDE7 nie korzysta z GCC, chcoc nie wiem z czego?

Reply to
slawek7

W dniu 2012-01-19 11:42, slawek7 pisze:

A zajrzałeś do katalogu, w którym jest RIDE7?

formatting link
W sekcji 2 jest mowa o gcc

Reply to
Zbych

Masz całkowitą rację. Tak to jest jak się pisze z rozpędu ...

Reply to
Elektrolot

GCC znane bylo ze sztuczek w umieszczaniu tablic w pamieci flash. Rozumiem ze ARMy maja inna architekture niz AVRy ale umieszczanie tablic we flashu tez podlega jakims "sztuczkom" (w sensie odpowiednich dyrektyw)

Reply to
slawek7

In the darkest hour on Thu, 19 Jan 2012 03:12:04 -0800 (PST), slawek7 snipped-for-privacy@wp.pl screamed:

Nie. "Dyrektywy" są takie same jak w przypadku RAM. To w przypadku AVR jest inaczej.

Reply to
Artur M. Piwko

A dlaczego tu nie występuje slynny makefile?

Reply to
slawek7

Teoretycznie byty takie jak kompilator, linker, "bibliotekarz", IDE (bądź jego brak) czy też make i makefile (bądź ich brak) są od siebie niezależne i tak też mogą egzystować. W praktyce kompilator, linker i "bibliotekarz" bardzo blisko ze sobą współpracują ale już używanie IDE i/lub make to już raczej kwestia indywidualnych preferencji. Zarówno IDE jaki i stary dobry make maja swoje wady i zalety. W każdym bądź razie mając kompilator dostarczony w paczce razem z jakimś IDE wcale nie musisz używać owego IDE i/lub make aby wygenerować kod źródłowy a następnie działającą binarkę. Możesz wcale ich nie używać lub, co jest znacznie bardziej typowe, używać innych narzędzi do "zbudowania" projektu.

Poza tym poczytaj o architekturze von Neumanna i (zmodyfikowanej) harwardzkiej a następnie to przemyśl aby się przekonać, że to, co nazywasz "sztuczkami" wcale nimi nie jest.

Reply to
JDX

Wiem co masz na mysli a slowo sztuczki bylo uzyte przeze mnie na wyrost. Moje pytanie powinno brzmiec jak w ARMach zadeklarowac jakas tablice np tekst do umieszczenia w pamieci flash i jak potem odczytac?

Reply to
slawek7

W dniu 19.01.2012 19:05, slawek7 pisze:

np przez dodanie: __attribute__(( section(".text") )) __attribute__(( section(".rodata") ))

Poza tym gcc chyba dane const wyrzuca do flash samo.

Zazwyczaj tablicę odczytuje się przez indeks (foo=tab[i];) lub przez konwersję do wskaźnika (foo=*(tab+i);) ale chyba nie o to pytasz?

Reply to
Michoo

*KOMPILATOR:* $arm-none-eabi-gcc --version arm-none-eabi-gcc.exe (Sourcery G++ Lite 2010.09-51) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. *ŹRÓDŁO:* char tab1[3] = {'a', 'b', 'c'}; /* To ląduje w .data */ char tab2[3]; /* To ląduje w .bss */ const char tab3[3] = {'c', 'd', 'e'}; /* To ląduje w .rodata */ const char tab4[3]; /* To ląduje w .bss */

char *napis1 = "Napis 1.\n"; /* To ląduje w .data */ const char *napis2 = "Napis 2.\n"; /* To ląduje w .data */ char napis3[] = "Napis 3.\n"; /* To ląduje w .data */ const char napis4[] = "Napis 4.\n"; /* To ląduje w .rodata */

int main(int argc, char* argv[]) { return (int)(tab1[0]+tab2[0]+tab3[0]+tab4[0]); }

*KOMPILACJA:* $arm-none-eabi-gcc -mcpu=arm7tdmi -nostdlib -Wl,-Map=testrom.map

-Wl,--entry=main -o testrom.elf testrom.c

No i teraz pooglądaj sobie plik .map i popatrz gdzie wylądowały poszczególne tablice.

A to pod jakimi adresami będą znajdować się poszczególne sekcje i w związku z tym w jakim rodzaju pamięci mają wylądować to już sobie ustalasz sam pisząc (lub modyfikując) skrypt linkera. No i musisz mieć świadomość tego, że czasami być może będziesz musiał dostarczyć własny kod kopiujący odpowiednie sekcje z ROM do RAM jeśli domyślny nie wystarczy.

Reply to
JDX

No to z lekka hardkor jest. :-) I assembler może pluć ostrzeżeniami. Ale działa

Czasami wrzuca a czasami nie. :-) Patrz mój przykład. Tzn. jest tak, że niektóre consty lądują w .rodata a inne w .data która na starcie jest kopiowana do RAM i w związku z tym mamy duplikaty z których część jest zapewne zbędna.

Reply to
JDX

W dniu 2012-01-20 03:24, JDX pisze:

W tym przypadku napis ląduje w .rodata, tylko sam wskaźnik napis2 jest umieszczany w .data.

Reply to
Zbych

In the darkest hour on Fri, 20 Jan 2012 03:24:48 +0100, JDX snipped-for-privacy@onet.pl screamed:

Jeśli chodzi o napis2, sprawdź sobie to:

const char * s1 = "test"; char * const s2 = "test"; const char * const s3 = "test";

Reply to
Artur M. Piwko

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.