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

K U R S

AVR-GCC: kompilator C

mikrokontrolerów AVR, część 2

Kontynuujemy cykl artykułów, których zadaniem jest przedstawienie podstaw

oraz praktycznych zasad programowania mikrokontrolerów AVR w języku C

z użyciem kompilatora avr-gcc. Oczywiście wybór kompilatora AVR-GCC może

się jednym podobać, a innym nie. Postaramy się jednak uzasadnić, że nie

jest to zły wybór.

Środowisko avrside

Uproszczone zintegrowane środo-

wisko programistyczne ( Avr S -imple

I -ntegrated D -evelopment E -nviron-

ment) powstało właśnie w celu ła-

twego rozpoczęcia nauki programo-

wania mikrokontrolerów AVR Atmela

z użyciem avr-gcc w systemie Win-

dows. Zawiera edytor kodu źródło-

wego z kolorowaniem składni oraz

systemem podpowiedzi i wyszukiwa-

nia. Pozwala na wygodne ustawianie

w oknie dialogowym podstawowych

opcji kompilacji. Uruchamia - po-

dobnie jak make - kolejno potrzeb-

ne podprogramy avr-gcc i raportuje

ewentualne błędy wykonania z moż-

liwością ich lokalizacji w kodzie

źródłowym. Jednocześnie zaś umoż-

liwia dokładne zapoznanie się z wy-

wołaniami avr-gcc i wynikiem pracy

kompilatora, z czego będziemy na

bieżąco korzystać.

Szczegóły obsługi AvrSide najle-

piej chyba będzie objaśniać w trak-

cie realizacji kolejnych przykładów.

Na początek warto jednak spojrzeć -

podobnie jak w przypadku avr-gcc -

na strukturę katalogów programu aby

nie stanowił on tajemniczej „czarnej

skrzynki”. Drzewo katalogów (doty-

czące instalacji AvrSide we własnym

niezależnym od WinAvr folderze) jest

przedstawione na rys. 3 .

W podkatalogu [ bin ] umieszczo-

ny jest plik wykonawczy AvrSide.exe

oraz pliki konfiguracyjne:

– desktop.cfg - zapis ogólnej konfi-

guracji środowiska (np. położenie

i rozmiar okien),

– autocpl.cfg - plik tekstowy szablo-

nów autokompletacji kodu,

– libfunc.cfg - plik tekstowy auto-

kompletacji funkcji avr-libc,

– ftd2xx.dll - dodatkowo biblioteka

FTDI niezbędna do uruchomienia

AvrSide jeśli nie mamy w sys-

temie zainstalowanego sterownika

direct dla układów Ft8uxx.

W podkatalogu [ dev ] przechowy-

wane są pliki *.pdf firmowej doku-

mentacji mikrokontrolerów. Nazwane

są zgodnie z typem mikrokontrolera

ustalonym w AvrSide, co pozwala

na ich otwieranie z poziomu menu

pomocy programu.

Dalej widzimy omówione wcze-

śniej foldery kompilatora avr-gcc w

różnych wersjach. Folder [ isp ] zawie-

ra pliki programatora AvrProgrammer

Adama Dybkowskiego. Foldery [ My-

inc ] oraz [ MyLib ] są przeznaczone na

własne - bardziej uniwersalne i sto-

sowane w większej liczbie projektów

- pliki nagłówkowe oraz biblioteki.

Folder [ Projects ] grupuje podkata-

logi (a także drzewa podkatalogów)

poszczególnych projektów. Każdy

nowy projekt powinien być zakłada-

ny w oddzielnym podkatalogu (np.

\Projects\Nowy_projekt ) lub drzewie

(np. \Projects\Kurs\Przyklad_01 ). Ta-

kie rozwiązanie umożliwia zacho-

wanie porządku i przejrzystości we

własnych archiwach projektowych, a

także umożliwia korzystanie z wbu-

dowanej przeglądarki projektów.

W każdym subfolderze projektu

zapisujemy pliki źródłowe ( *.c , *.s

oraz *.h ) oraz plik konfiguracji pro-

jektu ( nazwa_projektu.gcp ) określający

wszystkie opcje, ustawienia, ścieżki

itp. użyte w projekcie. W tym sa-

mym subfolderze powstają wspo-

mniane wcześniej pliki wynikowe

działania kompilatora. W głównym

folderze [ Projects ] znajdziemy też

plik lastwork.cfg zapisujący dane pro-

jektu używanego w chwili zamykania

AvrSide (co pozwala na natychmia-

stowe przywrócenie środowiska pracy

podczas ponownego uruchomienia)

oraz - tylko w przypadku używania

AvrProgrammera - pliki eeprom.hex i

flash.hex wykorzystywane przez ten

programator.

Foldery [ Freaks ] i [ Notes ] nie są

bezpośrednio związane z AvrSide

ani avr-gcc - przechowuję tam róż-

ne notatki, noty aplikacyjne, wypisy

z forum i listy avr-gcc itp. - w ten

sposób nie „rozbiega” mi się to po

całym dysku.

Tworzymy pierwszy testowy projekt

Po zainstalowaniu wszystkich

wcześniej wymienionych składników

na dysku pora na wypróbowanie

działania środowiska. Wszystkie przy-

taczane przykłady dotyczą AvrSide

ulokowanego w folderze c:\AvrSide i

korzystającego z wersji avr-gcc z sub-

Rys. 3. Struktura folderów AvrSide

Rys. 4. Opcje ustawień ekranowych

AvrSide

Elektronika Praktyczna 4/2005

K U R S

Rys. 5. Opcje ustawień konfiguracji

plików wynikowych i typu mikrokon-

trolera

jakimkolwiek managerze plików);

– przejdźmy do [ Przyklad-01 ] na-

zwijmy plik main.c (rozszerzenie

jest dodawane domyślnie) i po-

twierdźmy; okno zapisu przełączy

się samoczynnie na zachowywa-

nie projektu - nazwijmy go np.

Test01 i zapiszmy;

– nasze nazwy zostały wprowadzone

do projektu: plik na zakładce ( tab )

edytora, a projekt na belce tytu-

łowej okna (w managerze plików

możemy też od razy sprawdzić

poprawność zapisu - subfolder

\Projects\Kurs\Przyklad-01 powinien

zawierać dwa pliki: main.c oraz

Test01.gcp );

– nazwy oczywiście możemy wy-

brać dowolnie, jedynym ograni-

czeniem jest aby plik projektu

*. gcp nie nazywał się tak samo

jak jakikolwiek plik źródłowy,

gdyż spowoduje to nadpisywanie

plików wynikowych listingu.

Zanim ruszymy dalej z kompila-

cją zajmijmy się przez chwilę skonfi-

gurowaniem środowiska oraz ustawie-

niem opcji projektu. Okno główne

umieszczamy na ekranie według po-

trzeb - jego pozycja będzie odtąd na

stałe zapamiętana we wspomnianym

wcześniej pliku ogólnej konfiguracji

desktop.cfg . Następnie wybieramy z

menu komendę „Projekt>>Ustawie-

nia” i przełączamy widok kolejno na

potrzebne pozycje:

1. „Ekran” ( rys. 4 ) - tutaj ustawimy

sobie:

– kolory i style dla podswietla-

nych elementów składni kodu

źródłowego (wybieramy w

prawym panelu posługując się

typowymi windowsowymi kon-

trolkami);

– rodzaj i wielkość czcionki

oraz kolor tła dla głównych

okienek AvrSide (edytor, ko-

munikaty błędów oraz podgląd

asemblera); używamy do tego

kontekstowego menu (prawy-

-klik) trzech małych paneli po

lewej stronie;

– wygląd menu głównego (trady-

cyjny lub zgodny z XP);

– rozmiar czcionki w generowa-

nym kodzie HTML;

– ustawienia dotyczą naszego

pojedynczego projektu, jeśli

chcemy ich używać w każ-

dym nowym projekcie zapisz-

my je jako domyślne (w desk-

top.cfg ) przy pomocy przycisku

DEF>> (podobnie przyciskiem

DEF<< możemy później przy-

wrócić ustawienie domyślne w

dowolnym inaczej skonfiguro-

wanym projekcie);

2. „Ścieżki” - tu na razie ustawia-

my tylko „namiar” na pliki wy-

konawcze narzędzi kompilatora,

w naszym przykładzie będzie to

C:\AvrSide\gcc-3.4.2-2.15-1.0.4\bin

(jeśli zrobimy błąd i AvrSide nie

znajdzie kompilatora zgłosi to

przy próbie kompilacji);

3. „AvrSide” - wyłączmy na ra-

zie opcję „Samoczynnie zamykaj

okno postępu kompilacji”, będzie

to pomocne w zapoznaniu się

z przebiegiem kompilacji; pozo-

stałe opcje można zostawić jako

domyślne (starsze PC mogą tak-

że wymagać wyłączenia opcji

„Fast reading” co umożliwi pracę

z małym RAM-em, ale kosztem

szybkości działania);

4. „Wyjście” ( rys.5 ) - większość po-

zycji pozostawiamy na razie jako

domyślne, sprawdźmy tylko czy

są zaznaczone opcje: „Zbiorczy

listing projektu” i „Debug format

- dwarf-2”.

Opcje kompilatora i linkera pozo-

stawiamy bez zmian (będą oczywi-

ście przedstawiane bardziej szczegó-

łowo w dalszych przykładach).

Po zamknięciu dialogu opcji mo-

żemy zapisać zmiany w projekcie

(„Projekt>>Zapisz projekt”) ale nie

jest to bezwzględnie konieczne gdyż

zostaną samoczynnie zachowane przy

przełączaniu projektu albo zamknię-

ciu AvrSide.

Po tych wszystkich wstępnych

czynnościach możemy wreszcie wy-

próbować działanie kompilatora.

Skrót klawiaturowy F9 spowodu-

je wykonanie niezbędnego szeregu

operacji (jest to odpowiednik pozy-

cji menu „Projekt>>Make” - jednak

nazwa ta nie ma nic wspólnego z

klasycznym programem make ), po-

kazanych w oknie postępu (celowo

wyłączyliśmy jego samoczynne za-

mykanie aby je sobie spokojnie obej-

rzeć) - rys. 6 .

folderu \AvrSide\gcc-3.4.2-2.15-1.0.4 ,

bez użycia pakietu WinAvr. Należy

je więc każdorazowo dopasować do

ustawionych u siebie lokalizacji.

Podczas pierwszego uruchomienia

AvrSide otwiera w domyślnym poło-

żeniu okno pustego projektu NONA-

ME z pojedynczą zakładką pustego

pliku źródłowego NoName. Wywo-

łajmy skrótem Ctrl + J wykaz szablo-

nów kodu i wybierzmy „ mainmod

- szablon modułu głównego” - zosta-

nie wpisany najprostszy, podstawowy

program z pustą pętlą:

// główny moduł projektu

#deﬁne _MAIN_MOD_ 1

// pliki dołączone (include):

// dane:

// funkcje:

/====================

// funkcja main()

int main(void)

{

// inicjalizacja

// pętla główna

while (1)

{

}

Teraz od razu wybierzmy lokali-

zację i nazwijmy plik oraz projekt:

– z menu „Plik” wybieramy komen-

dę „Zapisz” albo „Zapisz jako”

(w przypadku nowego pliku są

one równoważne);

– w typowym windowsowym

oknie dialogowym zapisywa-

nia pliku otwartym na folde-

rze [ Projects ] tworzymy nowy

podkatalog [ Kurs ] a w nim ko-

lejny subfolder [ Przyklad-01 ]

(używamy zwykłych narzędzi

Windows czyli menu kontekstowe-

go, możemy też jednak przygoto-

wać sobie te foldery wcześniej w

Rys. 6. Wynik kompilacji przykłado-

wego projektu

Rys. 7. Okno konfiguracyjne sesji

debuggera w AvrStudio

Elektronika Praktyczna 4/2005

K U R S

Jeśli teraz przełączymy się do ma-

nagera plików znajdziemy w folderze

naszego projektu szereg nowych pli-

ków utworzonych w trakcie działania

kompilatora (sięgnijmy do rys. 1):

– main.o: plik relokowalny modułu

main.c,

– Test01.hex: plik wynikowy kodu

programu ( flash ),

– Test01.map: plik informacyjny

konsolidatora,

– Test01.lst: plik assemblerowego li-

stingu całego projektu,

– Test01.elf: plik obiektowy projektu,

– Test01.smb: wykaz symboli uży-

tych w projekcie,

– Test01.txt: rejestracja komend wy-

konanych w trakcie kompilacji.

Zauważmy, że nie ma tu pliku

pośredniego main.s - dla przyśpiesze-

nia działania nie jest on zapisywany

na dysku, a powstaje w chwilowym

buforze pamięci operacyjnej. Pliki re-

lokowalne *.o zachowują nazwy od-

powiadających modułów źródłowych,

natomiast zbiorczym plikom wyniko-

wym AvrSide nadaje nazwę projektu

z odpowiednim rozszerzeniem.

W ostatnim z plików - Test01.txt

- znajdziemy zapis kolejnych ko-

mend kompilatora odpowiadających

pozycjom okienka postępu. Nie bę-

dziemy się w nie teraz na początku

zagłębiać, ale wykorzystamy ten plik

wielokrotnie podczas dalszego pozna-

wania avr-gcc.

Z punktu widzenia elektroni-

ka - konstruktora najważniejszy jest

oczywiście plik kodu *.hex , który za

pomocą dowolnego programatora ła-

dujemy do mikrokontrolera. Odłóżmy

to jednak na nieco później i naj-

pierw obejrzyjmy trochę dokładniej

wygenerowany kod. Skorzystamy w

tym celu z wbudowanych udogod-

nień AvrSide. Skrót klawiaturowy F7

otworzy nam okno podglądu kodu

asm odtworzonego („zdeasemblowane-

go”) z pliku relokowalnego bieżącego

modułu (u nas mamy tylko jeden -

main.o). Widzimy następującą treść

(sekcja .text określa obszar pamięci

programu Flash ):

main.o: ﬁle format elf32-avr

Disassembly of section .text:

00000000 <main>:

/====================

// funkcja main()

int main(void)

{

0: c0 e0 ldi r28, 0x00 ; 0

2: d0 e0 ldi r29, 0x00 ; 0

4: de bf out 0x3e, r29 ; 62

6: cd bf out 0x3d, r28 ; 61

// inicjalizacja

// pętla główna

while (1)

8: ff cf rjmp .-2 ; 0x8

Funkcja main() ustawia na sa-

mym początku wskaźnik stosu (re-

jestry 0x3e,0x3d - na etapie pliku

relokowalnego nie są jednak jeszcze

wstawiane konkretne wartości) i od

razu przechodzi do pustej nieskoń-

czonej pętli while (1) .

Jednak coś się tu nie zgadza: ten

kod ma najwyżej kilka bajtów dłu-

gości, a wynik kompilacji na pasku

statusu pokazał nam 102 bajty. Aby

znaleźć różnicę zajrzyjmy do pliku

Test01.lst, który zawiera ostateczny

kod po zakończeniu konsolidacji (do

tego posłuży nam skrót Ctrl + F7 ):

Test01.elf: ﬁle format elf32-avr

Disassembly of section .text:

00000000 <__vectors>:

0: 12 c0 rjmp .+36 ; 0x26

2: 2b c0 rjmp .+86 ; 0x5a

4: 2a c0 rjmp .+84 ; 0x5a

6: 29 c0 rjmp .+82 ; 0x5a

8: 28 c0 rjmp .+80 ; 0x5a

a: 27 c0 rjmp .+78 ; 0x5a

c: 26 c0 rjmp .+76 ; 0x5a

e: 25 c0 rjmp .+74 ; 0x5a

10: 24 c0 rjmp .+72 ; 0x5a

12: 23 c0 rjmp .+70 ; 0x5a

14: 22 c0 rjmp .+68 ; 0x5a

16: 21 c0 rjmp .+66 ; 0x5a

18: 20 c0 rjmp .+64 ; 0x5a

1a: 1f c0 rjmp .+62 ; 0x5a

1c: 1e c0 rjmp .+60 ; 0x5a

1e: 1d c0 rjmp .+58 ; 0x5a

20: 1c c0 rjmp .+56 ; 0x5a

22: 1b c0 rjmp .+54 ; 0x5a

24: 1a c0 rjmp .+52 ; 0x5a

00000026 <__ctors_end>:

26: 11 24 eor r1, r1

28: 1f be out 0x3f, r1 ; 63

2a: cf e5 ldi r28, 0x5F ; 95

2c: d4 e0 ldi r29, 0x04 ; 4

2e: de bf out 0x3e, r29 ; 62

30: cd bf out 0x3d, r28 ; 61

00000032 <__do_copy_data>:

32: 10 e0 ldi r17, 0x00 ; 0

34: a0 e6 ldi r26, 0x60 ; 96

36: b0 e0 ldi r27, 0x00 ; 0

38: e6 e6 ldi r30, 0x66 ; 102

3a: f0 e0 ldi r31, 0x00 ; 0

3c: 02 c0 rjmp .+4 ; 0x42

0000003e <.do_copy_data_loop>:

3e: 05 90 lpm r0, Z+

40: 0d 92 st X+, r0

00000042 <.do_copy_data_start>:

42: a0 36 cpi r26, 0x60 ; 96

44: b1 07 cpc r27, r17

46: d9 f7 brne .-10 ; 0x3e

00000048 <__do_clear_bss>:

48: 10 e0 ldi r17, 0x00 ; 0

4a: a0 e6 ldi r26, 0x60 ; 96

4c: b0 e0 ldi r27, 0x00 ; 0

4e: 01 c0 rjmp .+2 ; 0x52

00000050 <.do_clear_bss_loop>:

50: 1d 92 st X+, r1

00000052 <.do_clear_bss_start>:

52: a0 36 cpi r26, 0x60 ; 96

54: b1 07 cpc r27, r17

56: e1 f7 brne .-8 ; 0x50

58: 01 c0 rjmp .+2 ; 0x5c

0000005a <__bad_interrupt>:

5a: d2 cf rjmp .-92 ; 0x0

0000005c <main>:

/====================

// funkcja main()

int main(void)

{

5c: cf e5 ldi r28, 0x5F ; 95

5e: d4 e0 ldi r29, 0x04 ; 4

60: de bf out 0x3e, r29 ; 62

62: cd bf out 0x3d, r28 ; 61

// inicjalizacja

// pętla główna

while (1)

64: ff cf rjmp .-2 ; 0x64

Teraz zgadza się wszystko: ostat-

ni bajt kodu ma adres 0x65=101

- przy numeracji od zera długość

wynosi 102 (przy okazji zauważmy,

że gcc stosuje adresowanie bajtowe

w przeciwieństwie do notacji Atme-

la używającej adresów dwubajtowych

słów - dlatego adresy podawane w

notach i dokumentacjach należy dla

potrzeb avr-gcc mnożyć przez dwa).

Dodatkowy kod spełnia kilka zadań

związanych z inicjalizacją pracy pro-

gramu (będziemy później wracać do

tego tematu bardziej szczegółowo):

1. Sekcja <__vectors> ustawia obszar

wektorów przerwań odpowiedni

dla użytej kostki. Przerwanie pod

adresem 0x0 (czyli reset) zawiera

skok na koniec obszaru wektorów.

Pozostałe wektory domyślnie (o

ile nie została zdefiniowana ob-

sługa danego przerwania) wskazu-

ją na błędne przerwanie.

2. Sekcja <__ctors_end> kończy ob-

szar wektorów - w tym miejscu

„ląduje” skok z przerwania spo-

wodowanego resetem. Sekcja wy-

konuje kilka dodatkowych czyn-

ności: zeruje rejestr r1 (co jest

wymagane przez standard wyko-

rzystywania rejestrów w avr-gcc),

zeruje rejestr stanu i ustawia re-

jestry stosu (zauważmy, że stos

jest zatem ustawiany dwukrotnie

- jest to jakaś „zaszłość rozwo-

jowa” kompilatora, która będzie

prawdopodobnie usunięta w dal-

szych wersjach).

3. Sekcje <__do_copy_data_xx> służą

do załadowania wartościami zmien-

nych, które w programie zdefinio-

waliśmy jako zainicjalizowane.

4. Sekcje <__do_clear_bss_xx> służą

z kolei do wyzerowania wszystkich

zmiennych nie zainicjalizowanych

(które w standardzie C muszą

mieć domyślnie wartość zero).

5. Sekcja <__bad_interrupt> stanowi

(jak wspomniano wyżej) domyśl-

ną obsługę błędnego przerwania,

jest to po prostu skok pod adres

zero czyli na początek programu.

Cały ten blok kodu jest zawar-

ty w relokowalnych plikach crtxx.o

umieszczonych w podkatalogu (wróć-

my do rys. 2) \avr\lib\ kompilatora.

Komenda wywołania konsolidatora:

avr-gcc.exe -mmcu=atmega8 -Wl,-

-Map= Test01.map ,--cref -o Test01.elf

main.o

(znajdziemy ją we wspominanym

już pliku Test01.txt ) zawiera w sobie

obowiązkowo opcję typu procesora. Na

tej podstawie konsolidator dołącza od-

powiedni plik crtxx.o oraz wybiera od-

powiedni skrypt (ze skryptu pochodzi

m.in. docelowa wartość rejestru stosu:

0x45F, która - jak łatwo sprawdzić w

dokumentacji Atmega 8 - odpowiada

końcowi obszaru pamięci SRAM).

Elektronika Praktyczna 4/2005

K U R S

Obecność bezparametrowej funk-

cji main(void) wynika z zasad języ-

ka C - każdy program musi ją mieć

jako podstawową „ramkę” obejmują-

cą wszystkie wewnętrzne działania.

Jednak aplikacja działająca w małym

mikrokontrolerze będzie się dość

istotnie różnić od „zwykłego” pro-

gramu komputerowego. Taki program

jest uruchamiany przez system ope-

racyjny, zakończenie funkcji main()

jest równoznaczne z zakończeniem

programu i powrotem do systemu.

Wstawienie takiej jak u nas zamknię-

tej pętli jest kardynalnym błędem,

gdyż uniemożliwia wyjście z main()

co jest równoznaczne z „zawiesze-

niem się” aplikacji. Zapis musi wy-

glądać nieco inaczej (zazwyczaj wsta-

wimy jeszcze jakieś oczekiwanie na

klawisz, żeby zamknięcie nie nastą-

piło natychmiast):

int main(void)

{ return 0; }

Natomiast w atmedze oczywiście

nie ma żadnego nadrzędnego sys-

temu operacyjnego, któremu moż-

na przekazać sterowanie. Wyjście z

funkcji main() spowoduje po prostu

opuszczenie obszaru kodu programu

i utratę kontroli nad mikrokontrole-

rem - czyli znów kardynalny (cho-

ciaż zupełnie innej natury) błąd.

Spróbujmy skompilować nasz test

w takiej wersji. W kodzie wyniko-

wym czeka nas miła niespodzianka:

int main(void)

{

5c: cf e5 ldi r28, 0x5F ; 95

5e: d4 e0 ldi r29, 0x04 ; 4

60: de bf out 0x3e, r29 ; 62

62: cd bf out 0x3d, r28 ; 61

// inicjalizacja

// pętla główna

//while (1)

//{

//}

return 0;

}

64: 80 e0 ldi r24, 0x00 ; 0

66: 90 e0 ldi r25, 0x00 ; 0

68: 00 c0 rjmp .+0 ; 0x6a

0000006a <_exit>:

6a: ff cf rjmp .-2 ; 0x6a

Jak widać avr-gcc przewidział

taką sytuację i samoczynnie (po

zwrocie w rejestrach r25,r24 dekla-

rowanej wartości zero) dodał sekcję

<_exit>, która znów jest zamkniętą

pętlą. Oczywiście mikrokontroler „za-

niemówi” w oczekiwaniu na reset,

niemniej jego zachowanie pozostaje

całkowicie przewidywalne.

Zwróćmy przy okazji uwagę, że w

wersji „atmegowej” kompilator uwzględ-

nia fakt nie opuszczania main() i nie

generuje ostrzeżenia o braku zwracanej

wartości ( control reaches end of non-

-void function ) nawet jeśli pomijamy

końcową instrukcję return.

Powyższy przykład wskazuje też

na konieczność zachowania dodatkowej

ostrożności przy stosowaniu „peceto-

wych” umiejętności programowania w

C dla potrzeb mikrokontrolerów - cały

czas trzeba mieć świadomość, że prze-

nosimy się do środowiska o radykalnie

innych możliwościach i wymaganiach.

Pojawi się niechybnie wątpliwość,

czy tak długi kod dla „nic-nie-robiącego”

programu nie jest marnowaniem cennej

pamięci Flash mikrokontrolera? No cóż

- zawsze trzeba jakoś zapłacić za wygo-

dę i standaryzację. Poza tym - pisząc w

C będziemy i tak sięgać raczej po kost-

ki o większych możliwościach aby nie

przejmowac się ograniczonymi zasoba-

mi. Dla przykładowej ATmega8 inicjali-

zacja zajmuje ok. 1% dostępnej pamięci

programu, co jest wartością nieznaczną.

Dla Atmega128 z 16-krotnie większym

Flashem jest to już zupełnie pomijalne.

Natomiast w ATtiny13 z 1 kB programu

oraz 64 B SRAM rzeczywiście C może

się zachowywać jak przysłowiowy słoń

w składzie porcelany. W tym przypad-

ku wybór narzędzia (C czy asm) będzie

podyktowany rzeczywistymi wymagania-

mi naszej konkretnej aplikacji.

też sobie pasujący układ okien i sche-

mat kolorowania składni.

Jeśli teraz zamkniemy AvrStudio

parametry sesji zostaną zachowane w

pliku Test01_elf.aps (ulokowanym w fol-

derze naszego projektu), który posłuży

do jej samoczynnego wznawiania. Po-

nowne użycie F11 z poziomu AvrSide

spowoduje uruchomienie AvrStudio od

razu z naszym projektem (w zależności

od wydajności sprzętu może to chwilę

potrwać). Natomiast przy działającym

już Studiu efektem będzie po prostu

przywołanie jego okna. Warto poświę-

cić chwilę czasu na przejrzenie możli-

wości, opcji i „klawiszologii” AvrStudio

- to znakomicie ułatwi później analizę

kolejnych przykładów.

Należy jednak cały czas mieć na

uwadze, że najnowsze wersje AvrStudio

wyposażone w możliwość bezpośrednie-

go odczytu plików *.elf (z pominięciem

dodatkowych konwersji elf >> coff, któ-

re zawsze były piętą achillesową współ-

pracy z avr-gcc) są cały czas rozwijane

i dopracowywane - mogą się więc przy-

trafiać rozmaite błędy. Dlatego warto na

bieżąco sprawdzać czy nie pojawiły się

jakieś aktualizacje (chodzi głównie o po-

prawione wersje bibliotek, często przeka-

zywane poprzez forum avrfreaks).

Jeśli wszystko poszło bez proble-

mów, to mamy po tej części artykułu:

– przygotowane środowisko do tworze-

nia oraz symulacji i debugowania

projektów,

– wstępne rozeznanie jak są rozmiesz-

czone i jak współpracują jego po-

szczególne komponenty,

– orientację w typach plików używa-

nych w trakcie budowy projektu,

– podstawowe informacje o zasadach

działania kompilatora i uzyskiwanym

wynikowym kodzie.

Jerzy Szczesiul, EP

jerzy.szczesiul@ep.com.pl

Uruchamiamy sesję debuggera

Na koniec tego wstępnego rozdziału

sprawdźmy jeszcze jak działa AvrStudio

4.10 w roli symulatora i debuggera. Z

poziomu AvrSide po prostu wciskamy

F11 (albo używamy odpowiedniej ko-

mendy menu). Jednak za pierwszym

razem zamiast startu AvrStudio zostaje

wyświetlone okienko informacyjne ze

wskazówkami dalszego postępowania.

Zgodnie z nimi uruchamiamy ręcznie

AvrStudio z „pustą” sesją a następnie:

– otwieramy plik C:\AvrSide\Projects\

Kurs\Przyklad-01\Test01.elf ,

– w wyświetlonym oknie konfiguracji

( rys. 7 ) wybieramy platformę debu-

gera - AVR Simulator,

– oraz wybieramy typ układu - At-

mega 8 (może się zdarzyć, że

wybór układu jest zablokowany -

świadczy to o braku w systemie

odpowiedniej wersji parsera XML,

należy przeprowadzić update z

witryny Microsoftu - znajdziemy

o tym wzmiankę w opisie usterek

w pomocy AvrStudio).

Po chwili projekt zostanie załado-

wany i w oknie edycji pojawi się nasz

kod ze wskaźnikiem programu ustawio-

nym na funkcji main(). Nasz skrajnie

uproszczony projekt nie daje żadnych

praktycznych możliwości debugowania,

możemy jednak sprawdzić działanie:

startu i wstrzymania wykonywania, re-

setu oraz pracy krokowej. Wybierzmy

Niektóre przydatne linki

http://winavr.sourceforge.net - strona

domowa WinAvr

http://www.avrfreaks.net - największe forum

mikrokontrolerów AVR

http://www.atmel.com - firmowa strona

producenta AVR

http://www.nongnu.org/avr-libc/ - strona

domowa projektu avr-libc

http://gcc.gnu.org - strona główna

kompilatora gcc

http://sources.redhat.com/binutils/ - strona

narzędzi binutils

http://www.avrside.fr.pl - strona środowiska

AvrSide

http://www.avrside.ep.com.pl - strona

środowiska AvrSide

http://www.amwaw.edu.pl/~adybkows/elka/

ispprog.html - programator ISP LPT Adama

Dybkowskiego

Elektronika Praktyczna 4/2005

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: