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 :-)
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)
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?
*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]); }
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.
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.