AVR-GCC kompilator C dla mikrokontroler├│w AVR, cz─Ö┼Ť─ç 14.pdf

K U R S

AVR–GCC: kompilator C dla

mikrokontrolerów AVR, część 14

Obsługa obszarów pamięci

mikrokontrolerów AVR, część 2

Jedną z wielkich zalet

mikrokontrolerów AVR (podobnie

zresztą jak układów wielu

innych rodzin) jest integracja

w jednym układzie wszystkich

potrzebnych rodzajów pamięci

(SRAM, EEPROM i Flash),

co pozwala na znaczne

uproszczenie budowanych

urządzeń. Ich obsługa nie

zawsze jest jednoznaczna,

co sprawia duże trudności

programistom, zwłaszcza tym,

którzy są przyzwyczajeni do

korzystania z pełni możliwości

języka C.

miaru wewnętrznej pamięci kostki).

W taki właśnie sposób – poprzez

rzutowanie wydzielonych obszarów

pamięci AVR na własny wspólny

liniowy obszar pamięci – linker

AVR–GCC radzi sobie z architek-

turą typu Harvard ( rys. 33 ). Duża

wartość offsetów zapewnia, że na-

wet dla największych dostępnych

pamięci nie wystąpi nałożenie się

obszarów. Z tak zapisanej (w pliku

elf ) zawartości pamięci narzędzie

avr–objcopy ekstrahuje następnie po-

trzebne fragmenty do wynikowych

plików hex . Stąd też wynika dość

rozbudowana postać wywołania dla

pliku zawartości eeprom, np:

avr–objcopy.exe –j.eeprom –set–

–section–ﬂags=.eeprom=”alloc,lo-

ad” ––change–section–lma.eeprom=0

–O ihex t0_test.elf t0_test.eeh

które musi z powrotem przesunąć

początkowy adres do pozycji 0.

Przy dokładaniu w układzie ze-

wnętrznej pamięci SRAM należy

mieć na uwadze, że (ze względu

na wspominany już mechanizm

sprzętowej obsługi magistrali) ko-

mórek od zera do RAMEND nie da

się zaadresować bezpośrednio (te

adresy dotyczą zasobów wewnętrz-

nych mikrokontrolera). Jest to bar-

dzo proste do ominięcia w razie

stosowania kostki 62256 (32 kB).

Adresy powyżej 32 kB (od 0x8000)

mają ustawioną linię A15, której ta

kostka nie używa – ﬁzycznie więc

adresowany jest obszar od zera.

W rezultacie mamy do dyspozycji

przestrzeń adresową od zera do

0x8000 + RAMEND ( rys. 34 ), nato-

miast linia A15 może pozostać wy-

łączona (odpowiedni pin jest wyko-

rzystywany jako zwykłe we/wy).

Przy zewnętrznej pamięci o mak-

symalnej pojemności 64 kB sprawa

nie jest już taka prosta. Zgodnie

z opisami dokumentacyjnymi Atmela

można to osiągnąć ustawiając adres

>= 0x8000 (jak powyżej) i przełą-

czając linię A15 programowo. Dolny

obszar ( 0 – RAMEND ) zewnętrznej

Rys. 34. Obszar adresowania

0x8000...(0x8000+RAMEND) fizycznie

odpowiada obszarowi 0...RAMEND

dodatkowego układu 62256

kostki pozostaje jednak niedostępny

dla linkera i można go obsłużyć tyl-

ko bezpośrednio poprzez wskaźniki.

Po odpowiednim skonﬁgurowa-

niu nie musimy już w programie

pamiętać o rozmieszczeniu poszcze-

gólnych obszarów – linker sam za-

dba o właściwe adresowanie używa-

nych zmiennych. Inaczej wygląda

sprawa gdy używamy magistrali do

komunikacji z zewnętrznym urzą-

dzeniem, którego rejestry znajdują

się pod konkretnymi – zależnymi

od połączeń i systemu dekodowa-

nia – adresami. Mamy w tym celu

do dyspozycji dwie różne metody.

Pierwsza to zastosowanie standardo-

wych operacji na wskaźnikach. 16–

–bitowy adres jest traktowany jako

wskaźnik na 8–bitową komórkę pa-

mięci ( char * lub unsigned char * )

– a dostęp do tej komórki jest reali-

zowany jako odwołanie do obiektu

wskazywanego. Stosujemy typowy

zapis C:

*((volatile unsigned char *) adres_ko-

morki)

Podczas konﬁgurowania pamięci

danych ponownie pojawia się wspo-

mniany wcześniej „dziwny” offset

0x800000 dodawany do adresów

RAM. Zawsze należy go uwzględ-

niać przy wpisywaniu nowej loka-

lizacji sekcji danych (czyli przeno-

sząc . data do pamięci zewnętrznej

jak w powyższym opisie, np. dla

ATmegi 128 wpiszemy –Tdata-

=0x801100, a nie –Tdata=0x1100

jak intuicyjnie wynikałoby z roz-

Rys. 33. Rzutowanie pamięci AVR

na liniowy obszar pamięci linkera

AVR–GCC

któremu dyrektywą #deﬁne mo-

żemy dla wygody nadać czytelną

nazwę zgodną z przeznaczeniem ko-

mórki. Sprawdźmy, że to rzeczywi-

ście działa, np. tak (ATmega 8515,

RAMEND=0x260):

Elektronika Praktyczna 4/2006

109

K U R S

Rys. 35. Wprowadzenie zmodyfiko-

wanego skryptu linkera oraz adresu

startowego dodatkowej sekcji RAM

wyeliminowany jeśli nakażemy lin-

kerowi utworzenie dodatkowej sekcji

w pamięci RAM i ulokowanie w niej

zmiennych wyposażonych w odpo-

wiedni atrybut.

Sprawdźmy szybko na małym

przykładzie jak to działa: ulokujmy

na początku zewnętrznej pamię-

ci ATmega 8515 (od adresu 0x260 )

sekcję . extsec i skierujmy tam obsłu-

gę czterech rejestrów. W tym celu

do dyrektyw linkera dodamy wpis

–section–start,.extsec=0x800260 i za-

deklarujemy odpowiednie zmienne

z atrybutem przynależności do sek-

cji . extsec . Należy mieć jednak na

uwadze, że chociaż zazwyczaj linker

nadaje adresy w kolejności zgodnej

z uszeregowaniem deﬁnicji wkodzie,

to generalnie wcale nie jest to za-

gwarantowane. Dlatego zamiast 4

niezależnych zmiennych char użyje-

my „opakowującej” je struktury:

volatile struct

{

char rejestr1;

char rejestr2;

char rejestr3;

char rejestr4;

} ExtStruct __attribute__((sec-

tion(„.extsec”))) ;

Po skompilowaniu i wczytaniu do

AvrStudio sprawdzamy, że ExtStruct

jest rzeczywiście ulokowana pod ad-

resem 0x260, a odwołania do pól,

np. ExtStruct.rejestr2 = 0xaa ; po-

wodują zmianę we właściwym miej-

scu pamięci (w praktyce nie spotka-

ła mnie ze strony AVR–GCC niespo-

dzianka w postaci zamiany kolejności

pól struktury w pamięci, jednak dla

ostrożności można zamiast struktury

zastosować po prostu tablicę – tu

kolejność elementów jest już całko-

wicie jednoznaczna).

Pomimo przekazania kontroli

linkerowi musimy jednak wstępnie

zadbać, aby nie nastąpiła kolizja

nowej sekcji z sekcjami tworzonymi

automatycznie. Na ogół bierzemy

też wtedy pod uwagę oferowany

przez AVR sprzętowy rozdział ze-

wnętrznej przestrzeni adresowej na

dolną i górną z możliwością usta-

wienia różnych czasów dostępu

– co pozwala na podłączenie jedno-

cześnie szybszych oraz wolniejszych

układów peryferyjnych.

Drugim – zamiennym – sposo-

bem przekazania linkerowi instruk-

cji o dodatkowej sekcji jest mody-

ﬁkacja skryptu. Na przykład dla

atmega 8515 (architektura 4) sko-

piujemy sobie odpowiedni skrypt

\folder_kompilatora\avr\lib\ldscripts\

avr4.x jako avr4sec.x do subfoldera

projektu i dopiszemy w nim:

– informację o nowym obszarze pa-

mięci i jego adresie startowym:

MEMORY

{

text (rx) : ORIGIN = 0, LENGTH =

data (rw!x): ORIGIN = 0x800060,

LENGTH = 0xffa0

eeprom (rw!x): ORIGIN = 0x810000,

LENGTH = 64K

page_2 (rw!x): ORIGIN = 0x800300,

LENGTH = 4K

}

– informację o nowej sekcji (w dzia-

le SECTIONS ):

.eeprom:

{

*(.eeprom*)

__eeprom_end =. ;

} > eeprom

.page2:

{ *(.page2) } > page_2

#deﬁne EXT_MEM_CELL(X) *((volatile

unsigned char*)X)

EXT_MEM_CELL(0x400) = 0xaa;

136: 8a ea ldi r24, 0xAA ; 170

138: 80 93 00 04 sts 0x0400, r24

Następnie w wywołaniu linkera

opcją –Tścieżka_skryptu wskazujemy

zmodyﬁkowany skrypt. AvrSide ofe-

ruje w tym celu wsparcie – korzy-

stanie z oddzielnego skryptu i jego

pełną nazwę ustawiamy na zakład-

ce Linker dialogu konﬁguracji pro-

jektu ( rys. 35 ). Po skompilowaniu

projektu sprawdźmy, że odwołanie

do zmiennej należącej do nowej

sekcji, np:

volatile int Page2 __attribute__((sec-

tion(„.page2”)));

...................

Page2=0x55;

traﬁa pod zadeklarowany przez nas

w skrypcie adres:

13c: 85 e5 ldi r24, 0x55 ; 85

13e: 90 e0 ldi r25, 0x00 ; 0

140: 90 93 01 03 sts 0x0301, r25

144: 80 93 00 03 sts 0x0300, r24

Klasyﬁkator volatile jest w przy-

padku obsługi zewnętrznych urzą-

dzeń szczególnie istotny – często

mamy do czynienia z sekwencyjnym

zapisem lub odczytem danych lub

nastaw konﬁguracyjnych – bez vo-

latile optymalizator może nam wie-

le z tych operacji całkiem pominąć

czego skutkiem będzie błędne (lub

brak) działanie układu. Taki bezpo-

średni dostęp przez wskaźniki zo-

stał zastosowany w testowym ukła-

dzie ATmega 8515 + 62256 dla

sprawdzenia poprawności podłącze-

nia i działania pamięci:

bool CheckRam(void)

{

bool chkcell;

chkcell=true;

uint i,k;

k=(uint)RAMEND + 0x8000;

for (i=RAMEND+1;i<=k;i++)

{

*((uchar*)i)=0xa5;

}

for (i=RAMEND+1;i<=k;i++)

{

if (*((uchar*)i) != 0xa5)

{

chkcell = false;

break;

}

for (i=RAMEND+1;i<=k;i++)

{

*((uchar*)i)=0x5a;

}

Jednak po bliższym przyjrze-

niu się rezultatom naszych poczy-

nań stwierdzimy, że niezbędne będą

pewne poprawki. Otóż zawartość tak

utworzonych sekcji (wartości począt-

kowe – także zerowe – zmiennych

przypisanych do sekcji) jest dołącza-

na do pliku wynikowego ( hex ) pro-

gramu. Pamiętamy, że w przypadku

domyślnej sekcji . data jest to za-

mierzone i pozwala na stosowanie

zmiennych inicjalizowanych. Nato-

miast dla dodatkowych sekcji RAM

nie jest już tak idealnie.

Po pierwsze: mechanizm samo-

czynnej inicjalizacji (i zerowania)

nie będzie (bez modyﬁkacji znacz-

nie głębszych niż nasza) działać

dla sekcji dodatkowych (chociaż

kompilator nie zgłosi żadnego błę-

du). Musimy więc samodzielnie

inicjalizować każdą zmienną (także

wartością zerową). Akurat w przy-

padku komunikacji z urządzeniem

zewnętrznym nie jest to żadną

wadą, a staje się wręcz zaletą: le-

piej unikać wszelkich samoczyn-

nych zapisów do urządzenia gdyż

może to przynieść niespodziewane

rezultaty. Taka sama korzyść wystą-

pi przy obsłudze pamięci nieulot-

for (i=RAMEND+1;i<=k;i++)

{

if (*((uchar*)i) != 0x5a)

{

chkcell = false;

break;

}

return chkcell;

}

Potencjalne zagrożenie stwarza

przy takim bezpośrednim dostę-

pie fakt, że linker nic nie „wie”

o niezależnym wykorzystaniu przez

nas niektórych adresów pamięci

i w związku z tym może je przy-

dzielić zmiennym. Jeśli zachodzi

potrzeba musimy więc sami odpo-

wiednio poprzesuwać sekcje pamię-

ci, aby zapobiec takiej kolizji. Man-

kament ten jest w znacznej mierze

110

Elektronika Praktyczna 4/2006

K U R S

nych (NVRAM, FRAM) gdyż wszel-

ka inicjalizacja zniszczyłaby ich po-

przednią zawartość.

Po drugie (gorsze): wpis do pliku

hex zachowuje adresy z przesunię-

ciem 0x800000, czyli poza zakresem

wszelkiej pamięci ﬂash . Może to

prowadzić do zakłócenia działania

nie przygotowanych na taką ewentu-

alność programatorów i w konsekwen-

cji do niemożności zaprogramowania

kostki posiadanym sprzętem.

Z powyższego wynika natych-

miast, że nasze dodatkowe sekcje

muszą być koniecznie wyelimino-

wane z pliku wynikowego. Reali-

zuje się to bardzo prosto poprzez

modyﬁkację wywołania avr–objcopy

konwertującego wybrane elementy

pliku obiektowego elf do pliku hex .

Sprawa staje się jednak utrudniona

jeśli z poziomu używanego IDE nie

mamy dostępu do zmiany potrzeb-

nych opcji. Niestety także AvrSide

nie jest obecnie wyposażone w ża-

den mechanizm zarządzania sek-

cjami pamięci i brak możliwości

zmiany domyślnej postaci linii ko-

mendy dla avr–objcopy .

Na szczęście jest inny sposób

rozwiązania problemu: poinstruowa-

nie linkera, aby dodatkowych sek-

cji w ogóle nie umieszczał w pliku

obiektowym elf . Jeśli stosujemy od-

dzielny skrypt wystarczy wyposa-

żyć opis sekcji w atrybut NOLOAD

(w podanym powyżej przykładzie

będzie to . page2 (NOLOAD): ). Wy-

konanie zadania z poziomu opcji

wywołań linkera jest nieco bardziej

skomplikowane:

– nazwę sekcji rozpoczynamy od

frazy . noinit , w naszym przykła-

dzie może to byc np. . noinit_ext-

sec , jest to równoznaczne z usta-

wieniem atrybutu NOLOAD

– wywołanie linkera uzupełnia-

my opcją –unique=”noinit_ext-

sec” nakazującą utworzenie

całkiem oddzielnej sekcji, bez

tego nasza . noinit_extsec zosta-

nie domyślnie dołączona (bez

zwracania uwagi na adres star-

towy) do podstawowej sekcji.

noinit (linia dodatkowych opcji

na rys. 35 będzie więc w koń-

cu wyglądać tak: –section–start,.

noinit_extsec=0x800260, –uniqu-

e=”.noinit_extsec”) .

Teraz dodatkowe sekcje skonﬁ-

gurowane są już całkowicie zgod-

nie z oczekiwaniami.

Wszystkie powyżej omówione

metody dostępu do RAM zakładają

przydzielenie na

stałe adresów

zmiennych już

na etapie linko-

wania. Avr–gcc

daje nam do

dyspozycji do-

datkowo możli-

wość dynamicz-

nego wykorzysta-

nia pamięci.

F u n k c j a

v o i d * m a l -

loc (size_t __size) (moduł stdlib )

zwraca nam wskaźnik na przy-

dzielony obszar pamięci o roz-

miarze __size bajtów (ewentualnie

NULL jeśli operacja się nie po-

wiedzie). Obszar nie jest inicjali-

zowany (jego zawartość pozostaje

przypadkowa).

Funkcja void* realloc (void* ptr,

size_t __size) zmienia rozmiar przy-

dzielonego pod adresem ptr obsza-

ru na nową wielkość __size (w ra-

zie konieczności przeniesienia ca-

łego obszaru w inne wolne miejsce

zwraca nowy wskaźnik).

Funkcja void* calloc (size_t __

nele, size_t __size) przydziela obszar

na __nele elementów o rozmiarze _

_size (czyli __nele * __size bajtów).

Przy tym zawartość obszaru zostaje

wyzerowana.

Funkcja void free (void* ptr)

zwalnia przydzielony pod adresem

ptr obszar i umożliwia jego ponow-

ne wykorzystanie.

Domyślnie na obszar dynamicz-

nej alokacji pamięci (czyli stertę,

heap ) przeznaczona jest przestrzeń

pomiędzy omawianymi wcześniej

automatycznymi sekcjami, a stosem

( rys. 36 – zaczerpnięty z dokumen-

tacji avr–libc ).

Podczas każdej nowej alokacji

sprawdzany jest bieżący wskaźnik

stosu. Po zmniejszeniu o margines

bezpieczeństwa ( __malloc_margin ,

domyślnie 32 bajty) stanowi ogra-

niczenie dla wielkości alokowane-

go obszaru (koniec sterty jest opi-

sany wewnętrzną zmienną brkval ).

Zabezpiecza to przed nałożeniem

się sterty i stosu w trakcie dalsze-

go działania programu. Oczywiście

może się zdarzyć, że przy wielo-

krotnych zagnieżdżeniach lub dużej

ilości zmiennych lokalnych w funk-

cjach stos rozszerzy się bardziej

niż zakładaliśmy, jednak zmienna

__malloc_margin jest udostępniona

jako globalna i możemy ją skorygo-

wać według potrzeb.

W tak ciasnym środowisku sto-

sowanie dynamicznej alokacji jest

raczej problematyczne (co zresztą

podkreślają sami autorzy avr–libc).

Nie zwiększy nam ona w cudowny

sposób brakującej pamięci RAM.

Jednak stertę – podobnie jak

wszelkie inne sekcje – możemy

przenieść do pamięci zewnętrznej.

W tym celu odpowiednio deﬁniu-

jemy symbole __heap_start oraz __

heap_end w opcjach wywołania lin-

kera, albo zamiennie (co jest chyba

trochę wygodniejsze) samodzielnie

inicjalizujemy w programie zmien-

ne __malloc_heap_start i __malloc_

heap_end . Pamiętajmy przy tym, że

sama zmiana początku sterty nie

wystarcza, jej koniec także musi

zostać ustawiony (domyślna wartość

zero zmiennej __malloc_heap_end

jest interpretowana jako położenie

sterty poniżej stosu co doprowadzi

do sprzeczności).

W przykładowym programie wy-

gląda to np. tak:

– inicjalizacja sterty:

#deﬁne HEAP_START 0x4000

#deﬁne HEAP_END 0x8000+RAMEND

void InitHeap(void)

{

__malloc_heap_start=(char*)HE-

AP_START;

__malloc_heap_end=(char*)HEAP_END;

}

– zaalokowanie obszaru 10000 baj-

tów i jego wyzerowanie:

volatile char *Ptab100;

Ptab100 = calloc(10000,1);

– i zapisy do różnych miejsc alo-

kacji:

*(Ptab100 + 99) = 20;

*(Ptab100 + 102) = 30;

Operacje te łatwo prześledzimy

w oknie podglądu pamięci AvrStudio.

Jerzy Szczesiul, EP

jerzy.szczesiul@ep.com.pl

UWAGA!

Środowisko IDE dla AVR–GCC

opracowane przez autora artykułu

można pobrać ze strony

http://avrside.ep.com.pl.

Elektronika Praktyczna 4/2006

111

Rys. 36. Lokalizacja sterty w wewnętrznej pamięci RAM

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: