Elektronika dla Wszystkich

37

Programowanie

Kontynuujemy  tworzenie  programu  obs³ugi

wyœwietlacza multipleksowanego. Tak jak obie-

ca³em, doprowadzimy teraz program do pe³nej

funkcjonalnoœci. Zmienimy elementy marnuj¹-

ce cenne zasoby. Wa¿ne jest jednak to, abyœ wie-

dzia³, ¿e bêdziemy musieli w tym celu odejœæ od

standardu  ANSI  C.  W  standardzie  tym  nie

wystêpuje twór taki jak przerwania oraz oddziel-

na pamiêæ danych i programu. Jedyne, co w tym

zakresie zosta³o zdefiniowane, to fakt, ¿e wszyst-

kie  nietypowe  problemy  twórca  kompilatora

powinien... rozwi¹zaæ we w³asnym zakresie.

Wiêcej o plikach 

nag³ówkowych

Do  tej  pory  niewiele  pisa³em  o  tytu³owych

plikach.  Nag³ówki  do³¹czaliœmy  do  ka¿dego 

z  tworzonych  plików.  Przypomnê,  ¿e  prak-

tycznie  ka¿dy  program  posiada³  dyrektywê

#include  <avr\io.h>.  W  poprzedniej  czêœci

zaczêliœmy  korzystaæ  tak¿e  z  dobrodziejstw,

jakie daje nam plik <inttypes.h>. Z dyrekty-

wy #include bêdziemy korzystaæ coraz inten-

sywniej, dlatego te¿ jest to najwy¿sza pora na

jej dok³adniejsze opisanie. Informacje na ten

temat znajduj¹ siê w ramce u do³u strony.

AVR-GCC – przerwania

Zanim zabierzemy siê do dalszych przeróbek

naszego  kodu,  poœwiêæmy  chwilê  na  prze-

myœlenie,  gdzie  umieœcimy  obs³ugê  naszego

wyœwietlacza.  Na  pewno  bêdzie  to  jedno 

z  przerwañ  zegara  –  licznika.  Warto  w  celu

jego wybrania zerkn¹æ do dokumentacji opi-

suj¹cej  procesor  AT90S2313.  Uk³ad  ten  ma

dwa  liczniki.  Prosty  oœmiobitowy  oraz  bar-

dziej rozbudowany o rozdzielczoœci szesnastu

bitów. 

P

P

r

r

o

o

g

g

r

r

a

a

m

m

o

o

w

w

a

a

n

n

i

i

e

e

 

 

p

p

r

r

o

o

c

c

e

e

s

s

o

o

r

r

ó

ó

w

w

w

w

 

 

j

j

ê

ê

z

z

y

y

k

k

u

u

 

 

C

C

Czêœæ 3

ABC... C

Dyrektywa 

#include

i pliki nag³ówkowe

Jak wszystkie komendy zaczynaj¹ce siê zna-

kiem  hash  (#),  tak  te¿  i  #include nie  jest

instrukcj¹ jêzyka C. Jest to komenda prze-

znaczona  dla  kompilatora,  steruj¹ca  jego

prac¹.

#include <plik.h>

Gdy  kompilator  natknie  siê  na  wspomnian¹

dyrektywê, wstawi w jej miejsce odpowiedni

plik. Uwa¿aj teraz: wa¿ne jest to, jakimi zna-

kami otoczymy nazwê pliku. Do tej pory ca³y

czas  stosujemy  zapis  <plik.h>.  Dziêki  temu

kompilator wie, ¿e chcemy do³¹czyæ jeden ze

standardowych  nag³ówków.  Wyjœciowym

folderem,  w  którym  odbywa  siê  w  takim

przypadku poszukiwanie pliku, jest 

C:\WinAVR\avr\include.  Jeœli  jeszcze  tego

nie zrobi³eœ – warto abyœ tam zajrza³ i zoba-

czy³,  jakie  standardowe  pliki  oferuje  GCC.

Przejrzyj,  co  znajduje  siê  w  ich  wnêtrzu. 

Nie przejmuj siê, jeœli wydaj¹ siê teraz niesa-

mowicie zagmatwane. W praktyce posiadaj¹

one  bardzo  rozbudowane  komentarze,  które

bywaj¹  lepsz¹  dokumentacj¹  ni¿  znajduj¹cy

siê w katalogu C:\WinAVR\doc\avr-libc pros-

ty  manual.  Zwróæ  uwagê  tak¿e  na  to,  ¿e 

w plikach tych czêsto znajduje siê do³¹cze-

nie innych plików. Mo¿esz spróbowaæ prze-

œledziæ, jak odbywaj¹ siê kolejne „do³¹cze-

nia”.

Wielokrotnie  do³¹czaj¹c  plik  nag³ówka,

odwo³ywaliœmy  siê  do  podkatalogu  avr. 

W  miejscu  tym  zosta³y  umieszczone  pliki,

których  standard  C  w  ¿aden  sposób  nie

ujmuje i s¹ one œciœle przynale¿ne do zasto-

sowanych  procesorów.  Zajrzyj  do  naszego

„niezbêdnika”  –  pliku  io.h.  Jest  to  plik  na

pierwszy  rzut  oka  doœæ  skomplikowany.

Okazuje  siê  jednak,  ¿e  jego  rdzeñ  stanowi

warunkowe do³¹czenie innych plików, zale¿-

nie od wybranego typu procesora. Zajrzyj do

pliku  io2313.h.  Tutaj  w³aœnie  znajduj¹  siê

najwa¿niejsze  z  naszego  punktu  widzenia

definicje  rejestrów,  wektorów  przerwañ 

i nazw poszczególnych bitów naszego proce-

sora.  Czasami  warto  tu  zajrzeæ,  przede

wszystkim,  jeœli  poszukujemy  nazwy  jakie-

goœ rejestru, do którego w³aœnie chcemy siê

odwo³aæ.

W oddzielnej ramce umieœci³em skrótowe

informacje  o  najbardziej  nas  interesuj¹cych

plikach znajduj¹cych siê w tym folderze.

#include „plik.h”

Nazwa  pliku  mo¿e  byæ  tak¿e  umieszczona

miêdzy znakami cudzys³owiu. W takim przy-

padku  poszukiwanie  odpowiedniego  pliku

bêdzie  siê  odbywaæ  z  poziomu  folderu, 

w którym znajduj¹ siê pliki naszego progra-

mu. Ma to niebagatelne znaczenie w chwili

pisania du¿ego programu oraz jego rozbijania

na wiele plików. Jest tak¿e wa¿ne, jeœli chce-

my do³¹czyæ po prostu jakiœ swój plik, czy to

z  w³asnymi,  uniwersalnymi  funkcjami,  czy

te¿ pobrany z sieci.

Z mo¿liwoœci tej nie bêdziemy dziœ jesz-

cze  korzystaæ,  jednak  warto  ju¿  teraz  wie-

dzieæ, ¿e taka mo¿liwoœæ istnieje.

<avr\io.h> 

Plik, który powinien byæ do³¹czony do ka¿dego programu. Definiuje adresy rejes-

trów procesora, w tym jego porty. Dziêki temu mo¿emy odwo³aæ siê do nich za pomoc¹ sta-

³ych symbolicznych. To, jakie rejestry zostan¹ zdefiniowane, zale¿y od typu wybranego mik-

rokontrolera wskazanego w pliku makefile.

<inttypes.h> 

Bardzo  wa¿ny  plik,  który  czêsto  bêdzie  w  u¿yciu  w  naszych  programach 

–  definiuje  proste  nazwy  dla  zmiennych  ca³kowitych.  Wiêcej  szczegó³ów  znajduje  siê 

w ramce o zmiennych (pojawi³a siê w czêœci 2).

<avr\interrupt.h>

Umo¿liwia wykorzystanie kilku prostych funkcji dotycz¹cych przerwañ,

wœród nich sei() i cli() – globalne odblokowanie i zablokowanie przerwañ.

<avr\signal.h> 

Umo¿liwia proste tworzenie funkcji obs³ugi przerwañ.

<avr\pgmspace.h> 

Upraszcza korzystanie ze zmiennych umieszczonych w pamiêci progra-

mu.

<avr\eeprom.h> 

Zawiera funkcje obs³ugi pamiêci eeprom.

<avr\wdt.h>

Kilka pomocniczych funkcji obs³ugi timera watchdog.

<avr\delay.h>

Proste (a tak¿e niedok³adne) funkcje realizuj¹ce opóŸnienia.

Najczêœciej stosowane, standardowe pliki nag³ówkowe 

udostêpniane przez AVR-GCC

Obs³uga wyœwietlacza wymaga od nas

wysterowania ka¿dej cyfry tak, aby niedo-

strzegalne by³o migotanie ca³ego pola odczy-

towego. Za granicê widocznego przez cz³o-

wieka migotania uznaje siê oko³o 50Hz.

Ka¿de przerwanie powodowaæ bêdzie wy³¹-

czenie bie¿¹cego wyœwietlacza i uruchomie-

nie nastêpnego. Bior¹c pod uwagê, ¿e wy-

œwietlaczy mamy 4 – dochodzimy do wnios-

ku, ¿e musimy odpowiedni¹ procedurê wywo-

³aæ co najmniej 200 razy w ci¹gu sekundy.

Oczywiœcie nie jest tutaj wa¿na du¿a do-

k³adnoœæ odmierzenia czasu. Jeœli procedura

obs³ugi wyœwietlacza bêdzie wywo³ywana

nawet 500 razy na sekundê, spowoduje to

tylko wiêksze obci¹¿enie procesora, a jedno-

czeœnie mniej zauwa¿alne migotanie wy-

œwietlacza. Ostatecznie pod koniec ca³ego po-

wy¿szego toku rozumowania mo¿emy stwier-

dziæ, ¿e ca³kowicie wystarczy nam zastoso-

wanie prostszego timera. Bardziej rozbudo-

wany pozostawiamy w celu jego ewentualne-

go wykorzystania do bardziej ambitnych

zadañ. Ze wzglêdu natomiast na prostotê

wspomnianego licznika, wyboru w przerwa-

niach nie mamy – bêdzie to przerwanie

wywo³ywane w momencie przepe³nienia licz-

nika.

Koniecznie zapoznaj siê teraz z ramk¹

mówi¹c¹ o tym, jak w naszym kompilatorze

wygl¹da obs³uga przerwañ. Tabela 2 prezen-

tuje nazwy przerwañ procesora AT90S2313.

Wszystkie nazwy, jakie udostêpnia nasz kom-

pilator, mo¿na odnaleŸæ w manualu (przypo-

minam:  C:\WinAVR\doc\avr-libc). Z mojego

doœwiadczenia wynika jednak, ¿e znacznie

wygodniej jest zajrzeæ do odpowiedniego

pliku definiuj¹cego wszelkie sta³e symbolicz-

ne dla wykorzystanego procesora. W naszym

przypadku bêdzie to C:\WinAVR\avr\inclu-

de\avr\  io2313.h.  Listing  10  pokazuje, jak

wygl¹da definicja wektorów przerwañ. W ten

sposób czêsto ³atwiej znaleŸæ interesuj¹c¹ nas

nazwê ni¿ za pomoc¹ przedzierania siê przez

dokumentacjê, w której brak podzia³u na

poszczególne procesory.

Uzbrojeni w wiedzê o przerwaniach mo¿e-

my podj¹æ siê ju¿ zadania napisania naszego

kodu z ich wykorzystaniem. Spójrz na listing

11. Przedstawi³em na nim prawie kompletny

kod naszego programu. Program zosta³ napi-

sany na bazie tego, do czego uda³o nam siê

dojœæ w poprzedniej czêœci. Spójrz na linie

oznaczone na szaro. S¹ to linie, które nie uleg-

³y zmianom. Mo¿e zdziwi Ciê wyszarzenie

wnêtrza naszej funkcji obs³ugi przerwania?

Zrobi³em to specjalnie. Zauwa¿, ¿e zawarty

tutaj kod to nic innego jak poprzednia zawar-

toœæ naszej pêtli g³ównej! Dziêki temu, ¿e

wykorzystujemy sprawdzony ju¿ fragment

kodu, unikamy pracy oraz zmniejszamy mo¿-

liwoœæ pomy³ki.

Zanim wiêc zaczniesz pisaæ nowy pro-

gram, warto oszczêdziæ sobie pracy i przyj-

rzeæ siê co tak naprawdê jest do zrobienia 

w stosunku do jego wersji z poprzedniego

miesi¹ca. Jeœli chcesz zachowaæ kopiê po-

przedniego programu, skopiuj go teraz. Na-

stêpnie otwórz go w Programmers Notepa-

dzie.  Tak naprawdê konieczne jest jedynie

dodanie dwóch plików nag³ówkowych poma-

gaj¹cych w obs³udze przerwañ. Konieczne

jest dopisanie trzech linii inicjacji, utworzenie

szkieletu funkcji obs³ugi przerwania oraz

przeniesienia do jej cia³a wnêtrza

naszej pêtli g³ównej. Sam¹ (pust¹

ju¿) pêtlê g³ówn¹ proponujê zosta-

wiæ. Zmiany opisa³em tutaj bardzo

skrótowo, ale jeœli podeprzesz siê

jeszcze listingiem 11 – wprowadze-

nie odpowiednich zmian nie bêdzie

trudne. 

Po skompilowaniu programu 

i jego wys³aniu do naszego uk³adu tes-

towego powinniœmy ujrzeæ znajomy

nam widok – wyœwietlane kolejne

cyfry na wyœwietlaczach. Niektórzy

!&

Programowanie

Elektronika dla Wszystkich

Listing 10  Definicja nazw przerwañ w pliku io2313.h

/* Interrupt vectors */ 

#define SIG_INTERRUPT0  _VECTOR(1)

#define SIG_INTERRUPT1  _VECTOR(2)

#define SIG_INPUT_CAPTURE1 _VECTOR(3)

#define SIG_OUTPUT_COMPARE1A _VECTOR(4)

#define SIG_OVERFLOW1  _VECTOR(5)

#define SIG_OVERFLOW0  _VECTOR(6)

#define SIG_UART_RECV  _VECTOR(7)

#define SIG_UART_DATA  _VECTOR(8)

#define SIG_UART_TRANS  _VECTOR(9)

#define SIG_COMPARATOR  _VECTOR(10)

#define _VECTORS_SIZE 22

ABC... C

Obs³uga przerwañ w AVR-GCC

Przypominam jeszcze raz: standard ANSI C

nie definiuje sposobu obs³ugi przerwañ. To, 

o czym bêdziemy dalej mówiæ, dotyczy œciœ-

le kompilatora zastosowanego w pakiecie

WinAVR.

Tworzenie funkcji obs³ugi przerwania

znakomicie upraszcza do³¹czenie do progra-

mu pliku <avr\signal.h>. Definiuje on 3

ró¿ne makra. Po jego do³¹czeniu funkcjê

obs³ugi przerwania tworzymy jak to przed-

stawia listing:

Czy¿ nie wygl¹da prosto? Takie w³aœnie

w istocie jest. 

Najczêœciej bêdziemy korzystaæ z zaleca-

nego makra SIGNAL. Powoduje ono utwo-

rzenie funkcji obs³ugi w typowy dla AVR-ów

sposób, gdzie w czasie obs³ugi jednego prze-

rwania zerowana jest globalna flaga zezwole-

nia na przerwanie. Nie oznacza to, ¿e proce-

sor jest „œlepy i g³uchy na inne wo³ania”.

Jeœli w tym czasie bêdzie zg³oszone ¿¹danie

obs³ugi innego zdarzenia, ustawiona zostanie

odpowiednia flaga i bêdzie ono obs³u¿one,

gdy tylko przerwania zostan¹ odbloko-

wane (nastêpuje to automatycznie przy

koñczeniu obs³ugi aktualnego prze-

rwania).

Czasami jednak chcemy, aby nowe zda-

rzenie mog³o przerwaæ bie¿¹ce zadanie.

Mo¿emy w takim przypadku przy tworzeniu

funkcji obs³ugi s³owo SIGNAL zamieniæ na

INTERRUPT. Kompilator doda wtedy auto-

matyczne odblokowanie przerwañ zaraz po

wywo³aniu jego obs³ugi. Makra tego nale¿y

u¿ywaæ bardzo ostro¿nie. Ka¿de przerwanie

odk³ada na stos pewne informacje. Nieprze-

myœlane u¿ywanie makra typu INTERRUPT

mo¿e doprowadziæ do zapchania stosu i nie-

przewidzianego dzia³ania programu.

Pozosta³o nam jeszcze trzecie, rzadziej

stosowane makro. Umo¿liwia ono utworze-

nie tak zwanego pustego przerwania. Wywo-

³ane przerwanie natychmiast zwróci sterowa-

nia do programu g³ównego. Jest to o tyle

wa¿ne, ¿e standardowo wyst¹pienie nieprze-

widzianego przerwania spowoduje restart

ca³ego programu. Puste przerwanie mo¿emy

utworzyæ jak ni¿ej:

Nie nale¿y definiowaæ cia³a funkcji –

makro tworzy je automatycznie.

W³¹czanie/wy³¹czanie przerwañ

Plik <avr/interrupt.h> definiuje bardzo przy-

datne funkcje sei() i cli(). Obie t³umaczone s¹

na jedn¹ instrukcjê asemblera o nazwie iden-

tycznej z nazw¹ funkcji. Powoduj¹ odpo-

wiednio: globalne w³¹czenie i globalne wy³¹-

czenie przerwañ. 

Istnieje tutaj tak¿e funkcja aktywacji prze-

rwañ liczników. Jednak chocia¿by ze wzglê-

du na kompatybilnoϾ z innymi kompilatora-

mi oraz banalnoœæ „rêcznego” realizowania

takiego dzia³ania – nie warto z niej korzystaæ. 

SIGNAL(Nazwa_przerwania)

{

// Cia³o funkcji 

}

EMPTY_INTERRUPT(Nazwa_przerwania);

Tabela 2  Przyk³adowe nazwy przerwañ

dostrzeg¹  jednak  migotanie  wyœwietlaczy.

Przyjrzyjmy siê naszemu programowi – z jak¹

czêstotliwoœci¹  obs³ugujemy  wyœwietlacze?

Dobrze  by³oby,  gdybyœ  móg³  razem  ze  mn¹

zajrzeæ do karty katalogowej naszego mikro-

kontrolera.  Nasz  timer  wywo³uje  przerwanie

po ka¿dym przepe³nieniu – oznacza to prze-

rwanie  co  256  zliczonych  impulsów.  Dodat-

kowo rejestr TCCR0 zosta³ ustawiony w taki

sposób, ¿e licznik zlicza impulsy zegara sys-

temowego,  podzielone  w  preskalerze  przez

64. Jak ³atwo obliczyæ: 

4MHz/(256*64) = 244Hz

Przy  czterech  wyœwietlaczach  otrzymuje-

my  czêstotliwoœæ  odœwie¿ania  ca³ego  pola

rzêdu 60Hz. Niby wiêcej ni¿ granica czêstot-

liwoœci,  jak¹  cz³owiek  zauwa¿a,  jednak 

w praktyce czêsto tak niska czêstotliwoœæ jest

nieprzyjemna w odbiorze. Mo¿na spróbowaæ

j¹ podwy¿szyæ, zmniejszaj¹c stopieñ preska-

lera. Znów zagl¹damy do dokumentacji. Oj –

niedobrze...  najbli¿szy,  ni¿szy  stopieñ  jest  8

razy  mniejszy.  Mo¿na  zobaczyæ,  jaki  bêdzie

efekt. Zamieñ pierwsz¹ linijkê inicjacji timera

na: 

TCCR0 =

1

<<CS01;

Migotanie rzeczywiœcie ca³kowicie usta³o.

Warto  zobaczyæ,  jak  takie  przyspieszenie

wyœwietlacza  obci¹¿y³o  procesor.  Z  pomoc¹

przyjdzie  nam  tutaj  AVRStudio. Zak³adam,

¿e  jego  uruchomienie  oraz  wczytanie  pliku

programu  nie  sprawia  Ci  problemów.  Jeœli

pracujesz na poprzednim kodzie – w katalogu

powinien nawet znajdowaæ siê ju¿ plik o roz-

szerzeniu  aps,  którego  dwukrotne  klikniêcie

otworzy  od  razu  AVRStudio ze  skonfiguro-

wanym symulatorem.

Uruchom teraz na chwilê program w trybie

pracy  ci¹g³ej.  Zatrzymaj  go  w  dowolnym

momencie  za  pomoc¹  klawisza  pauzy  na

pasku  narzêdziowym  (CTRL+F5).  Zale¿y

nam, aby zatrzymaæ program ju¿ po inicjacji

czêœci  sprzêtowej,  w  pustej  pêtli  g³ównej.

Jeœli  pechowo  trafi³eœ  w³aœnie  na  obs³ugê

przerwania  –  uruchom  program  jeszcze  na

sekundê  i  ponownie  zatrzymaj.  Innym,  bar-

dziej eleganckim sposobem zatrzymania pro-

gramu w interesuj¹cym nas punkcie jest usta-

wienie  kursora  na  instrukcji  for  i  wybranie 

z  paska  narzêdzi  komendy  Run  to  cursor

(CTRL+F10).

Jest wiele sposobów, ¿eby sprawdziæ czas,

przez jaki bêdzie wykonywaæ siê dana proce-

dura. Jeœli jest to podprogram, mo¿na na przy-

k³ad wyzerowaæ licznik czasu tu¿ przed jego

wywo³aniem,  kazaæ  symulatorowi  go  prze-

skoczyæ  (F10)  i  ju¿  mamy  czas  wykonania

procedury. Próbê dobrze jest powtórzyæ kilka-

krotnie  i  za  czas  wy-

konania podprogramu

uznaæ otrzymany czas

œredni.  W  naszym

przypadku  mamy  do

czynienia  z  przerwa-

niem.  Zasada  bêdzie

wiêc troszkê zmienio-

na,  aczkolwiek  ogól-

nie  pozostaje  zacho-

wana.

Spójrz na rysunek

22. Przedstawi³em na

nim  widok  prawid³o-

wo  skonfigurowane-

go symulatora AVRS-

tudio  razem  z  dodat-

kowymi  komentarza-

mi. Spróbuj doprowa-

dziæ  do  podobnej

sytuacji. Przyjrzyj siê, jakie zak³adki zosta³y

przeze mnie rozwiniête w lewym panelu. Naj-

bardziej interesuje nas licznik cykli. Wykonu-

j¹c  kilkakrotnie  komendê  Run  to  cursor,

stwierdzimy, ¿e wykonanie pêtli for zajmuje

procesorowi  dwa  cykle.  Zapamiêtujemy  tê

wartoœæ.  Gdy  program  jest  ju¿  zatrzymany,

zerujemy  licznik  cykli,  tak  jak  opisuj¹  to

komentarze  na  obrazku.  Ustawiamy  flagê

symuluj¹c¹  wyst¹pienie  przerwania  przepe³-

nienia  licznika  0  i  wykonujemy  ponownie

komendê Run to cursor. U mnie licznik wska-

za³  82  cykle.  Wiemy,  ¿e  wykonanie  samej

pêtli i dojœcie do kursora dodaje do tej war-

toœci dwa cykle – aby uzyskaæ dok³adny czas

zajmowany przez przerwanie, nale¿y wartoœæ

tê odj¹æ od uzyskanej. Po kilkakrotnej próbie,

raz na 3 przerwania, czas wykonania jego obs³u-

gi  wynosi³  83  cykle.  Jest  to  o  tyle  oczywiste, 

39

Programowanie

Elektronika dla Wszystkich

Listing 11  Obs³uga wyœwietlacza LED w przerwaniach

#include <avr\io.h>

#include <inttypes.h>

#include <avr\signal.h>

#include <avr\interrupt.h>

(... definicje wyprowadzeñ - bez zmian...)

uint8_t g_AktWyswietlacz = 

0

; 

uint8_t g_DaneWyswietlacza[

4

]; 

uint8_t g_DaneCom[

4

] = 

{~(

1

<<COM1), ~(

1

<<COM2), ~(

1

<<COM3), ~(

1

<<COM4)};

int

main(

void

)

{

/////////////////////////////

// inicjacja

LEDDDR = 

0xff

; 

COMDDR = 

1

<<COM1 | 

1

<<COM2 | 

1

<<COM3 | 

1

<<COM4; 

// Timer0

TCCR0 = 

1

<<CS01|

1

<<CS00; 

TIMSK = 

1

<<TOIE0; 

// Globalne zezwolenie na przerwania

sei(); 

// koniec inicjacji

/////////////////////////////

// Wpisanie do tablicy próbnych wartoœci

g_DaneWyswietlacza[

0

] = ~(

1

<<LED_B | 

1

<<LED_C); 

g_DaneWyswietlacza[

1

] = ~(

1

<<LED_A | 

1

<<LED_B | 

1

<<LED_D | 

1

<<LED_E | 

1

<<LED_G); 

g_DaneWyswietlacza[2] = ~(1<<LED_A | 1<<LED_B | 

1

<<LED_C | 

1

<<LED_D | 

1

<<LED_G); 

g_DaneWyswietlacza[3] = ~(1<<LED_B | 1<<LED_C | 

1

<<LED_F | 

1

<<LED_G); 

for

(;;)

{

}

return

0

; 

}

//_____________________________________________

// Obs³uga przerwañ

SIGNAL(SIG_OVERFLOW0)

{

// Wygaszenie wyœwietlaczy

COMPORT |= 

1

<<COM1 | 

1

<<COM2 | 

1

<<COM3 | 

1

<<COM4; 

// Wys³anie odpowiedniej danej

LEDPORT = g_DaneWyswietlacza[g_AktWyswietlacz]; 

// W³¹czenie odpowiedniego wyœwietlacza

COMPORT &= g_DaneCom[g_AktWyswietlacz]; 

// Zwiêkszenie stanu zmiennej wskazuj¹cej na 

// obs³ugiwany wyœwietlacz

++g_AktWyswietlacz; 

if

(g_AktWyswietlacz > 

3

)

g_AktWyswietlacz = 

0

; 

}

ABC... C

C a format linii

Mo¿e zauwa¿y³eœ, ¿e w kolejno przedstawianych kodach Ÿród³owych

dzielê liniê praktycznie tam, gdzie jest to dla mnie wygodne, listing

opracowujê tak, aby zmieœci³ siê ³adnie w ramce? Wydawaæ by siê

mog³o, ¿e jest to tylko zabieg maj¹cy zmniejszyæ objêtoœæ ca³ego tek-

stu,  okazuje  siê  jednak,  ¿e  jakkolwiek  wpisa³byœ  kod  –  wszystko

bêdzie dzia³aæ. 

C  jest  jêzykiem  niezale¿nym  od  formatu  linii. Wa¿ne  jest  to,

aby ka¿d¹ instrukcjê pojedyncz¹ zakoñczyæ znakiem œrednika, wa¿ne

jest  by  zawsze  zamkn¹æ  otwarty  nawias  czy  klamrê.  Natomiast 

w wiêkszoœci przypadków zupe³nie nie ma znaczenia, gdzie rozpo-

czniemy  now¹  liniê,  wstawimy  znak  tabulacji  czy  wiêcej  znaków

spacji. Oznacza to, ¿e zwykle mo¿esz przerwaæ pisanie bie¿¹cej linii

i rozpocz¹æ je w linii nastêpnej. W obliczeniach na przyk³ad mo¿esz

to zrobiæ przed lub po znaku dzia³ania.

W  rzadkich  przypadkach,  w  których  koniec  linii  ma  znaczenie

(przyk³adem  jest  dyrektywa  #define),  a  linia  staje  siê  nieznoœnie

d³uga, mo¿na zastosowaæ na koñcu znak ukoœnika (\). Spowoduje to,

¿e  kompilator  potraktuje  liniê  nastêpn¹  jako  przed³u¿enie  poprzed-

niej.

¿e dok³adnie co taki czas zmienna g_AktWys-

wietlacz jest  zerowana.  Ju¿  teraz  zapewne

domyœlasz siê, ¿e te kilkadziesi¹t cykli nie jest

du¿¹ wartoœci¹ dla procesora. Aby siê o tym

upewniæ,  policzmy  co  ile  cykli  pojawia  siê

przerwanie. 256 zliczeñ licznika, który zlicza

co  ósmy  takt  zegara  systemowego  –  2048

cykli. Nie potrzeba ju¿ wiêcej obliczeñ.

W tej chwili by³o to tylko æwiczenie, jed-

nak pozwoli³o na zaznajomienie siê z rzeczy-

wistym  problemem.  Warto  wiedzieæ,  jak

sprawdziæ  czas  wykonywania  przerwania,

zw³aszcza  ¿e  w  rzeczywistym,  rozbudowa-

nym programie mo¿e pojawiæ siê koniecznoœæ

jego optymalizacji. Je¿eli jednak nie chcemy

przyspieszaæ  wywo³ywania  przerwania  wy-

œwietlacza a¿ 8 razy, istnieje inna mo¿liwoœæ.

Mo¿emy  przywróciæ  poprzedni¹  wartoœæ

preskalera licznika, a w obs³udze przerwania

na jego przepe³nienie wpisywaæ do niego ja-

k¹œ wartoœæ pocz¹tkow¹. W tym celu wystar-

czy,  jeszcze  przed  wygaszeniem  wyœwietla-

czy, dopisaæ liniê:

TCNT0 = 128;

Wartoœæ  128,  odpowiadaj¹ca  po³owie

zakresu  zliczania,  spowoduje  dwukrotne

zwiêkszenie  czêstotliwoœci  wywo³ywania

przerwania.

Jakkolwiek postanowimy rozwi¹zaæ prob-

lem  niskiej  czêstotliwoœci  przemiatania

wyœwietlacza i czy w ogóle postanowimy go

rozwi¹zywaæ,  poznaj¹c  oraz  wykorzystuj¹c

przerwania  dokonaliœmy  wielkiego  skoku

jakoœciowego  –  teraz,  w  w¹tku  g³ównym,

mo¿emy  zapomnieæ  o  prze³¹czaniu  wy-

œwietlaczy, poœwiêcaj¹c uzyskane miejsce na

inne  dzia³ania.  Z  tego  punktu  widzenia

wyœwietlacz  sta³  siê  tablic¹  czterech  zmien-

nych  dok³adnie  odwzorowuj¹cych  wygl¹d

wyœwietlanych znaków.

Warunki i instrukcja if

Do tej pory milcz¹co zak³ada³em, ¿e u¿ywana

w  programie  instrukcja  if  jest  w  pe³ni  zro-

zumia³a. Wydaje mi siê, ¿e tak jest w istocie –

zosta³a  tutaj  wykorzystana  jej  najprostsza

sk³adnia,  a  dzia³ania  mo¿na  domyœliæ  siê 

z  kontekstu.  Dla  porz¹dku  i  aby  rozwiaæ

wszystkie w¹tpliwoœci, na tej i nastêpnej stro-

nie  przedstawiam  dwie  ramki.  Zwróæ  szcze-

góln¹ uwagê na ramkꠄWarunki”. Z zawar-

tych tam informacji bêdziemy jeszcze wielo-

krotnie korzystaæ. 

„Zmienne”

w pamiêci programu

Na  koniec  poprzedniej  czêœci  wspomnia³em

o  tym,  ¿e  zmienna  zawieraj¹ca  informacje

aktywacji  poszczególnych  wyœwietlaczy  –

g_DaneComm,  marnuje  nasze  zasoby  –  nie-

potrzebnie  zajmuje  cenn¹  pamiêæ  danych,

której  mamy  tylko  128B.  Jednoczeœnie  jej

kopia jest przechowywana w pamiêci progra-

mu w celu inicjacji wartoœci... których tak na-

prawdê  nigdy  nie  chcemy  zmieniaæ.  Ze

zmiennej  tylko  czytamy.  Bardziej  optymal-

nym rozwi¹zaniem w tym przypadku wydaje

siê  bezpoœrednie  czytanie  danych  z  pamiêci

programu.

W  tym  miejscu  zwraca  siê  przeciw  nam

architektura procesorów AVR. Mimo i¿ pro-

ducent  zapewnia  w  swoich  materia³ach,  ¿e

procesor  ten  by³  opracowywany  pod  k¹tem

wykorzystania jêzyków wysokiego poziomu,

takich  jak  C,  okazuje  siê,  ¿e  specyfikacja

ANSI  C  zosta³a  stworzona  dla  procesorów

niewyró¿niaj¹cych  pamiêci  danych  i  progra-

mu. W takim przypadku rozró¿nienie, do któ-

rej  pamiêci  chcemy  siê  odwo³aæ,  powinno

nastêpowaæ  za  pomoc¹,  tylko  i  wy³¹cznie,

ró¿nych adresów. W naszym procesorze nie-

stety  oba  wymienione  rodzaje  pamiêci  pod

wzglêdem  adresów  nachodz¹  na  siebie

(pierwsze 224 adresy odnosz¹ siê do pamiêci

danych,  przestrzeni  wejœcia  wyjœcia  oraz

rejestrów...  jednak  jednoczeœnie  adresy  te  s¹

jak najbardziej w³aœciwe dla pamiêci progra-

mu!).  Jedynym  sposobem  odró¿nienia  obu

pamiêci s¹ ró¿ne instrukcje dostêpu.

Producenci kompilatorów w ró¿ny sposób

rozwi¹zuj¹  przedstawiony  problem.  W  GCC

postanowiono  utworzyæ  oddzielne  instrukcje

umo¿liwiaj¹ce  dostêp  do  pamiêci  programu.

Warto  o  tym  pamiêtaæ  –  sam  wielokrotnie

wpada³em w pu³apkê, gdy chcia³em wykorzys-

taæ zmienn¹ umieszczon¹ w pamiêci progra-

mu  tak  samo,  jakby  by³a  ona  umieszczona 

w pamiêci danych. 

Du¿o informacji o wykorzystaniu pamiê-

ci  programu  znajdziesz  w  kolejnej  ramce

ABC... C. Gdy tylko przejrzysz zawarte tam

informacje,  mo¿emy  rozpocz¹æ  dalsz¹

modyfikacjê  naszego,  coraz  doskonalszego,

programu.

Mo¿e ju¿ zauwa¿y³eœ, ¿e w ramkach napi-

sa³em, co musimy zmieniæ w naszym kodzie.

Teraz, tylko dla porz¹dku, zbiorê te informa-

cjê  w  jednym  miejscu.  Umieœæ  wiêc  kursor

zaraz na koñcu sekwencji dyrektyw #include.

Dodaj  potrzebny  nam  nag³ówek  za  pomoc¹

komendy #include <avr\pgmspace.h>. Od tej

chwili mo¿emy korzystaæ z pamiêci programu

w  sposób  opisany  w  ramkach.  Nastêpnie

"

Programowanie

Elektronika dla Wszystkich

Rys. 22 Badanie liczby cykli obs³ugi przerwania

ABC... C

Instrukcja warunkowa if

Instrukcja if wystêpuje praktycznie w ka¿-

dym jêzyku programowania. W C jej dzia-

³anie  nie  odbiega  od  ogólnie  przyjêtej

normy. Jej sk³adnia jest nastêpuj¹ca:

Jeœli warunek jest spe³niony, wykonywa-

na  jest  instrukcja  znajduj¹ca  siê  zaraz  za

komend¹ if. Jeœli nie, to albo wykonywana

jest  instrukcja  znajduj¹ca  siê  za  komend¹

else, albo  –  w  przypadku  jej  braku  –  pro-

gram przechodzi do dalszego dzia³ania.

Pamiêtaj,  ¿e  w  obu  przypadkach,  jeœli

wystêpuje  instrukcja  prosta,  musi  koñczyæ

siê ona znakiem œrednika. Za pomoc¹ kla-

mer  mo¿na  wprowadziæ  tak¿e  instrukcje

z³o¿one.

if

(warunek)

instrukcja

[

else

instrukcja]

zmieniamy  typ  tablicy  g_DaneCom  na

prog_uint8_t.  Zgodnie  z  opisem  mo¿esz

zamiast tego dodaæ zaraz za deklaracj¹ zmien-

nej s³owo PROGMEM. Sposób, jaki wybie-

rzesz,  nie  ma  znaczenia.  Efekt  bêdzie  taki

sam. Ostatnim koniecznym do zmiany punk-

tem  jest  miejsce,  gdzie  doczytujemy  dane 

z naszej, przeniesionej do pamiêci programu,

tablicy. Wszystko to wyjaœniaj¹ wspomniane

ramki. Aby u³atwiæ Ci pracê oraz zrozumienie

ca³oœci – konieczne zmiany przedstawia ca³o-

œciowo listing 12. Tablica zosta³a umieszczo-

na tutaj w pamiêci programu za pomoc¹ s³owa

PROGMEM. 

Po  wprowadzeniu  zmian  skompiluj  pro-

gram... uda³o siê? Kompilacja powinna prze-

biec bez problemów, po za³adowaniu do pro-

cesora  nie  zauwa¿ymy  z  zewn¹trz  ró¿nicy 

w  porównaniu  do  poprzedniej  wersji.  W  tej

chwili czêœæ programu odpowiedzialna za ob-

s³ugê  wyœwietlacza  LED  jest  kompletna  i  w

pe³ni funkcjonalna. Jeœli jeszcze wprowadzi-

my do niej jakieœ zmiany – bêd¹ to poprawki

kosmetyczne.

Spodziewasz  siê  mo¿e,  ¿e  dostêp  do

pamiêci programu, od strony kodu maszyno-

wego,  jest  troszkê  bardziej  skomplikowany

ni¿  dostêp  do  pamiêci  RAM?  SprawdŸmy

wiêc, czym i jak zap³aciliœmy za zwolnione 4

komórki cennej pamiêci danych. Rysunek 23

przedstawia wyliczon¹ przez kompilator zajê-

toœæ pamiêci w przypadku programu. Podsu-

mowanie takie jest wykonywane po prawid³o-

wym zakoñczeniu ka¿dej kompilacji. Obydwa

programy,  zgodnie  z  proponowan¹  modyfi-

kacj¹,  zawiera³y  wpisanie  pocz¹tkowej  war-

toœci  to  licznika  –  co  zajmuje  dodatkowe  4

bajty.  Jak  widaæ,  koniecznoœæ  odwo³ywania

siê  do  pamiêci  programu  zaowocowa³a

zwiêkszeniem  programu  jedynie  o  2  bajty!

Okazuje siê wiêc, ¿e dzia³anie takie nie jest a¿

tak  bardzo  pamiêcioch³onne.  Jeœli  chcesz, 

w  ramach  æwiczenia  mo¿esz  sprawdziæ,  ile

cykli zajmie teraz procesorowi obs³uga nasze-

go przerwania.

"#

Programowanie

Elektronika dla Wszystkich

ABC... C

Warunki

Warunki s¹ to pewne specyficzne wyra¿enia,

które mog¹ przyj¹æ dwie wartoœci: true lub

false,  czyli  po  prostu  prawda  lub  fa³sz.

Zwykle konstruujemy je za pomoc¹ operato-

rów  porównañ  i  ewentualnie  operatorów

logicznych, przy czym te drugie s³u¿¹ do z³o-

¿enia  prostych  warunków  w  jedn¹  ca³oœæ.

Realizuj¹ one funkcje i, lub oraz nie. 

Dowolna liczba mo¿e zostaæ automatycz-

nie  zamieniona  na  warunek,  przy  czym  0

oznacza fa³sz, inna wartoœæ – prawdê. Poni¿-

sze zapisy s¹ równowa¿ne: 

if

(a) 

ó

if

(a!=

0

)

Mo¿na dowolnie mieszaæ w jednym wyra-

¿eniu  operatory  warunków,  arytmetyczne,

logiczne  czy  bitowe  (operatory  zosta³y

przedstawione  na  wk³adce  do  czêœci  2,

dostêpnej  na  stronie  www). Wa¿ne  jest  jed-

nak dobre zrozumienie zasady wykonywania

obliczeñ w C. 

Operatory logiczne 

a operatory bitowe

Do  tworzenia  z³o¿onych  warunków  wyko-

rzystujemy  operatory  logiczne.  Trzeba  byæ

tutaj bardzo ostro¿nym, poniewa¿ kompilator

nie  zg³osi  b³êdu  przy  instrukcji  na  przyk³ad

jak poni¿sza:

if

(a <

12

& b)

Spodziewamy siê, ¿e instrukcja if bêdzie

wykonana,  jeœli  a jest  mniejsze  od  podanej

liczby  i  jednoczeœnie  b jest  ró¿ne  od  zera.

Jednak zastanówmy siê, co siê stanie w rze-

czywistoœci: 

Nast¹pi porównanie liczby a z 12. Dzia³a-

nie  to  zwróci  prawdê  lub  fa³sz,  liczbowo

równe 1 lub 0. Jeœli porównanie bêdzie fa³-

szywe  –  instrukcja  zadzia³a  tak,  jak  tego

oczekiwaliœmy  –  bitowy  iloczyn  z  jak¹kol-

wiek liczb¹ zwróci wartoœæ sta³¹. Jeœli b jest

równe 0, na tej samej zasadzie wszystko bê-

dzie pozornie w porz¹dku. Problem zacznie

siê  w  pozosta³ej  sytuacji.  Gdy  porównanie

zwróci wartoœæ 1, a b bêdzie ró¿ne od zera,

taki bitowy iloczyn mo¿e byæ równy 0 lub 1,

zale¿nie  od  tego,  czy  najm³odszy  bit  b  jest

ustawiony, czy wyzerowany.

Prawid³owy  zapis  powinien  wygl¹daæ

nastêpuj¹co:

if

(a <

12

&& b)

Zapis  ten  jest  te¿  o  tyle  optymalny, 

¿e  obliczenia  s¹  przerywane  w  momencie,

gdy znany jest ju¿ wynik. Oznacza to, ¿e jeœli

oka¿e siê, na przyk³ad, ¿e pierwsze porówna-

nie zwróci fa³sz – wartoœæ zmiennej b nawet

nie  bêdzie  sprawdzana.  Uwaga:  standard

definiuje  takie  w³aœnie  zachowanie,  jednak

nie  definiuje,  w  jakiej  kolejnoœci  testowanie

ma byæ wykonywane. 

5<a<10 – oj...

chyba nie o to chodzi³o

Powy¿sze  wyra¿enie  mo¿e  wydawaæ  siê

poprawne.  Kompilator  nie  zg³osi  b³êdu.

Pomyœlmy  jednak,  jakie  operacje  zostan¹

wykonane:  liczba  5  zostanie  porównana  ze

zmienn¹  a,  dopiero  wynik  tego  porównania

zostanie  porównany  ze  sta³¹  10.  Co  jest

wynikiem  pierwszego  dzia³ania?  –  true  lub

false,  które  maj¹  wartoœci  liczbowe  1  i  0.

Widzisz  ju¿,  co  siê  stanie?  Ca³e  wyra¿enie

bêdzie zawsze spe³nione. 

Dzia³anie takie musisz rozbiæ na dwa:

if

(

5

<a && a<

10

)

Teraz  wszystko  bêdzie  dzia³a³o  zgodnie 

z nasz¹ intencj¹. 

Nie wszystko naraz

Widzisz mo¿e teraz, ¿e warunki w C pozwa-

laj¹  na  tworzenie  nawet  bardzo  z³o¿onych

wyra¿eñ.  Aby  dobrze  z  tym  sobie  radziæ,

konieczna jest praktyka. Nie trzeba przecie¿

od  razu  wykorzystywaæ  wszystkich  z³o¿o-

nych  mo¿liwoœci.  Jeœli  jest  to  dla  Ciebie

wygodne, mo¿esz z³o¿ony warunek rozbiæ na

prostsze.  Wy¿ej  zapisan¹  instrukcjê  mo¿na

by tak¿e zapisaæ w nastêpuj¹cy sposób:

if

(

5

<a)

{

if

(a<

10

)

{

//Program dojdzie do tego

//miejsca jeœli 5<a<10

}

}

Listing 12  Tablica g_DataCom w pamiêci programu

#include <avr\io.h>

#include <inttypes.h>

#include <avr\signal.h>

#include <avr\interrupt.h>

#include <avr\pgmspace.h>

(...)

uint8_t g_DaneCom[

4

] PROGMEM = 

{~(

1

<<COM1), ~(

1

<<COM2), ~(

1

<<COM3), ~(

1

<<COM4)};

int

main(

void

)

{

(...)

}

//____________________________________________________________

// Obs³uga przerwañ

SIGNAL(SIG_OVERFLOW0)

{

(...)

// W³¹czenie odpowiedniego wyœwietlacza

COMPORT &= pgm_read_byte(&g_DaneCom[g_AktWyswietlacz]);

(...)

}

Zaczynamy 

tworzyæ funkcje

Mo¿e i Tobie, tak jak i mnie znudzi³o siê prze-

twarzanie programu tak, aby na wyœwietlaczu

wci¹¿  widzieæ  to  samo.  Niezale¿nie  od  tego

jakie  wymyœlne  znaki  zostan¹  wypisane  –

wci¹¿ bêdzie to nieruchomy obraz. Mo¿e nad-

szed³ wiêc czas, by coœ w tym miejscu zmie-

niæ?

Skoro praktycznie nie musimy ju¿ zajmo-

waæ siê ci¹g³ym odœwie¿aniem wyœwietlacza

– dziêki przerwaniom bêdzie dzia³o siê to nie-

jako ca³kowicie niezale¿nie – mo¿emy wyko-

rzystaæ  pêtlê  g³ówn¹  do  tworzenia  animacji.

Najproœciej bêdzie wyœwietlaæ kolejne liczby.

Okazuje  siê  tak¿e,  ¿e  bardzo

³atwo  tworzy  siê  funkcjê

wyœwietlaj¹c¹  liczby  w  kodzie

heksadecymalnym. 

Myœlê,  ¿e  po  poznaniu

wszystkich informacji, jakie do

tej  pory  przedstawi³em,  jesteœ

ju¿ w stanie mniej wiêcej wyob-

raziæ sobie, jak bêd¹ wygl¹da³y

poszczególne  dzia³ania.  Ca³y

program  mo¿na  by  napisaæ 

w funkcji main. Takie przyzwy-

czajenia  niektórzy  mogli  wy-

nieœæ z BASCOM-a – tam opis

dzia³ania  najczêœciej  zawiera³o

siê  w  jednym  ci¹gu.  Twór  taki

jak funkcja by³ nieco sztuczny.

Jeœli  podzielasz  takie  w³aœnie  myœlenie,

chcia³bym, abyœ zacz¹³ przyzwyczajaæ siê do

czegoœ zupe³nie innego. Troszkê innej jakoœ-

ci. W C wykorzystanie funkcji staje siê ca³ko-

wicie naturalne. Program praktycznie zawsze

powinien sk³adaæ siê z zespo³u funkcji wywo-

³ywanych  z  poziomu  programu  g³ównego.

Nawet  bardziej  rozbudowana  obs³uga  prze-

rwania mo¿e korzystaæ z innych funkcji. Mam

nadziejê, ¿e przekonasz siê, ¿e takie myœlenie

jest bardzo wygodne. Dziêki temu, ¿e skom-

plikowane dzia³anie mo¿na rozbiæ na wiêcej

prostych – program pisze siê ³atwiej i bardziej

intuicyjnie. Wa¿ne jest tak¿e to, ¿e raz utwo-

rzon¹  funkcjê  mo¿na  wykorzystaæ  w  wielu

miejscach  –  co  zmniejsza  objêtoœæ  kodu.

Wyprzedzaj¹c trochê dzisiejszy zakres mate-

ria³u,  wspomnê  tylko  o  bardzo  wygodnej

w³aœciwoœci  funkcji,  któr¹  jest,  ca³kowicie

naturalna,  mo¿liwoœæ  tworzenia  zmiennych

lokalnych  praktycznie  nieistniej¹cych  poza

funkcj¹. Zobaczysz ju¿ nied³ugo, jak wygod-

ny  jest  brak  koniecznoœci  zastanawiania  siê,

czy gdzieœ indziej nie wykorzystujê tej w³aœ-

nie zmiennej. 

Jednak koñcz¹c zachwalaæ to, co dopiero

przedstawiê  w  przysz³oœci,  przechodzê  do

rzeczy. Dziœ przedstawiam ca³kowite podsta-

wy,  umo¿liwiaj¹ce  stworzenie  programu

dok³adnie  takiego,  jak  chcieliœmy:  licz¹cego 

i  wyœwietlaj¹cego  kolejne  liczby  w  kodzie

heksadecymalnym.  Jak  zwykle  proponujê

zapoznanie  siê  z  ramk¹  zawieraj¹c¹  odpo-

wiednie informacje. Tym razem jest to ramka

z informacjami o podstawach tworzenia oraz

korzystania z funkcji.

Pamiêtasz  mo¿e  moje  pytanie  na  koñcu

poprzedniej  czêœci?  Jeœli  podj¹³eœ  wtedy

wyzwanie  i  stworzy³eœ  tablicê  zawieraj¹c¹

wygl¹d  wszystkich  cyfr  kodu  szesnastkowe-

go, masz teraz okazjê porównaæ swoje dzie³o

z  moj¹  propozycj¹.  Ze  wzglêdu  na  objêtoœæ

pe³nego kodu Ÿród³owego oraz na to, ¿e wiele

elementów wci¹¿ siê nie zmienia, nie przed-

stawiam go w ca³oœci. Myœlê, ¿e jeœli opiszê

krok  po  kroku  wprowadzane  zmiany  –  nie

bêdziesz  mia³  problemów  z  przerobieniem

poprzedniego programu, a dodatkowo ³atwiej

przyjdzie zrozumienie nowego kodu. 

Na  pocz¹tek  zajmiemy  siê  stworzeniem

tablicy  zawieraj¹cej  wygl¹d  poszczególnych

znaków  na  wyœwietlaczu.  Ja  umieœci³em  j¹

"$

Programowanie

Elektronika dla Wszystkich

ABC... C

Wykorzystanie pamiêci 

programu w AVR-GCC

Oddzielna przestrzeñ adresowa dla danych i pro-

gramu  to  kolejny  element,  który  nie  jest  zgodny 

z ANSI C. Trzeba liczyæ siê z tym, ¿e w innym kom-

pilatorze problem ten mo¿e byæ rozwi¹zany zupe³-

nie inaczej!

Najwygodniejszym sposobem pos³ugiwania siê

pamiêci¹  programu  jest  wykorzystanie  nag³ówka

<avr\pgmspace.h>. Definiuje on wszystko, czego

potrzeba  do  umieszczenia  „zmiennych”  w  obsza-

rze programu oraz do dostêpu do nich. 

Pamiêtaj - jeœli chcesz wykorzystaæ w praktyce

informacje z tej ramki – koniecznie do³¹cz wspom-

niany plik do swojego programu za pomoc¹ dyrek-

tywy #include.

Jak tworzy栄zmienne”:

Wspomniany  wy¿ej  nag³ówek  daje  dwie  mo¿li-

woœci  poinformowania  kompilatora  o  naszym

¿yczeniu  specjalnego  potraktowania  zdeklarowa-

nej  w³aœnie  zmiennej.  Jednym  z  nich  jest  wyko-

rzystanie  s³owa  kluczowego PROGMEM.  W  ta-

kim przypadku deklaracja naszej tablicy wygl¹da-

³aby nastêpuj¹co:

uint8_t g_DaneCom[

4

] PROGMEM =

{~(

1

<<COM1)

(...)

};

S³owo  kluczowe  PROGMEM  umieszcza  siê

za deklaracj¹ „zmiennej”, ale przed jej inicjacj¹. 

Drug¹ mo¿liwoœci¹ jest wykorzystanie jednego

ze  specjalnych  typów  zmiennych,  jakie  deklaruje

do³¹czenie  pliku  pgmspace.h.  Pojawiaj¹  siê  tutaj

wszystkie  typy  zdeklarowane  w  pliku  inttypes.h

(przypominam,  zmienne  w  formie  [u]intN_t  –

czêœæ  2  kursu),  jednak  poprzedzone  dodatkowo

przedrostkiem prog_. Jak zwykle wszystko najle-

piej t³umaczy przyk³ad:

prog_uint8_t g_DaneCom[

4

] =

{~(

1

<<COM1)

(...)

};

To,  który  sposób  wyda  Ci  siê  wygodniejszy 

i  bardziej  czytelny,  zale¿y  tylko  i  wy³¹cznie  od

Twojego gustu. Ja praktycznie wykorzystujê obie

mo¿liwoœci naprzemiennie. 

Niezmienne zmienne? 

Zauwa¿ pewn¹ bardzo wa¿n¹ rzecz: jeœli tworzy-

my twór taki jak „zmienna” w pamiêci programu –

nie  mamy  mo¿liwoœci  zapisania  do  niej  danych,

mo¿emy z niej tylko czytaæ. Nie ma znaczenia to,

¿e niektóre z procesorów pozwalaj¹ na pisanie do

pamiêci programu – to jest zupe³nie inna historia.

Z punktu widzenia kompilatora zmienna w pamiê-

ci programu zawsze jest TYLKO DO ODCZYTU.

Aby  z  tworu  takiego  mieæ  jakikolwiek  u¿ytek,

konieczne jest pocz¹tkowe przypisanie mu war-

toœci.

(ci¹g dalszy w nastêpnej ramce...)

Rys. 23 Porównanie zu¿ycia pamiêci

Listing 13  Tablica zawieraj¹ca definicjê wygl¹du poszczególnych znaków

prog_uint8_t g_WzorCyfr[

16

] =

{

~(

1

<<LED_A |

1

<<LED_B |

1

<<LED_C |

1

<<LED_D |

1

<<LED_E |

1

<<LED_F),

// 0

~(

1

<<LED_B |

1

<<LED_C),

// 1

~(

1

<<LED_A |

1

<<LED_B |

1

<<LED_G |

1

<<LED_E |

1

<<LED_D),

// 2

~(

1

<<LED_A |

1

<<LED_B |

1

<<LED_C |

1

<<LED_D |

1

<<LED_G),

// 3

~(

1

<<LED_B |

1

<<LED_C |

1

<<LED_G |

1

<<LED_F),

// 4

~(

1

<<LED_A |

1

<<LED_F |

1

<<LED_G |

1

<<LED_C |

1

<<LED_D),

// 5

~(

1

<<LED_A |

1

<<LED_F |

1

<<LED_E |

1

<<LED_D |

1

<<LED_C |

1

<< LED_G),

// 6

~(

1

<<LED_A |

1

<<LED_B |

1

<<LED_C),

// 7

~(

1

<<LED_A |

1

<<LED_B |

1

<<LED_C |

1

<<LED_D |

1

<<LED_E |

1

<<LED_F |

1

<<LED_G),

// 8

~(

1

<<LED_G |

1

<<LED_F |

1

<<LED_A |

1

<<LED_B |

1

<<LED_C |

1

<<LED_D),

// 9

~(

1

<<LED_A |

1

<<LED_B |

1

<<LED_C |

1

<<LED_E |

1

<<LED_F |

1

<<LED_G),

// A

~(

1

<<LED_C |

1

<<LED_D |

1

<<LED_E |

1

<<LED_F |

1

<<LED_G),

// B

~(

1

<<LED_A |

1

<<LED_D |

1

<<LED_E |

1

<<LED_F),

// C

~(

1

<<LED_B |

1

<<LED_C |

1

<<LED_D |

1

<<LED_E |

1

<<LED_G), /

/ D

~(

1

<<LED_A |

1

<<LED_D |

1

<<LED_E |

1

<<LED_F |

1

<<LED_G),

// E

~(

1

<<LED_A |

1

<<LED_E |

1

<<LED_F |

1

<<LED_G) /

/ F

};

zaraz  za  ostatnio  zdeklarowan¹  zmienn¹

(g_DaneCom). Wpisz tutaj kod przedstawio-

ny na listingu 13. Jest to nic innego jak de-

klaracja  nowej  tablicy  w  pamiêci  programu.

Na kolejnych jej pozycjach znajduj¹ siê war-

toœci opisuj¹ce wygl¹d odpowiedniej cyfry.

Zajrzyj teraz na listing 14. Przedstawi³em

te czêœci kodu, które siê zmieni³y. Nie przepi-

suj ca³oœci od góry do do³u. Spróbujmy napi-

saæ  to  w  takiej  kolejnoœci,  w  jakiej  kod 

by³  tworzony.  Najpierw  przepisz  funkcjê

WyswietlHex. Umieœæ  j¹  nad  funkcj¹  main  –

umo¿liwi nam to unikniêcie pisania jej dekla-

racji. Funkcja nie jest optymalna. Ale zosta³a

napisana w taki sposób, aby nie wykorzysty-

waæ  nic  ponad  to,  co  do  tej  pory  zdo³a³em

przedstawiæ. 

Gdy funkcja ta jest ju¿ gotowa, zastanów-

my siê, co dalej. Chcemy zliczaæ i wyœwietlaæ

wartoœæ aktualnego zliczenia. Procesor oczy-

wiœcie  potrafi  dodawaæ  bardzo  szybko,  wiêc

aby  cokolwiek  widzieæ,  bêdziemy  musieli

troszkê spowolniæ jego dzia³anie. W tym celu

skorzystamy  z  funkcji  zawartych  w  pliku

<avr\delay.h>. Dodaj wiêc jeszcze i ten plik

do  naszego  programu  za  pomoc¹  dyrektywy

#include. 

Nastêpnie  stworzymy  zmienn¹  przecho-

wuj¹c¹ aktualnie zliczon¹ wartoœæ.  Ja umieœ-

ci³em  j¹  zaraz  za  ostatnio  dodan¹  tablic¹,

nadaj¹c jej nazwê g_Licznik.

W funkcji main nic nie zmieniamy w czêœ-

ci  odpowiedzialnej  za  inicjacjê.  Po  jej  zakoñ-

czeniu usuwamy jednak czêœæ odpowiedzialn¹

za  wyœwietlenie  na  wyœwietlaczach  sta³ych

cyfr, a w pêtli nieskoñczonej tworzymy pros-

ty  algorytm,  jak  na  listingu  14.  Uff...  jeœli

wszystko  siê  uda³o  –  po  przeprowadzeniu

kompilacji i za³adowaniu programu do proce-

sora  program  zacznie  dzia³aæ  zgodnie  z  na-

szym aktualnym ¿yczeniem. W razie proble-

mów pe³ne kody Ÿród³owe mo¿esz pobraæ ze

strony  internetowej  Elektroniki  dla  Wszyst-

kich. Korzystaj z nich œmia³o! Czasami lepiej

spojrzeæ na pe³ny kod i w ten sposób znaleŸæ

problem, ni¿ próbowaæ walczyæ z nim ambit-

nie a¿ do zniechêcenia. 

Podsumowanie

W  tym  odcinku  opowiedzia³em  Ci  o  tym, 

w  jaki  sposób  korzystaæ  z  przerwañ,  jak

umieœciæ  zmienn¹  w  pamiêci  programu 

i jak siê do niej dostaæ. Pozna³eœ praktyczne

wykorzystanie operatora adresowego &. Opo-

wiedzia³em Ci o instrukcji if oraz o specyficz-

nych  wyra¿eniach,  którymi  s¹  warunki.

Wreszcie  zaczêliœmy  zajmowaæ  siê  samo-

dzielnym tworzeniem funkcji.

W miêdzyczasie nasz program zosta³ roz-

winiêty i na koñcu sta³ siê czymœ w rodzaju

szesnastkowego  licznika  czasu.  Pisany  pro-

gram  jest  coraz  ciekawszy,  ale  oczywiœcie

mo¿na napisaæ go lepiej i bardziej wydajnie.

Czy  wiesz  w  jaki  sposób  zamiast  funkcji

_delay_loop_2  wykorzystaæ  do  generowania

opóŸnienia  nasze  przerwanie  wyœwietlacza,

czy wiesz jak poradziæ sobie z dwoma przy-

ciskami  znajduj¹cymi  siê  na  p³ytce?  Razem

zrobimy to ju¿ w nastêpnym odcinku.

"%

Programowanie

Elektronika dla Wszystkich

ABC... C

Dostêp do danych 

w pamiêci programu w AVR-GCC

W  AVR-GCC  nie  ma  mo¿liwoœci  wykorzystania

„zmiennych” umieszczonych w pamiêci programu

w taki sam sposób, jakby by³a to zwyk³a zmienna.

Gdy  ju¿  umieœciliœmy  nasz¹  tablicê  g_DaneCom 

w pamiêci programu, odwo³anie siê do niej w spo-

sób jak do tej pory:

nie  spowoduje  co  prawda  zg³oszenia  b³êdu

przez  kompilator,  jednak  zachowanie  programu

bêdzie  nieokreœlone.  Zostanie  wykonany  dostêp

do komórki pamiêci RAM o adresie takim, jaki

posiada nasza zmienna w obszarze ROM!

Makra pgm_read

Najprostszy dostêp do wartoœci zapisanych w pa-

miêci  programu  umo¿liwiaj¹  niewielkie  makra,

które udostêpnia nam plik <avr\pgmspace.h>. 

Maj¹ one postaæ: 

pgm_read_byte(adres)

pgm_read_word(adres)

pgm_read_dword(adres)

Pozwalaj¹ one na odczytanie z podanego adre-

su (kolejno) baitu, s³owa oraz podwójnego s³owa. 

Wyprzedzaj¹co warto zwróciæ uwagê, ¿e makra

te  umo¿liwiaj¹  dostêp  tylko  do  obszaru  64kB

pamiêci. Teraz nie ma to znaczenia, ale w przypad-

ku  potrzeby  dostêpu  do  danych  umieszczonych

powy¿ej 64kB w procesorze o wiêkszym rozmia-

rze pamiêci (na przyk³ad ATmega128), konieczne

jest  wykorzystanie  analogicznych  makr,  jednak 

z przyrostkiem _far – zajmuj¹ one wiêcej zasobów

oraz dzia³aj¹ wolniej, lecz umo¿liwiaj¹ dostêp do

obszaru  pamiêci  o  teoretycznym  rozmiarze  do

4GB, jednak przy uwzglêdnieniu

ich aktualnej implementacji, teo-

retycznie mo¿liwa do obs³u¿enia pamiêæ to „tylko”

16MB. 

Jeœli wiesz cokolwiek o asemblerze AVR, pro-

ponujê  Ci  zajrzenie  do  pliku  <avr\pgmspace.h> 

i przyjrzenie siê, jak wygl¹daj¹ opisane makra.

Funkcje z przyrostkiem _P

Warto wiedzieæ, ¿e praktycznie wszystkie funkcje

standardowe,    operuj¹ce  na  danych,  maj¹  swoje

odpowiedniki  z  przyrostkiem  _P.  Przyrostek  taki

oznacza, ¿e funkcja ta operuje na danych umiesz-

czonych  w  pamieci  programu.  Niewiele  jeszcze

mówi³em  o  funkcjach  sa-

mych  w  sobie,  nie  przej-

muj siê wiêc, jeœli ten aka-

pit  wydaje  siê  niejasny  –

temat zostanie rozwiniêty w niedalekiej przysz³oœ-

ci.

Operator adresu &

Przy  opisie  makr  dostêpu  do  pamiêci  beztrosko

wspomnia³em o tym, ¿e konieczne jest podanie im

adresu, pod jakim nasza zmienna siê znajduje. Nie

wdaj¹c siê aktualnie w szczegó³y, podam Ci jedy-

nie kuchenny przepis „jak uzyskaæ potrzebny nam

adres  jakiejkolwkiek  zmiennej”.  W  tym  celu

wykorzystujemy  operator  &.  Umieszczamy  go

przed nazw¹ zmienej. Ostro¿nie jednak z tablica-

mi. Okazuje siê, ¿e z punktu widzenia kompila-

tora, wszêdzie, gdzie u¿yjemy samej nazwy tab-

licy,  bêdzie  to  adres  jej  pierwszego  elementu!

Jednak  ju¿  wykorzystanie  nawiasów  kwadrato-

wych powoduje dostêp do odpowiedniej wartoœci.

Najlepiej jak zwykle wyjaœnia to przyk³ad. Poni¿-

sze zapisy s¹ równowa¿ne:

pgm_read_byte(&g_DaneCom[0]);

pgm_read_byte( g_DaneCom );

W  naszym  programie  prawid³owy  dostêp  do

pamiêci  programu  bêdzie  wygl¹da³  nastêpuj¹co

(porównaj  z  pierwszym  przedstawionym  w  tej

ramce listingiem):

COMPORT &= g_DaneCom[g_AktWyswietlacz];

COMPORT &=

pgm_read_byte(&g_DaneCom[g_AktWyswietlacz]);

Listing 14  Zmiany wprowadzone w program w celu wyœwietlania licznika

(...)

#include <avr\delay.h>

(...)

uint16_t g_Licznik =

0

;

// Funkcja wyœwietla w kodzie heksadecymalnym podan¹ liczbê

void

WyswietlHex(uint16_t var)

{

g_DaneWyswietlacza[

0

] = pgm_read_byte(&g_WzorCyfr[var>>(

3

*

4

)]);

g_DaneWyswietlacza[

1

] = pgm_read_byte(&g_WzorCyfr[(var>>(

2

*

4

))&

0xf

]);

g_DaneWyswietlacza[

2

] = pgm_read_byte(&g_WzorCyfr[(var>>(

1

*

4

))&

0xf

]);

g_DaneWyswietlacza[

3

] = pgm_read_byte(&g_WzorCyfr[var&

0xf

]);

}

// Start

int

main(

void

)

{

/////////////////////////////

(...) 

// koniec inicjacji

/////////////////////////////

for

(;;)

{

WyswietlHex(g_Licznik);

_delay_loop_2(

0xffff

);

g_Licznik++;

}

return

0

;

}

Elektronika dla Wszystkich

"&

Programowanie

ABC... C

Funkcje

Stworzenie nowej funkcji w C jest bardzo proste.

Tak naprawdê ca³y czas tworzymy przecie¿ funkc-

je. Do tej pory stworzyliœmy funkcjê main, oraz za

pomoc¹ makra, funkcjê obs³ugi przerwania. By³y

to  funkcjê  standardowe.  Teraz  rozwiniemy  temat

na  tyle,  aby  móc  utworzyæ  funkcjê  o  dowolnej

nazwie, dowolnych parametrach i dowolnej zwra-

canej wartoœci.

Na  obrazku  w  tej  ramce  pokaza³em  z  czego

sk³ada siê definicja funkcji. Przyk³adowa funkcja

zaczerpniêta z tworzonego aktualnie programu ma

za zadanie wyœwietliæ podan¹ liczbê w kodzie hek-

sadecymalnym. Nie skupiamy siê teraz na tym, jak

ona  dzia³a,  wa¿ne  jest  to,  jak  zosta³a  zapisana.

Funkcja  sk³ada  siê  z  informacji  dla  kompilatora,

jak¹ wartoœæ zwraca. Czêsto, zamiast mówiæ opiso-

wo, ¿e funkcja zwraca wartoœæ typu (przyk³adowo)

int,  mówimy  prosto,  ¿e  funkcja  jest  typu  int. 

W naszym przypadku u¿ywamy void. Jest to bar-

dzo specyficzny typ wartoœci, który... nie istnieje.

W ten sposób informujemy kompilator, ¿e funkcja

nie  zwraca  wartoœci.  Jeœli  pisa³eœ  programy 

w BASCOM-ie, mo¿e zakrzykniesz teraz – to ju¿

znamy  –  tylko  do  tej  pory  funkcjê  niezwracaj¹c¹

danych nazywaliœmy procedur¹ (SUB). Znakomi-

cie, jeœli zauwa¿asz analogiê. Teraz jednak zarów-

no  procedury,  jak  i  funkcjê  tworzy  siê  tak  samo.

Ró¿nica w zapisie polega tylko na poinformowa-

niu  kompilatora,  ¿e  nie  chcemy  zwracaæ  ¿adnej

wartoœci. 

Nastepnie  pojawia  siê  nazwa  funkcji.  Jest  to

identyfikator, wiêc nie mo¿e zaczynaæ siê od cyfry.

Poza tym mo¿e zawieraæ wszystkie litery alfabetu,

jednak bez polskich „ogonków”. Dodatkowo mo¿na

wykorzystaæ znak podkreœlenia. Przypominam, ¿e

rozmiar  liter  ma  znaczenie.  Z  tego  identyfikatora

bêdziemy korzystaæ w celu wywo³ania funkcji. 

Zaraz  za  identyfikatorem,  w  nawiasach,

umieszczamy wymagane przez funkcjê parametry.

Jeœli potrzebujemy wiêcej ni¿ jednego parametru,

oddzielamy je przecinkami. Kolejno podajemy typ

zmiennej, nastêpnie jej nazwê. Wa¿ne jest, ¿e para-

metry te bêd¹ dostêpne tylko i wy³¹cznie dla two-

rzonej funkcji. Uwa¿aj – aby nie nadaæ parametro-

wi  nazwy  jakiejœ  zmiennej  globalnej.  Przeciwnie

do BASCOM-a, tutaj nie tylko nie jest to wymaga-

ne, ale wrêcz niewskazane. 

Miêdzy nawiasami klamrowymi umieszczamy

cia³o  funkcji,  czyli  po  prostu  opis  jej  dzia³ania.

Mo¿emy wykorzystaæ teraz wszelkie funkcje stan-

dardowe, wywo³aæ inn¹ w³asn¹ funkcjê, a nawet –

funkcja  mo¿e  wywo³aæ  sam¹  siebie...  Tak  czy

inaczej – cia³o funkcji pisaliœmy ju¿ kilka razy, tak

wiêc nie jest to ju¿ niczym nowym. 

Parametry

Parametry  w  C  przesy³ane  s¹  poprzez  wartoœæ.

Oznacza to, ¿e funkcja nie ma dostêpu do zmien-

nych  na  poziomie  funkcji  wywo³uj¹cej.  Mo¿na

wiêc z przes³anych danych korzystaæ do woli. Jak

do zwyk³ej zmiennej mo¿esz wpisaæ tutaj na przy-

k³ad  wynik  cz¹stkowy  jakiegoœ  obliczenia...  Na

pewno nie zmieni to wartoœci zmiennej w funkcji

wywo³uj¹cej. 

Wywo³anie 

w³asnej funkcji

Gdy  mamy  ju¿  utworzon¹

w³asn¹  funkcjê,  potrzebujemy

jeszcze mo¿liwoœci jej wywo-

³ania.  Okazuje  siê,  ¿e  jest  to

bardzo intuicyjne. Nie ma ró¿-

nicy  pomiêdzy  sposobem

wywo³ywania  w³asnej  funkcji

a  jednej  z  funkcji  standarto-

wej, z jakich korzystaliœmy do

tej  pory.  Tak  wiêc  wywo³anie

naszej  funkcji  przebiegnie

nastêpuj¹co: 

WyswietlHex(wartosc);

Wartoœæ w nawiasach mo¿e byæ ró¿nego typu.

Mo¿e  byæ  to  zmienna,  mo¿e  byæ  wartoœæ  sta³a,

mo¿e  byæ  ca³e  wyra¿enie...  Co  bardzo  ciekawe,

mo¿na tutaj tak¿e wywo³aæ inn¹ funkcjê. Za³ó¿my

czysto teoretycznie, ¿e chcemy wyœwietliæ wartoœæ

jakiejœ  „zmiennej”  umieszczonej  w  pamiêci  pro-

gramu.  Jak  pokazywa³em  wczeœniej,  w  tym  celu

konieczne  jest  wykorzystanie  makra  pgm_read.

Przyk³ad  takiego  dzia³ania  przedstawia  poni¿szy

pseudokod  (dzia³aj¹cy  przyk³ad  udostêpniam  na

stronie internetowej):

W ten sposób podaliœmy jako parametr naszej

funkcji  wynik  dzia³ania  innej  funkcji.  Istnienie

takiej mo¿liwoœci sprawia, ¿e mo¿emy oszczêdziæ

na  zmiennych  tymczasowych.  Inaczej  konieczne

by³oby utworzenie dodatkowej zmiennej, wpisanie

do niej wyniku dzia³ania funkcji odczytu z pamieci 

programu  i  dopiero  przes³anie  tej  zmiennej  do

wyœwietlania. 

Z drugiej strony, w bardzo z³o¿onych przypad-

kach,  rozwi¹zanie  ze  zmienn¹  tymczasow¹  mo¿e

znacznie uproœciæ zapis. Pamiêtaj wtedy, ¿e przed-

stawiona przed chwil¹ mo¿liwoœæ jest tylko mo¿li-

woœci¹.  C  nie  zmusza  nikogo  do  pisania  w  taki, 

a nie inny sposób. 

Deklaracja i definicja

Powinno  pojawiæ  siê,  ju¿  nawet  wczeœniej,  pyta-

nie: „No dobrze... ale czy funkcjê mo¿na wywo³aæ

ot  tak  sobie:  zawsze  i  w  dowolnym  miejscu?”.

OdpowiedŸ jest bardziej ni¿ oczywista: „Niestety,

nie  mo¿na”.  Zanim  funkcja  zostanie  wywo³ana,

musi  byæ  zdeklarowana.  Deklaracja  funkcji  to

powiadomienie kompilatora o tym, ¿e dana funkc-

ja istnieje oraz o tym, jakie przyjmuje paremetry.

Od strony „kuchennej” deklaracja to nic innego jak

powtórzona nazwa funkcji, razem z jej typem oraz

informacj¹  o  parametrach.  Deklaracja  jednak 

w odró¿nieniu od definicji nie zawiera cia³a funkc-

ji. Zamiast tego, zaraz za nawiasem z parametrami,

umieszczamy znak œrednika. Jest to konieczne, aby

kompilator  wiedzia³  o  co  chodzi  i  nie  szuka³  po-

cz¹tku cia³a funkcji. 

Uwa¿aj  teraz.  Okazuje  siê,  ¿e  zdefiniowanie

funkcji oznacza tak¿e jej zdeklarowanie. Sprawa

jest prostsza, ni¿ wynika³oby ze skomplikowania

poprzedniego  zdania.  Oznacza  to  tylko  tyle,  ¿e

jeœli  definiujesz  funkcjê  (przypominam  –  stwo-

rzysz pe³ny opis razem z opisem dzia³ania) przed

miejscem  jej  wywo³ania,  nie  jest  konieczne

umieszczanie  nigdzie  jej  deklaracji.  Dlatego  te¿

czêsto funkcjê main umieszcza siê na koñcu. Dziê-

ki temu unikamy wpisywania dodatkowych linijek

kodu.  Jednak  nie  zawsze  umieszczanie  definicji

ponad miejscem wywo³ania jest wygodne. Czasa-

mi mo¿e okazaæ siê nawet niemo¿liwe. Deklarac-

jê  w  takim  przypadku  umieszcza  siê  najczêœciej

zaraz  za  lub  zaraz  przed  zmiennymi  globalnymi.

Ogólniej  –  ju¿  po  do³¹czeniu  wszystkich  plików

nag³ówkowych, ale jeszcze przed definicj¹ jakiej-

kolwiek funkcji. 

Ogólnie ilustruje to poni¿szy obrazek (pseudo-

kod):

prog_uint16_t g_Stala =

0xcdef

;

(...)

WyswietlHex(pgm_read_word(&g_Stala));

Rados³aw Koppel