AVR-GCC kompilator C dla mikrokontrolerów AVR.pdf
(
5599 KB
)
Pobierz
ep_03_081-083_gcc_cz1.indd
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
81
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
82
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
83
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
89
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
#define _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
90
Elektronika Praktyczna 4/2005
Plik z chomika:
prawdziwy10
Inne pliki z tego folderu:
AVR-USB.rar
(1167 KB)
rs232-knowledge.pdf
(817 KB)
1 Wire.pdf
(587 KB)
lista_rozkazow_2.jpg
(484 KB)
lista_rozkazow_3.jpg
(444 KB)
Inne foldery tego chomika:
apuln
Flash do ATMEGI
Język C
Programy
Przyklady HAPSIM
Zgłoś jeśli
naruszono regulamin