Jak zrozumieć sekcje pamięci text, data i bss w ARM RIDE7 dla początkujących?

Thu Jan 19, 2012 9:13 am   

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

Thu Jan 19, 2012 10:17 am   

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

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

Thu Jan 19, 2012 11:09 am   

On 2012-01-19 10:17, Elektrolot wrote:

A nie tak:

text + data = FLASH
data + bss = RAM

BSS jest sekcja zerowana wiec po co kopia we FLASH

Krystian

Thu Jan 19, 2012 11:47 am   

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

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

http://www.raisonance.com/tzr/scripts/downloader2.php?filename=T009/folder2/f4/db/4gigg3n483xv/2&mime=text/plain&originalname=Release_notes_RKit-ARM.txt

W sekcji 2 jest mowa o gcc

Thu Jan 19, 2012 11:48 am   

W dniu 2012-01-19 11:09, Krystian pisze:

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

Thu Jan 19, 2012 12:42 pm   

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

Thu Jan 19, 2012 1:12 pm   

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)

Thu Jan 19, 2012 2:23 pm   

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

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

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:234B ]
[ 14:22:48 user up 13052 days, 2:17, 1 user, load average: 0.56, 0.89, 0.45 ]

hypocrite, n.: A man who says he likes cats, but won't eat pussy.

Thu Jan 19, 2012 6:57 pm   

On 2012-01-19 18:24, slawek7 wrote:

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

Thu Jan 19, 2012 7:24 pm   

A dlaczego tu nie występuje slynny makefile?

Thu Jan 19, 2012 8:05 pm   

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?

Fri Jan 20, 2012 12:45 am   

W dniu 19.01.2012 19:05, slawek7 pisze:

__attribute__(( section(".text") ))
__attribute__(( section(".rodata") ))

Poza tym gcc chyba dane const wyrzuca do flash samo.


konwersję do wskaźnika (foo=*(tab+i) ale chyba nie o to pytasz?

--
Pozdrawiam
Michoo

Fri Jan 20, 2012 3:24 am   

On 2012-01-19 19:05, slawek7 wrote:

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

Fri Jan 20, 2012 3:31 am   

On 2012-01-20 00:45, Michoo wrote:

działa


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.

Fri Jan 20, 2012 8:11 am   

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.