ARM RIDE7 sekcje text, data i bss

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

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

A nie tak:

text + data = FLASH data + bss = RAM

BSS jest sekcja zerowana wiec po co kopia we FLASH

Krystian

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

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

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

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

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)

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.

A dlaczego tu nie występuje slynny makefile?

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.

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?

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?

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]); }

-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.

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.

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.

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";