AVR-GCC kompilator C dla mikrokontrolerów AVR.pdf

K U R S

AVR-GCC: kompilator C dla

mikrokontrolerów AVR, część 1

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

Zanim przejdziemy do konkretów

na początek kilka słów uzasadniają-

cych taki właśnie wybór narzędzi.

Po pierwsze: po co w ogóle ję-

zyk wysokiego poziomu skoro mikro-

kontrolery świetnie programuje się w

assemblerze, który daje pełną kontro-

lę nad kodem i zasobami procesora

i pozwala na uzyskanie maksymalnej

szybkości i zwięzłości? Otóż cały

problem leży w skali. W przypadku

małych układów z niewielkimi zaso-

bami, wykonujących niezbyt złożone

zadania (proste pomiary, sterowania

czy transmisje) asembler rzeczywi-

ście będzie całkowicie wystarczający

(a czasem wręcz niezastąpiony). Gdy

jednak program się nam rozrasta i

komplikuje (obróbka większych ilości

danych, bardziej złożone przeliczenia

i konwersje, zaawansowane algoryt-

my sterowania itp.), prędzej czy póź-

niej dochodzimy do progu, powyżej

którego nasze dzieło staje się coraz

mniej czytelne i coraz trudniejsze

do opanowania. Nagle stwierdzamy,

że dotychczasowe doświadczenia w

asemblerze to za mało żeby szybko

i skutecznie rozwiązać szerszy zakres

problemów (taka zresztą była w ogó-

le geneza stworzenia języków wyż-

szego poziomu). Tutaj przechodzimy

do drugiego pytania.

Po drugie: dlaczego właśnie C a

nie np. BASIC czy Pascal? Otóż C

był od początku projektowany jako

język możliwie maksymalnie zbliżony

do sprzętu i generujący kod niewie-

le odbiegający od samodzielnie pisa-

nego w asemblerze. W połączeniu z

optymalizatorem kodu (składnik każ-

dego dobrego kompilatora) pozwala

to na uzyskanie zaskakująco zwarte-

go, krótkiego i szybkiego programu

wynikowego. Oczywiście mamy rów-

nież możliwość dopisania w czystym

asemblerze fragmentów krytycznych

czasowo (jak np. obsługa przerwań)

jeśli nie zadowala nas kod genero-

wany automatycznie. W ten sposób

możemy bez problemu połączyć naj-

większe zalety obu sposobów progra-

mowania. Następna sprawa to prze-

nośność. Znaczne fragmenty kodu (a

szczególnie algorytmy, przeliczenia,

konwersje itp. - czyli elementy nie

korzystające bezpośrednio ze specy-

ficznych zasobów i interfejsów da-

nego mikrokontrolera) możemy łatwo

zastosować w programie dla zupeł-

nie innej kostki (praktycznie każda

rodzina mikrokontrolerów posiada

opracowany kompilator C - z inny-

mi językami nie jest tak dobrze). Tu

od razu przechodzimy do następnej

zalety C: rozpowszechnienia. C jest

od lat ogólnie przyjętym standardem

programowania z czym wiąże się

ogromna ilość dostępnych materia-

łów: bibliotek, przykładowych kodów,

opisów, tutoriali, gotowych rozwiązań

sprzętowo - programowych. W wielu

przypadkach wystarczy dobrze po-

szukać w zasobach sieciowych żeby

znaleźć prawie gotowe rozwiązania

własnych zadań programowych.

Po trzecie: dlaczego kompilator

avr-gcc (o którym krążą opinie, że

jest niewdzięczny i trudny w konfi-

guracji i obsłudze) a nie jakieś inne

rozpowszechnione narzędzie - jak np.

CodeVision czy ICC? Jednym z ko-

ronnych argumentów jest oczywiście

fakt, że avr-gcc jest bezpłatny. Ale

to nie wszystko: jest to narzędzie

dostępne dla wielu platform (więc

bez problemu możemy przenosić się

z naszymi projektami pomiędzy np.

Windows a Linuksem). Przy tym avr-

-gcc jest produktem open-source , z

czym wiąże się cały szereg udogod-

nień: mamy cały czas dostęp do naj-

nowszych uaktualnień, pełnej infor-

macji o wykrytych błędach, a także

do ogromnych zasobów bardziej lub

mniej zaawansowanego kodu two-

rzonych i oferowanych do swobod-

nego wykorzystywania, możemy też

cały czas liczyć na wsparcie i pod-

powiedzi na aktywnie działających

międzynarodowych forach, grupach

i listach. A w dodatku - jak zaraz

się przekonamy - przy użyciu do-

datkowych narzędzi wspomagających

avr-gcc staje się bardzo poręcznym i

wygodnym w użyciu instrumentem.

Można też dodać - już poza kontek-

stem stosowania w AVR - że gcc ma

wersje (tzw. porty) dla wielu innych

mikroprocesorów (np. MSP 430 czy

ARM) więc raz opanowany znacznie

ułatwi ewentualne „przesiadki”.

Jednak żeby nie wyglądało to jak

reklamowa laurka należy też powie-

dzieć o mankamentach. Główny z

nich to nie do końca „rozpracowana”

obsługa przez gcc nieciągłej prze-

strzeni adresowej AVR (dokładniej

omówimy to w trakcie prezentacji

przykładów). Zaleta jaką jest ciągły

rozwój gcc może też stać się wadą

w momencie wprowadzenia bardziej

radykalnych zmian wymagających

korekt we wcześniej działających

projektach. Czasem pojawiają się

drobniejsze błędy widoczne tylko w

specyficznych sytuacjach (być może

dlatego przeoczone w trakcie prac

Rys. 1. Przykładowy przebieg kompi-

lacji kodu źródłowego

Elektronika Praktyczna 3/2005

K U R S

Rys. 2. Struktura folderów kompilato-

ra avr-gcc

w środowisko programatora). Wymogi

sprzętowe nie są krytyczne - jednak

rzecz jasna szybkość i komfort pracy

będą mocno zależeć od mocy kom-

putera. Prototyp opisywanego zestawu

używany przy opracowaniu kursu zo-

stał uruchomiony na platformie Ath-

lon XP 2600+512 MB+Windows XP

Pro PL, która zapewniła rzeczywiście

wygodną i bezproblemową pracę.

Zauważmy, że nie ma na razie

mowy o żadnym współpracującym

układzie sprzętowym mikrokontrole-

ra - wrócimy do tego tematu nieco

później.

Skąd to wszystko wziąć? Ponie-

waż artykuły przygotowywane są ze

sporym wyprzedzeniem, a potrzebne

programy są wciąż rozwijane - naj-

lepiej sięgnąć do źródłowych witryn

projektów po najnowsze wersje. Avr-

Side znajdziemy na http://www.avrsi-

de.fr.pl albo na mirrorze http://www.

avrside.ep.com.pl. Instalujemy naj-

pierw podstawową wersję D5 a na-

stępnie zastępujemy plik wykonaw-

czy AvrSide.exe najnowszym dostęp-

nym. Aktualne szczegóły znajdziemy

w dołączonych opisach i bezpośred-

nio na w/w stronach.

AvrStudio (w chwili pisania w

wersji 4.10) jest udostępnione do

bezpłatnego pobrania z firmowej wi-

tryny Atmela http://www.atmel.com.

Trochę więcej zastanowienia wy-

maga sam kompilator avr-gcc. Sztan-

darową dystrybucją avr-gcc dla Win-

dows jest pakiet WinAvr Erica Wed-

dingtona. Jednak nie należy utożsa-

miać avr-gcc z WinAvr jak to jest

często w uproszczeniu podawane. Wi-

nAvr jest ogromnym zestawem wszel-

kich narzędzi open-source przydat-

nych w programowaniu AVR. Oprócz

aktualnej wersji avr-gcc znajdziemy

tam notatnik programisty wspomaga-

jący tworzenie projektów, symulator

simulavr, debugger avr-gdb z graficz-

nym interfejsem Insight, programator

avrdude, Avarice - interfejs komuni-

kacji pomiędzy avr-gdb a sprzętowym

adapterem JTAG, szeroki wachlarz

małych pomocniczych programów

narzędziowych ogólnego stosowania,

generator plików makefile MFile oraz

ogromny zbiór pomocy, manuali i

dokumentacji. WinAvr jest aktualizo-

wane co kilka miesięcy i dostępne

na http://winavr.sourceforge.net.

Wielką zaletą WinAvr jest wszech-

stronność dostarczonego materiału,

który pozwala na dogłębne zapozna-

nie się z metodyką programowania,

a także na indywidualny wybór naj-

bardziej „pasującego” zestawu narzę-

dzi. Jednak dla początkującego ta

wszechstronność może zmienić się w

poważną wadę: po prostu trudno się

w tym wszystkim połapać. Dodatko-

wym utrudnieniem jest konieczność

zapoznania się (przynajmniej w ogól-

nym zarysie) z zasadami działania i

używania managera procesów make ,

stosowanego standardowo do urucha-

miania kompilatora.

Ale w naszym środowisku ten

nadmiar w niczym nie przeszka-

dza. Wykorzystamy po prostu tylko

sam kompilator (AvrSide nie używa

make ), gdy zaś zechcemy poczytać

dokumentację albo wypróbować inne

techniki opracowania projektów -

wszystko będzie pod ręką. AvrSide

było zresztą początkowo dedykowane

do współpracy z WinAvr i domyśl-

nie jest instalowane w jego folderze.

Dopiero później pojawiła się własna

dystrybucja avr-gcc (także na stro-

nie http://www.avrside.fr.pl). Obecnie

mamy więc do wyboru dwie możli-

wości:

– instalacja kompletnego WinAvr a

następnie AvrSide domyślnie w

folderze głównym WinAvr;

– uproszczona instalacja samego

AvrSide we własnym niezależnym

folderze np. c:\AvrSide i uzupeł-

nienie kompilatorem (właśnie tak

jest skonfigurowane środowisko

używane na potrzeby artykułu).

W obu przypadkach AvrStudio

instalujemy całkiem niezależnie zgod-

nie z zaleceniami Atmela.

Zanim zabierzemy się do pisania

pierwszych programów zapoznajmy

się ogólnie z działaniem elementów

środowiska programistycznego. Znako-

micie ułatwi to dalszą pracę i ana-

lizę pierwszych przykładów. Można

oczywiście na razie te zagadnienia

przejrzeć tylko pobieżnie - będziemy

wielokrotnie do nich wracać.

nad kompilatorem). Czy te wady są

bardzo uciążliwe - ocenimy sami po

pierwszych próbach programowania.

Nasze środowisko uruchomieniowe

Nasz „kursowy” zestaw do pro-

gramowania AVR składa się z nastę-

pujących pakietów narzędzi:

– właściwego kompilatora avr-gcc,

który jest programem typu CLI

( command line interface ) i bez

dodatkowego wsparcia musiałby

być obsługiwany z poziomu kon-

soli tekstowej;

– graficznego środowiska eliminują-

cego powyższą niedogodność - w

tej roli występuje bezpłatne Avr-

Side pozwalające na szybkie i in-

tuicyjne wykonanie podstawowych

operacji (wersja PL);

– najnowszej, mocno ostatnio roz-

winiętej i unowocześnionej wersji

firmowego pakietu Atmela AvrStu-

dio, który służy jako symulator i

debugger do testowania naszych

przykładowych projektów.

Całość jest zainstalowana na plat-

formie Windows. Dopuszczalne są

wersje 98, ME, XP, 2000. AvrSide

nie da się uruchomić pod NT i 95

ze względu na brak obsługi magistra-

li USB (koniecznej dla wbudowanego

Jak działa avr-gcc

Avr-gcc określamy ogólnym mia-

nem kompilatora - jednak w rzeczy-

wistości jest to cały szereg współ-

pracujących ze sobą narzędzi i bi-

bliotek używanych w odpowiedniej

kolejności i z potrzebnymi opcjami

(„właściwy” kompilator avr-gcc , ze-

staw narzędziowy avr-binutils oraz

biblioteki dla rodziny AVR avr-libc ).

Celem jest przetworzenie kodu źró-

dłowego C zapisanego w jednym lub

wielu plikach projektu na wynikowe

pliki: kodu wykonawczego wpisywa-

nego do pamięci Flash wybranego

Elektronika Praktyczna 3/2005

K U R S

modelu mikrokontrolera oraz (ewen-

tualnie) danych wpisywanych do

wewnętrznej pamięci EEPROM . W

trakcie powstaje także szereg pomoc-

niczych plików zawierających rozma-

ite informacje potrzebne do debugo-

wania oraz pozwalające ocenić efek-

ty pracy kompilatora. Przykładowy

przebieg przetwarzania jest pokazany

na rys. 1 .

Najpierw pliki źródłowe poddawane

są działaniu preprocesora, który reali-

zuje zmiany w kodzie nakazane wpisa-

nymi przez nas dyrektywami:

– dołącza dodatkowe pliki z dyrektyw

#include ,

– wstawia definicje oraz rozwija ma-

kroinstrukcje z dyrektyw #define ,

– uwzględnia odpowiednie fragmenty

kodu z dyrektyw kompilacji warun-

kowej #if #else #endif.

Tak przygotowany kod poddawany

jest właściwej kompilacji czyli przeko-

dowaniu zapisu C na ciąg instrukcji

asemblera (z przeprowadzeniem opty-

malizacji - automatycznego uproszcze-

nia i skrócenia kodu), wynikiem tego

są pośrednie pliki *.s.

Pliki asemblerowe podlegają na-

stępnie przetworzeniu na kod ma-

szynowy (asemblacji). Powstałe pliki

*.o są na razie tzw. relokowalne

(przemieszczalne) - adresy zmiennych

i funkcji nie są jeszcze konkretnie

ustalone (pozostają nadal określone

jedynie nazwami symbolicznymi uży-

tymi przez nas w programie).

Pliki relokowalne są łączone (linko-

wane, konsolidowane) w następnej ope-

racji - polega to właśnie na ulokowa-

niu wszystkich porcji kodu w obszarze

pamięci programu oraz wyliczeniu i

nadaniu symbolom określonych adre-

sów. Jednocześnie zostają dołączone

wszelkie niezbędne funkcje biblioteczne

wykorzystywane przez nas (jawnie lub

pośrednio) w programie, a także specy-

ficzny dla danego typu mikrokontrolera

plik kodu inicjalizującego.

Wynikiem powyższych zabiegów

jest tzw. plik obiektowy (zazwyczaj

nadaje mu się rozszerzenie .elf), któ-

ry zawiera wszelkie informacje o pro-

jekcie (kod wynikowy, informacje dla

debuggera, wykaz symboli, rozmiary

poszczególnych sekcji kodu). Z infor-

macji tych możemy korzystać według

potrzeb dekodując potrzebne fragmen-

ty za pomocą zbioru narzędzi binutils.

Rysunek pokazuje tylko podstawowe

zastosowanie - utworzenie plików wy-

konywalnych wpisywanych przy po-

mocy programatora do pamięci Flash

oraz EEPROM mikrokontrolera.

Do tych - na razie bardzo skróto-

wych i ogólnych informacji - będzie-

my wielokrotnie wracać w trakcie

omawiania przykładowych projektów.

Na razie zobaczmy jeszcze jak są

rozmieszczone poszczególne elementy

kompilatora i gdzie szukać wymie-

nionych wcześniej narzędzi.

Rys. 2 przedstawia drzewko fol-

derów kompilatora. Nie wszystkie

subfoldery są dla nas jednakowo

istotne ale do niektórych będziemy

często zaglądać.

Główny folder został nazwany

na podstawie użytych wersji narzę-

dzi (avr-gcc w wersji 3.4.2, binutils

w wersji 2.15 i biblioteki avr-libc w

wersji 1.0.4). W WinAvr powyższa na-

zwa głównego katalogu nie występuje

- rolę tę pełni po prostu \WinAvr\,

jednak zasadnicza struktura drzewa

subfolderów pozostaje taka sama.

Dla użytkownika - programisty AVR

najbardziej istotne są podkatalogi:

– \bin\ - zawierający zestaw bezpo-

średnio używanych programów na-

rzędziowych avr-gcc i avr-binutils,

– \avr\include\ (oraz \avr\include\

avr\ ) - grupujący pliki nagłówko-

we ( headers ) biblioteki avr-libc,

w szczególności pliki opisujące

zasoby poszczególnych kostek,

do których często zaglądamy dla

sprawdzenia np. nazw rejestrów

czy wektorów przerwań,

– \avr\lib\ldscripts\ - zawiera skrypty

sterujące pracą konsolidatora (lin-

kera), w szczególności opisujące

wielkości poszczególnych obszarów

pamięci, jej podział na sekcje, ad-

resy początkowe i końcowe,

– \lib\gcc\avr\3.4.2\include - znajdzie-

my tu ogólne pliki nagłówkowe

gcc, nie powiązane bezpośred-

nio z kostkami AVR ale często

używane (np. przy zastosowaniu

zmiennych logicznych bool ),

– \doc\avr-libc\avr-libc-user-manual\

- mieści aktualny opis funkcji

bibliotecznych avr-libc oraz wiele

istotnych szczegółowych informa-

cji dotyczących różnych aspek-

tów programowania (jest to pozy-

cja obowiązkowa - tu zaglądamy

prawie codziennie).

Pozostałe subfoldery zawierają

wewnętrzne podprogramy i biblioteki

gcc, wywoływane podczas kompilacji

w tle bez naszego bezpośredniego

udziału.

Zwróćmy uwagę na dość tajem-

nicze w pierwszej chwili oznacze-

nia: avr3 - avr4 - avr5 . Wynikają

one z przyjętego podziału szeregu

kostek AVR na różne typy architek-

tury związane z wielkością zasobów

danego mikrokontrolera. Każdy typ

posiada oddzielny zestaw bibliotek.

Jednak nie musimy się tym kłopotać

- na podstawie podanej w wywoła-

niu nazwy kostki konsolidator samo-

czynnie wybiera odpowiedni zestaw

z właściwego subfolderu (więcej na

ten temat powiemy przy opisach

działania avr-ld).

Teraz pozostaje już tylko pytanie

jak użyć tych wszystkich narzędzi

dla uzyskania pożądanego efektu.

Najbardziej podstawowym sposobem

będzie kolejne wpisywanie potrzeb-

nych komend w linii poleceń teksto-

wej konsoli. Taka metoda - chociaż

dobra do przeprowadzenia ekspery-

mentów edukacyjnych - jest zbyt

uciążliwa i powolna przy praktycz-

nym programowaniu - potrzebna jest

nam automatyzacja całego procesu

kompilacji. Tradycyjnym i bardzo

rozpowszechnionym rozwiązaniem

jest zastosowanie programu narzę-

dziowego make . Mówiąc w wielkim

skrócie jest to uniwersalny zarządca

procesów, który wykonuje po ko-

lei zadania określone podanymi mu

przy wywołaniu zasadami ( rules ).

Zasady te zapisujemy w określony

sformalizowany sposób w tekstowych

plikach makefile przygotowanych dla

każdego projektu. Make jest bardzo

wszechstronnym i potężnym narzę-

dziem pozwalającym na praktycznie

dowolne kształtowanie jego działania.

Jednak ta zaleta potrafi stać się po-

ważną wadą i przeszkodą przy roz-

poczynaniu nauki programowania -

musimy na wstępie opanować dodat-

kowy spory zasób wiadomości. Poza

tym make jest narzędziem typowo

tekstowym - nie stanowi to żadnej

przeszkody dla miłośników Linuksa,

ale przyzwyczajeni do interfejsów

graficznych użytkownicy Windows

mają prawo mieć inne zdanie (ab-

solutnie nie mam zamiaru powracać

tu do odwiecznego sporu o wyż-

szość jednego systemu nad drugim

- stwierdzam po prostu fakt). W na-

szym kursie realizowanym na plat-

formie Windows wykorzystamy więc

inne narzędzie. Oczywiście w mia-

rę nabierania doświadczenia opano-

wanie make będzie również bardzo

wskazane - ale to oddzielny temat i

w obecnym cyklu artykułów nie bę-

dziemy się tym zajmować.

Jerzy Szczesiul, EP

jerzy.szczesiul@ep.com.pl

Elektronika Praktyczna 3/2005

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

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: