Programowanie

Programowanie procesorów
w języku C
Po początkowych próbach nadążania za zmia-
nami w WinAVR, trzymaliśmy się cały czas
wersji 20060125. Obecnie wersja ma ponad
część 17
wszystkie zmiany na podstawie dokumenta- Najważniejsze zmiany w wersji
cji. Zwykle więc posługujemy się drogą na 20070122
skróty. Below is just a sample of what’s new.

półtora roku. Ponieważ ta część jest częścią
przedostatnią, chcę pokazać Ci prostą metodę
postępowania przy dostosowywaniu kodu do
ewentualnych zmian, jakie pojawiają się
w WinAVR.
Jak samemu dostosować
Spośród napisanych programów, niewiele
jest takich, które nie pozwolą skompilować się
bez żadnych zmian. Weźmy na warsztat pro-
gram testujący funkcję printf – drugi program
z części 7. Problem, który tu występuje, już
przerabialiśmy, jednak jego kod umożliwia
przedstawienie metody postępowania. Ponadto
• Major version change for GCC. Now at version
4.1.1.
• Support for the ATmega2560, and ATmega2561 de-
vices.
• Change the DWARF2 debug information from 16-bit
addresses to 32-bit addresses. This now allows de-
bugging of code above 64K, including bootloaders
for the ATmega128 and ATmega1281, and debug-

program do nowej wersji

narzędzia WinAVR
Proponuję, abyś teraz przeszedł do strony
http://winavr.sourceforge.net i pobrał najnow-
szą wersję WinAVR. W chwili pisania tekstu
była to wersja 20070122.
Po instalacji, pierwszy plik, do którego po-
winniśmy zajrzeć, to WinAVR-user-manual
(wersja txt albo html). Najbardziej interesuje
nas sekcja 1.0 What’s New. Tutaj znajdziemy
najważniejsze informacje o zmianach. Odpo-
wiedni fragment przedstawia ramka obok.
Zmiana w GCC ma dla nas znaczenie od
strony optymalizacji kodu. Składnia C się
przecież nie zmienia, a sam kompilator nie za-
wiera dodatkowych bibliotek.
Wsparcie dla nowych procesorów, które
mają 256kB pamięci, to przede wszystkim
miła niespodzianka. Wymusza jednak kolej-
ną, tym razem ważną dla nas zmianę: zmienia
się format pliku używanego do symulacji pro-
gramu. Jeśli korzystamy z AVRStudio, wy-
maga to posiadania programu w wersji przy-
najmniej 4.13. We wcześniejszej wersji, pod-
czas wczytywania pliku, otrzymamy komuni-
kat o błędzie.
Nowa biblioteka avr-libc to bardzo ważny
element naszego środowiska. Zmiany w tym
miejscu dotyczą funkcji standardowych,
z których cały czas korzystamy. Musimy mieć
więc świadomość, że w ich wywołaniach mo-
gły pojawić się zmiany.
Reszta wypisanych tutaj zmian nie ma dla
nas wielkiego znaczenia. Wiemy teraz, że
szczególną uwagę musimy zwrócić na funk-
cje z biblioteki avr-libc oraz na posiadanie
nowej wersji AVRStudio.
Dwa podejścia...
Do zagadnienia możemy teraz podejść na dwa
sposoby. Pierwszy, który nazwałbym właści-
wym, to zajrzenie do dokumentacji avr-libc
i przeczytanie o dostępnych funkcjach oraz
zmianach. Zazwyczaj jednak chcemy uzyskać
efekt szybko, ponadto trudno wychwycić
ging of the ATmega2560 and ATmega2561 devices.
otrzymałem pytania, dlaczego nie da się pro- This requires a version of AVR Studio that has a new
gramu skompilować z nowym kompilatorem. ELF/DWARF2 parser (> 4.12).
Sprawdźmy, czy kompilator „przełknie” • New avr-libc version with new examples, updated
examples, many bugs fixed, and new APIs for Power
program bez żadnych zmian. Przed pierwszą Reduction and Clock Prescaler.
kompilacją wykonujemy czyszczenie pro- • New avrdude version with libusb support, which al-
jektu – zapobiegnie to sytuacji, gdy część pli- lows connections to the AVR ISP mkII.
ków kompilowana jest nową wersją kompila- • New avarice version with libusb support, which al-
tora, a część pozostaje w starej wersji. Otrzy- lows connections to the AVR JTAG ICE mkII.
mamy błędy widoczne na listingu 223. • New versions for Binutils and SRecord.
• Updates to the WinAVR Makefile Template and
Gdy klikniemy fioletową linię błędu, zosta- MFile.
Listing 223 Błędy podczas kompilacji programu z części 7
Compiling: main.c
avr-gcc -c -mmcu=atmega162 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,
-adhlns=main.lst -std=gnu99 -MD -MP -MF .dep/main.o.d main.c -o main.o
main.c: In function ‘main’:
main.c:28: warning: passing argument 1 of ‘fdevopen’ from incompatible pointer type
main.c:28: warning: passing argument 2 of ‘fdevopen’ from incompatible pointer type
main.c:28: error: too many arguments to function ‘fdevopen’
make.exe: *** [main.o] Error 1
Listing 224 Funkcja fdevopen
#if defined(__STDIO_FDEVOPEN_COMPAT_12)
/*
* Declare prototype for the discontinued version of fdevopen() that
* has been in use up to avr-libc 1.2.x. The new implementation has
* some backwards compatibility with the old version.
*/
extern FILE *fdevopen(int (*__put)(char), int (*__get)(void),
int __opts __attribute__((unused)));
#else /* !defined(__STDIO_FDEVOPEN_COMPAT_12) */
/* New prototype for avr-libc 1.4 and above. */
extern FILE *fdevopen(int (*__put)(char, FILE*), int (*__get)(FILE*));
#endif /* defined(__STDIO_FDEVOPEN_COMPAT_12) */
niemy przeniesieni do linii, w której błąd się Listing 225 Zmiana w programie z części 7
pojawił. Nie zmieniajmy jej teraz pochopnie. #define __STDIO_FDEVOPEN_COMPAT_12
Przekonamy się, że błąd tkwi w innym miej- #include <stdio.h>
scu. Po pierwsze, znajdujemy opis funkcji
fdevopen z biblioteki stdio.h. gramie, przed dołączeniem nagłówka stdio.h
Informacje znajdziemy zarówno w odpo- umieszczamy linię, jak na listingu 225.
wiednim pliku nagłówkowym, jak i w doku- To najprostsze rozwiązanie, aby skompilo-
mentacji avr-libc. Okazuje się, że funkcja wać program. Oczywiście lepszym wyjściem
zmieniła swoją składnię i teraz funkcje rs_put byłoby odpowiednie zmienienie wywołania
i rs_get powinny mieć inną formę. Ponadto fdevopen oraz zmiana funkcji rs_put i rs_get.
usunięty został trzeci, nieużywany parametr. Później, gdy wczytamy się w dokumentację,
Linie opisujące funkcje fdevopen, znajdu- dojdziemy do wniosku, że inicjacji strumieni
jące się w pliku <stdio. h>, pokazuje listing można dokonać, rezygnując w ogóle z pamię-
224. Widzimy tutaj furtkę, jaką pozostawili ciożernej funkcji fdevopen. Teraz zależy nam
twórcy nowej wersji WinAVR. W naszym pro- jedynie na poznaniu sposobu postępowania.

40 E l e k t ro n i k a d l a Ws z y s t k i c h

Zbierzmy wszystko w punkty:
Postępując według schematu, być może
czasem podpierając się słownikiem, bę-
1. Czyszczenie projektu
2. Kompilacja
3. Sprawdzenie błędów i zajrzenie do
dokumentacji albo pliku nagłówkowego,
co się zmieniło w „spornej” funkcji?
4. Dostosowanie funkcji do wymagań no-
wej biblioteki i powrót do punktu 2.
dziesz w stanie samodzielnie obejść pro-
blem przejścia do nowej wersji WinAVR
gdy tylko taki się pojawi.
%s – wskaźnik na łańcuch w pamięci RAM,
wypisanie łańcucha.
%S – wskaźnik na łańcuch w pamięci progra-
mu, wypisanie łańcucha.
Program napiszemy na podstawie naszej
przeglądarki z poprzedniego odcinka. Ponie-
waż nie wypisywaliśmy jeszcze tekstu na na-
szym kolorowym wyświetlaczu, w dodatko-
wej ramce wyjaśniam, w jaki sposób się do te-
ABC... C
Otwarta (niepełna) lista argumentów
albo
Zmienna długość linii argumentów
Programowanie
go zabierzemy.
Resztę wyjaśnia ramka o otwartej liście ar-
gumentów oraz listingi 229 i 230.
Naszą funkcję piszącą możemy teraz wy-
korzystać, aby na pokazywanym obrazku wy-
pisać dodatkowe informację – dodamy linijkę
do funkcji app_DrawImg – listing 231.
Jak widzisz, obsługa tego tworu okazuje
się stosunkowo prosta.
va_end (va_list) – czyści wszystko, co jest do wy-
czyszczenia i pozwala na powrót z funkcji o zmiennej li-
ście argumentów, tak jakby to była zwyczajna funkcja.
Ograniczenia
Makro va_end powinno być wywoływane wyłącznie po

Pozostały zakres materiału
Z założonego materiału zostało nam do omó-
wienia kilka przydatnych drobiazgów. Do tej
pory pisaliśmy o tym, jak korzystać z funkcji
o otwartej liście argumentów, takiej jak printf.
Teraz dowiesz się, jak wykorzystać trzy krop-
ki we własnych konstrukcjach.
Później opowiem o kilku rzadziej używa-
nych, ale czasem bardzo przydatnych funkcjach.
Oto właściwa deklaracja funkcji z niepełną listą argu-
mentów:
void funkcja (char *str, ,...);
Trzy kropki oznaczają, że w tym miejscu może wy-
stąpić nieokreślona liczba argumentów. Symbol trzech
kropek umieszczamy zawsze jako ostatni argument.
Obsługa
Sztuka polega na tym, aby odszukać w pamięci przesłane
argumenty. W przypadku C służą do tego makra oraz spe-
cjalny typ zmiennej deklarowane w pliku <stdarg.h>.
Przedrostek va_ pochodzi od słowa varargs.
odczytaniu wszystkich parametrów przesłanych do funk-
cji (va_list musi wskazywać na miejsce za ostatnim argu-
mentem). Niespełnienie tego warunku może spowodo-
wać nieokreślone zachowanie programu.
Wszystkie parametry przekazywane przez zmienną
listę argumentów, są przesyłane z użyciem „starej promo-
cji argumentów języka C”. Promocja ta mówi, że typy
char, short int są automatycznie promowane do typu int.
Typ float jest promowany do typu double. W związku
z tym błędem jest ustawienie char, short int albo float
w miejscu drugiego parametru funkcji va_arg.
Trzeba zdawać sobie sprawę z faktu, że w AVR-GCC

Funkcja z otwartą listą
argumentów
Napiszemy teraz funkcję tworzącą na ekranie
formatowane wyjście. Będzie to pewna okro-
jona forma funkcji printf. Jej składnia będzie
identyczna, jednak będziemy przyjmować je-
dynie następujące formaty:
%d – wartość typu int, wypisanie w formie
dziesiętnej.
%c – wartość znakowa, wypisanie znaku.
va_list – jest to typ zmiennej wskazującej na aktual-
ną pozycję w liście argumentów nieustalonych.
va_start (va_list, str) – funkcję tę wywołujemy
w celu zainicjowania zmiennej typu va_list. Drugi para-
metr to mnemonik ostatniego argumentu ustalonego –
przed trzema kropkami. Jeśli przejdziemy już przez całą
listę argumentów, ponowny dostęp do pierwszego argu-
mentu jest możliwy po ponownym wywołaniu funkcji.
va_arg (va_list, typ) – powoduje pobranie argumen-
tu podanego typu oraz odpowiednie przesunięcie wskaź-
nika listy argumentów.
zmienna lista argumentów przesyłana jest przez stos (jest
to jednocześnie najczęstsze rozwiązanie stosowane
w praktyce). Nie ma możliwości umieszczenia takich pa-
rametrów w rejestrach. Sprawia to, że wywołanie tego ty-
pu funkcji zajmuje więcej zasobów niż w przypadku
funkcji o określonej liczbie parametrów.
Dodatkowym ograniczeniem jest też fakt, że kompi-
lator nie jest w stanie pilnować czy parametry przesłane
do funkcji są prawidłowe – należy pilnować tego we wła-
snym zakresie.
Przykłady: listing 229 i 230.

Idea rozwiązania Funkcja rysująca linie znaku: danych. W tym pierwszym przypadku należy ustawić fla-
Na listingu 226 pokazana jest funkcja, która zamienia li- gę LCD_TM_FLASH. Aby uprościć sobie dalszą pracę,
Proste pisanie tekstu na ekranie ko- nię znaku na dane wpisywane bezpośrednio do bufora. Za- znak z łańcucha będziemy pobierać za pomocą funkcji
lorowym uważ możliwość podania zarówno koloru tła, jak i koloru pomocniczej widocznej na listingu 228.
znaku. Ponadto, jeśli w parametrze mode
ustawiono flagę LCD_TM_TRANSPA- Listing 227 Wypisanie znaku
Pisanie na ekranie kolorowym wykonamy teraz w oparciu
RENT, tło będzie przezroczyste (nie będzie
o czcionkę statyczną, z której korzystaliśmy w części 13. uint8_t lcd_DrawChar(uint8_t x, uint8_t y, char znak,
wypisywane).
Wykorzystamy dokładnie tę samą tablicę z definicją wy- lcd_pixel charcolor, lcd_pixel bkcolor, uint8_t mode)
Funkcja oznaczona jako statyczna, po- {
glądu znaków. Jedyna różnica jest taka, że o ile poprzed-
nieważ w założeniu nie będzie wywoływana // Jeśli znak nie mieści się w tablicy...
nio bajt opisujący jedną linię znaku był wpisywany bezpo- if(znak < ‘ ‘ ||
spoza modułu LCD. Umożliwia to kompila-
średnio do bajtu w buforze obrazu, teraz będziemy musie- znak > ((char)’ ‘ + ELEMS(lcd_Font)))
torowi optymalizację jej wywołania. znak = ‘#’;
li rozłożyć go na pojedyncze piksele – w naszym koloro-
// Wysyłam 5 kolejnych bajtów z tablicy
wym wyświetlaczu jeden bajt odpowiada jednemu pikse-
Wypisanie znaku: uint8_t n;
lowi. prog_uint8_t* pData = lcd_Font[znak - ‘ ‘];
Mając funkcję wypisującą linię znaku, dalej
postępujemy już bardzo podobnie jak // wysyłanie danych
Listing 226 Wypisanie linii znaku przy pisaniu na wyświetlaczu czarno- for(n=0; n<5; n++)
-białym. Funkcję wypisującą znak poka- {
uint8_t data = pgm_read_byte(pData++);
static void lcd_DrawCharLine(uint8_t x, zuje listing 227. W razie wątpliwości zaj- lcd_DrawCharLine(x, y, data,
uint8_t y, uint8_t data, rzyj do części 13 – listing 227 to przerób- charcolor, bkcolor, mode);
lcd_pixel charcolor, lcd_pixel bkcolor, ++x;
uint8_t mode) ka listingu 169.
}
{
return x;
uint8_t n; Wypisanie całego }
for(n=0; n<8; n++)
{ łańcucha:
if(data & 0x01) Nie przedstawiam tutaj funkcji
lcd_Pixel(x, y, charcolor); Listing 228
wypisującej cały łańcuch zna-
else if(!(mode & LCD_TM_TRANSPARENT)) Pobieranie znaku z łańcucha umieszczonego w wybranej pamięci
lcd_Pixel(x, y, bkcolor); ków – podobne procedury pisa-
++y; liśmy już wielokrotnie. Nasza static uint8_t lcd_GetCharFromStr(char *str, uint8_t mode)
data >>= 1; funkcja różni się jednak o tyle, {
} return (mode & LCD_TM_FLASH) ? pgm_read_byte(str) : *str;
że może czytać łańcuch z pa- }
}
mięci programu albo pamięci

E l e k t ro n i k a d l a Ws z y s t k i c h 41
 Programowanie
Oszczędzanie energii
Do tej pory zupełnie nie przejmowaliśmy się Listing 229 Funkcja lcd_Printf

zużyciem energii przez układ. Nie ma w tym // Zwraca: pozycję x za ostatnio napisanym znakiem.
uint8_t lcd_Printf(uint8_t x, uint8_t y, char *str,
nic dziwnego – nasza płytka nie została utwo- lcd_pixel charcolor, lcd_pixel bkcolor, uint8_t mode, ...)
rzona do wielkiego oszczędzania mocy. Jed- {
// Inicjacja
nak pomyślmy teraz, co zrobić, gdy procesor va_list arg;
kręci się w pętli, czekając na jakieś zdarzenie? va_start (arg, mode);
Możemy przecież wprowadzić go w jeden ze // Pętla wypisywania łańcucha
stanów obniżonego poboru mocy. Pokażę Ci for(;;str++)
{
za moment, że dodając do naszej przeglądarki
zaledwie kilka linii, można uzyskać zaskaku- char znak;
// Wczytanie danej łańcucha
jące oszczędności. znak = lcd_GetCharFromStr(str, mode);
Wynik pomiaru prądu, pobieranego przez // Zakończenie funkcji, jeśli koniec łańcucha
if(znak == 0)
układ, w przypadku wyświetlania obrazka, break;
przy odłączonych wszelkich przewodach // Obsługa znaków specjalnych
if(znak == ‘%’)
oprócz zasilającego, pokazuje fotografia 12. {
(Listing 230 !!!)
Napięcie zasilania ograniczono do 4,1V, aby }
zminimalizować prąd płynący przez zabez- // Wypisanie zwyczajnego znaku
else
pieczającą diodę Zenera. {
W naszym programie są dwa miejsca, // Wypisanie znaku
x = lcd_DrawChar(x, y, znak, charcolor, bkcolor, mode);
gdzie procesor czeka na jakieś zdarzenia. Oba }
znajdują się w pliku system.c. Są to funkcje // Wypisanie przerwy
lcd_DrawCharLine(x, y, 0, charcolor, bkcolor, mode);
system_delayMake oraz system_msgWaitFor. ++x;
Co bardzo ważne, zdarzenie, na jakie czekają }
// Wyczyszczenie wszystkiego, co wymaga wyczyszczenia
funkcje, będzie ustawione w obsłudze prze- va_end (arg);
rwania. Możemy więc spokojnie przełączyć
return x;
procesor w tryb IDLE, w którym pobiera on }
2x mniej prądu.
W obu wspomnianych funkcjach
Listing 230 Pobieranie argumentów w funkcji lcd_Printf Listing 231 Wypisanie informacji o obrazku
znajdują się pętle z pustym ciałem.
W obu przypadkach w ciało pętli znak = lcd_GetCharFromStr(++str, mode);
switch(znak)
(...)
wpiszemy zawartość listingu 232. { lcd_Printf(0, 0, PSTR(„Obrazek %d z %d“),
0x1c, 0, LCD_TM_FLASH, index+1, imgl_GetSize());
Konieczne będzie dodanie pliku na- case{ ‘d’: // Odmalowanie ekranu
lcd_Update();
główkowego <avr/sleep.h>. int d = va_arg(arg, int);
char bufor[6];
Już taka prosta modyfikacja, któ-
ra zajęła nam może minutę czasu, x = lcd_DrawText(x, y, Listing 232 Usypianie procesora w czasie czekania na przerwanie
itoa(d, bufor, 10), charcolor,
pozwoli na widoczne wydłużenie bkcolor, mode & ~LCD_TM_FLASH); while(...)
czasu pracy urządzenia na bateriach. } {
break; set_sleep_mode(SLEEP_MODE_IDLE);
Fotografia 13 pokazuje nowy wy- case ‘c’: sleep_mode();
nik pomiaru zużycia prądu. // Uwaga - dajemy int nie char!!! }
znak = va_arg (arg, int);
Ale może taka oszczędność nam x = lcd_DrawChar(x, y, znak,
Listing 233 Makra włączające i wyłączające pamięć RAM
nie wystarczy? charcolor, bkcolor, mode);
break;
Co prawda nie dotyczy to już sa- case ‘s’: #define ram_Enable() PORTC &= ~(1<<7);
mego WinAVR, a raczej metodolo- case ‘S’: #define ram_Disable() PORTC |= (1<<7);
{
gii postępowania... sporo mocy po- char *str;
biera aktywna cały czas, zewnętrzna uint8_t mode_s = mode & ~LCD_TM_FLASH;
if(znak == ‘S’)
Listing 234 Wyłączanie pamięci w funkcji app_run
pamięć RAM. A przecież przez mode_s = mode | LCD_TM_FLASH;
for(;;)
str = va_arg (arg, char*);
większość czasu w ogóle się do niej x = lcd_DrawText(x, y, str,
{
// Aktywacja interpretera komend
nie odwołujemy. Dla prostoty jednak charcolor, bkcolor, mode_s);
system_enableUARTCommand();
}
ustawiliśmy na sztywno stan ‘0’ na break;
uint8_t msg;
wyprowadzeniu A15, połączonym case ‘%’: ram_Disable();
x = lcd_DrawChar(x, y, znak,
z wejściem /CE pamięci. Dodajmy charcolor, bkcolor, mode);
msg = system_msgWaitFor();
ram_Enable();
do pliku harddef. h dwa proste ma- break;
(...)
}
kra, widoczne na listingu 233.

Fot. 13 Pobór prądu, usypianie Fot. 14 Pobór prądu, usypianie proce-

Fot. 12 Pobór prądu, oryginalnie procesora, gdy nie pracuje sora oraz wyłączanie pamięci RAM

42 E l e k t ro n i k a d l a Ws z y s t k i c h
 Nie będziemy teraz zastanawiać się spe-
cjalnie, gdzie dostęp do pamięci jest ko-
nieczny, a gdzie nie. Założymy, że pamięć
RAM jest domyślnie uruchomiona w funk-
cji main – tak jak to było do tej pory. Wyłą-
czać ją będziemy na czas czekania na zda-
rzenie w module aplikacji. Zmienimy więc
fragment funkcji app_run widoczny na
listingu 234.
Obie opisane zmiany, chociaż bardzo
proste, umożliwiły zejście z poborem prądu
do wartości widocznej na fotografii 14. My-
ślę, że zestawienie fotografii mówi samo za
siebie, że warto czasem, po napisaniu pro-
gramu, przyjrzeć się, gdzie można oszczę-
dzić trochę mocy. Tym bardziej, jeśli spore
oszczędności uzyskamy praktycznie za
darmo.
Timer watchdog – bezpie-
czeństwo aplikacji
Poza oszczędzaniem mocy, powinniśmy
zwrócić także uwagę na bezpieczeństwo pra-
cy naszego programu. Trzeba zdawać sobie
z tego sprawę, że każdy, nawet najlepiej napi-
sany program, może ulec zawieszeniu. Nieko-
niecznie musi być to związane z błędem pro-
gramu – czasem wystarczy zakłócenie na li-
niach zasilania albo silny impuls EM.
Jeśli urządzenie się zawiesi, możemy za-
działać tak, aby użytkownik tego nie odczuł al-
bo przynajmniej zdarzenie takie nie było zbyt
uciążliwe (na przykład wyjście do menu głów-
nego, ale zachowanie właściwego odliczania
czasu i działania ustawionych alarmów).
W tym przypadku pomoże nam watchdog ti-
mer i odpowiednia reakcja na występujące
z niego zerowanie. Zwykle będzie to polegało
na pozostawieniu zawartości kluczowych dla
aplikacji zmiennych – możemy sprawdzić je-
dynie, czy ich wartości są prawidłowe (przy-
pomnij sobie, co pisaliśmy o sekcji .noinit).
Wróćmy do naszego programu generowa-
nia płomienia. Zabezpieczmy jego działanie
watchdogiem. Prosta kontynuacja pracy bę-
dzie polegała na tym, że pamięć obrazu nie
będzie czyszczona w przypadku wystąpienia
„awaryjnego” zerowania.
Sprawdźmy, jaki czas powinniśmy dać so-
bie na zerowanie watchdoga. Eksperymental-
nie, za pomocą symulacji w AVRStudio, mo-
żemy sprawdzić, że przy 8MHz zegarze czasy
wykonania poszczególnych fragmentów kodu
kształtują się następująco:
Od uruchomienia do zakończenia inicjacji:
67ms/67ms (sprzętowy SPI/programowy SPI).
Pojedynczy przebieg pętli głównej:
146ms/187ms.
ABC... GCC
Sterowanie trybami obniżonego po-
boru mocy
W przypadku procesorów AVR powstało kilka różnych
zestawów rejestrów służących do przełączania ich w tryb
obniżonego poboru mocy. Wszystko zależy od modelu.
Jednak korzystając z WinAVR nie musimy się tym przej-
mować – wszystkie wersje obsługiwane są przez iden-
tyczne funkcje.
Aby wymienione niżej funkcje były dostępne, ko-
nieczne jest dołączenie do programu pliku <avr/sleep.h>.
Definiowane stałe oznaczające poszczególne tryby:
SLEEP_MODE_ADC
SLEEP_MODE_EXT_STANDBY
SLEEP_MODE_IDLE
SLEEP_MODE_PWR_DOWN
Ponadto, co warto wiedzieć:
Od startu procesora do pierwszej instrukcji
w main (): 395us. Tutaj uwaga – czas ten za-
leży także od tego, ile zmiennych globalnych
i statycznych należy wcześniej przygotować
(wyzerować albo nadać im wartość początko-
wą). W dużych aplikacjach, czas ten może
znacząco się zwiększyć.
Od startu procesora do pierwszej instrukcji
w .init3: Niecałe 2us.
Widzimy, że minimalny, sensowny okres
WDT wynosi w naszym przypadku 250ms.
Można oczywiście go jeszcze skrócić, zerując
watchdog w większej ilości miejsc niż tylko raz
w pętli głównej, liczbie w naszym przypadku
takie podejście nie wydaje się uzasadnione. Dla
bezpieczeństwa nawet wybierzmy konfigura-
cję o 2x dłuższym czasie niż nasze minimum.
Listing 235 pokazuje wczesną konfigura-
cję watchdoga. Nie ma znaczenia, czy timer
SLEEP_MODE_PWR_SAVE
SLEEP_MODE_STANDBY
Dostępne funkcje:
set_sleep_mode (mode) – ustawia tryb uśpienia. Ustawie-
nia wystarczy dokonać tylko raz – każde późniejsze wy-
wołanie funkcji sleep_cpu () albo sleep_mode () spowo-
duje przejście do wybranego trybu.
sleep_cpu () – powoduje przejście procesora w wybrany
tryb uśpienia. W praktyce wykonuje instrukcję asemblera
„sleep”. Przed wywołaniem tej funkcji bit zezwalający na
uśpienie powinien być ustawiony. Zaleca się jego wyzero-
wanie zaraz po wyjściu ze stanu uśpienia.
sleep_enable () – ustawia bit zezwalający na uśpienie.
sleep_disable () – zeruje bit zezwalający na uśpienie.
sleep_mode () – powoduje przejście procesora w wybra-
ny tryb uśpienia. W odróżnieniu od sleep_cpu, sam prze-
prowadza aktywację uśpienia oraz późniejsze jego wyłą-
czanie.
Przykłady: listing 232.

Pobór prądu przy 5V, 8MHz

Szczegóły techniczne
Stany obniżonego poboru mocy
procesorów AVR
Procesory AVR mają spore możliwości oszczędzania
energii. Sam procesor może być przełączony w kilka try-
bów pracy, a najbardziej energochłonne peryferia mogą
być wyłączone. Nie będziemy zajmować się dokładnym
opisem sposobu przełączenia w tryb energooszczędny, po-
nieważ będziemy korzystać z wygodnych funkcji avr-libc.
Ważna natomiast jest wiedza na temat tego co w danym
stanie procesor może i ile potrzebuje prądu. Na drugie py-
tanie odpowiadają tabelki w ramce. Na pierwsze odpowia-
da opis niżej:
Idle – Tryb pracy, w którym zatrzymany jest CPU
oraz pamięć programu. Działają natomiast wszystkie pe-
ryferie i procesor może być obudzony przez dowolne
przerwanie (także gotowości pamięci FLASH do instruk-
cji SPM). Pobór prądu w tym trybie jest dwa razy mniej-
szy niż w trybie pełnej aktywności.
Power Down – Najbardziej oszczędny tryb pracy.
Wydawałoby się, że w tym trybie procesor praktycznie nic
nie może. Nie jest to jednak do końca prawda. Procesor
może być wybudzony za pomocą dowolnego źródła rese-
tu, jeśli tylko jest ono aktywne (Reset zewnętrzny, WDT,
BOD). Ponadto można obudzić go przerwaniem wyzwala-
nym poziomem na wejściach INT0 i INT1. Jeśli urucho-
miliśmy przerwanie asynchroniczne INT2, także to wej-
Tryb Pobór prądu Skrócony opis
Active 16mA Normalny tryb pracy
Idle 8mA CPU i pamięć FLASH zatrzymane, reszta peryferii pracuje
Power Down <2µA CPU i wszystkie peryferie zatrzymane. Rezonator nie pracuje.
Możliwe wyjście tylko przez reset albo przerwanie asynchroniczne.
Power Save <25µA Jak Power Save, ale Timer2 pracuje, jeśli taktowany asynchronicznie
Standby <180µA Jak Power Down, ale rezonator pracuje.
Skraca to czas reakcji na zerowanie albo przerwanie.
Extended Standby <200µA Jak Standby, ale Timer2 pracuje, jeśli taktowany asynchronicznie
Dodatkowy pobór mocy przez włączone peryferia
ście będzie aktywne. I co bardzo ciekawe, włączone wej-
Element Pobór prądu
ścia objęte przerwaniem na zmianę stanu też mogą obu-
BOD ok. 25µA
dzić procesor. TOSC 32kHz (Timer2) ok. 23µA
W każdym przypadku jednak wymagane jest, aby zda- WDT ok. 15µA
rzenie (reset, poziom niski, zmiana stanu) trwało przez pe- Komparator analogowy ok. 60µA
wien czas. To czyni procesor odporniejszym na zakłócenia
– wejścia są próbkowane dwa razy w takt oscylatora
WDT, którego nominalny okres wynosi 1µs. Extended Standby – Tryb Standby rozszerzony
Od chwili wykrycia zdarzenia do uruchomienia proce- o możliwość pracy w trybie asynchronicznym zegara
sora mija pewien czas, zależny od bitów konfiguracji, nie- – licznika 2.
zbędny do uruchomienia i stabilizacji drgań oscylatora. ADC Noise Reduction – Tryb dostępny w proceso-
Power Save – Tryb Power Down rozwinięty o możli- rach wyposażonych we wbudowany przetwornik AC.
wość pracy w trybie asynchronicznym zegara – licznika 2. Umożliwia on osiągnięcie dokładniejszych pomiarów,
Procesor może być budzony dodatkowo przez przerwania przez zmniejszenie generowanych zakłóceń. Po wejściu
pochodzące z tego elementu. w tryb, przetwarzanie rozpoczyna się automatycznie.
Standby – Tryb identyczny z trybem Power Down, Poza zakończeniem przetwarzania, inne przerwania
z tym wyjątkiem, że oscylator główny cały czas pracuje. (ale niekoniecznie wszystkie) mogą obudzić procesor.
Dzięki temu czas, jaki mija od wykrycia zdarzenia do pod- Szczegółowe informacje wymagają sprawdzenia doku-
jęcia pracy przez procesor, wynosi sześć taktów zegara. mentacji wybranego procesora.

E l e k t ro n i k a d l a Ws z y s t k i c h 43
 Programowanie
ten włączymy na sztywno z poziomu progra-
matora, czy będziemy zezwalali na jego za-
trzymanie. Tak czy inaczej dobrze jest prze-
prowadzić jego inicjację możliwie wcześnie.
Listing 235 Wczesna inicjacja WatchDog’a
void before_main(void)
{ należy czyścić bufor obrazu. W rejestrze
// Jak najwcześniejsze ustawienie wdt
wdt_enable(WDTO_500MS);
(...)
Listing 236 Warunkowa inicjacja części zmiennych (czyszczenie bufora) wykonywać tej funkcji. Jednak
if(MCUCSR & (1<<PORF | 1<<EXTRF | 1<<BORF | 1<<JTRF))
lcd_Cls(0);
MCUCSR = 0;
Spójrz teraz na listing 236. Nie jest to po-
czątkowa faza inicjacji – pojawia się już po
uruchomieniu samego wyświetlacza i wczyta-
niu palety. Na tym listingu na dwie rzeczy po-
winny zwrócić uwagę:
1. Wcale nie zerujemy rejestru MCUCSR
bardzo wcześnie. Do czasu zakończenia ini-
cjacji wyświetlacza mija czas liczony już
w dziesiątkach milisekund.
2. Czyszczenie ekranu nie jest uzależnione
od flagi zerowania z WDT, lecz od tego, czy
nie są ustawione flagi pozostałe.
Wyjaśnienie zacznę od końca:
Załóżmy taką teoretyczną sytuację: włą-
czamy zasilanie. W tej chwili zaczyna się
inicjacja. I dokładnie w tym momencie, zanim
Szczegóły techniczne
watchdog timer
Nie ma wielkich różnic w obsłudze timera WDT w po-
szczególnych procesorach, chociaż pewne występują. Po
szczegółowe informacje należy zawsze zajrzeć do doku-
mentacji danego procesora. Dalej skupiam się na proceso-
rze atmega162.
Timer watchdog jest taktowany z oddzielnego genera-
tora o częstotliwości 1MHz. Nie należy jednak liczyć na
dużą stabilność jej wartości. Jeśli pozwolimy doliczyć te-
mu timerowi do końca, procesor zostanie wyzerowany.
Możliwe do ustawienia czasy, między ostatnim zerowa-
niem timera a zerowaniem procesora, pokazuje tabela
w ramce. Duża rozpiętość czasów umożliwia dostosowa-
nie działania WDT do wymagań aplikacji.
W procesorze Atmega162 watchdog może pracować
w 3 poziomach bezpieczeństwa, zależnych od ustawień
bezpieczników w czasie programowania:
Safety Level 0 – WDT wyłączony po zerowaniu pro-
cesora. Jego włączenie i zmiana okresu są możliwe, bez
konieczności wykonywania niżej opisanej sekwencji
zmiany WDTCR. Wyłączenie wymaga odpowiedniej se-
kwencji.
Safety Level 1 – Podobnie jak poziom 0, ale wymaga
sekwencji także do zmiany okresu pracy WDT.
Safety Level 2 – WDT domyślnie włączony po zero-
waniu procesora. Timer ten nie może być programowo
wyłączony, a jedynie okresowo zerowany. Bit WDE pod-
czas odczytu przyjmuje zawsze wartość 1.
Okresowego zerowania watchdoga dokonujemy jedną
instrukcją asemblera: wdr.
Sekwencja zmiany rejestru WDTCR
W poziomach bezpieczeństwa, które tego wymagają, aby
zmienić zawartość rejestru WDTCR, należy wykonać na-
44
jeszcze wyświetlacz zostanie uruchomiony,
ktoś w łazience włącza starą suszarkę. Gene- ABC... GCC
ruje to impuls na liniach zasilania i procesor ABC... C
wpada w martwą pętlę. Po 0,5s zostaje on wy-
zerowany przez watchdoga. Ponownie rozpo- Dyrektywa #undef
czyna się inicjacja, która tym razem kończy Poniższa linia:
się pomyślnie. Dochodzimy do decyzji, czy #undef EXTRF
powoduje unieważnienie wcześniejszej definicji stałej /
makra EXTRF. Unieważnienie obowiązuje od chwili
MCUCSR ustawiony jest bit WDFR – wyda-
wystąpienia dyrektywy. Dane makro lub stała są ważne
wałoby się więc, że ponieważ wystąpiło awa-
wcześniej. Po dyrektywie #undef, można nadać określo-
ryjne zerowanie, nie powinniśmy nemu mnemonikowi nową wartość przez ponowną defi-
nicję.
tak naprawdę bufor od czasu włą- Przykład: listing 237
czenia zasilania nie był jeszcze
Do obsługi WDT służą w sumie trzy makra:
ABC... GCC
wdt_reset () – zerowanie licznika. Makro jest zamie-
Obsługa watchdoga niane na pojedynczą instrukcję asemblera: wdr. Jeśli ti-
mer pracuje, ta instrukcja powinna być wywoływana
W bibliotece avr-libc specjalne funkcje do obsługi timera okresowo, aby nie dopuścić do zerowania procesora. Do-
brym miejscem na jej umieszczenie jest pętla główna
WatchDog wymagają dołączenia pliku <avr/wdt. h>.
Definiowane stałe oznaczające poszczególne opóź- i wszystkie miejsca, gdzie procesor może dłużej „kręcić
nienia: się” w pętli.
WDTO_15MS wdt_disable () – wyłączenie WDT, jeśli tylko jest to
WDTO_30MS możliwe (jeśli zezwala na to wybrany tryb bezpieczeń-
WDTO_60MS stwa procesora). Automatycznie wykonuje sekwencję
wymaganą do zmiany rejestru WDTCR oraz blokuje
WDTO_120MS
WDTO_250MS przerwania na czas wprowadzanej zmiany.
WDTO_500MS wdt_enable (timeout) – powoduje włączenie WDT al-
WDTO_1S bo, jeśli licznik już pracuje, zmianę czasu jego opóźnie-
WDTO_2S nia. Podobnie jak wdt_disable, także generuje odpowied-
WDTO_4S – tylko niektóre procesory nią sekwencję i chwilowo blokuje przerwania. Ponadto
zawiera także instrukcję wdr.
WDTO_8S – tylko niektóre procesory
Przykłady: listing 235 i 236.
stępującą sekwencję:
1. W pojedynczej operacji
wpisz 1 do bitów WDCE i WDE
rejestru WDTCR (niezależnie od
tego, czy WDE jest aktualnie usta-
wiony, czy wyzerowany).
2. W czasie czterech cykli
wpisz wybrane ustawienia. Tym
razem bit WDCE powinien być
wyzerowany.
Sekwencja zmiany WDTCR wymaga odpowiednio WDP2..0 Liczba cykli Przybliżony czas
krótkiego czasu między poszczególnymi instrukcjami. 3V 5V
Ważne jest więc by w czasie jej wykonywania żadne prze- 0 16K 17ms 16ms
rwanie nie rozpoczęło wykonywania swojego kodu. Naj- 1 32K 34ms 33ms
bezpieczniej jest chwilowo wyłączyć globalne zezwolenie 2 64K 69ms 65ms
na przerwania. 3 128K 0,14s 0,13s
4 256K 0,27s 0,26s
Flagi źródła zerowania
5 512K 0,55s 0,52s
Przydatność timera WDT została znacznie zwiększona 6 1024K 1,1s 1,0s
przez specjalny rejestr MCUCSR, który zawiera informa- 7 2048K 2,2s 2,1s
cję o źródle zerowania.
Rejestr ten ma to do siebie, że zerowanie przy włącze-
niu zasilania (flaga PORF) powoduje wyzerowanie pozo-
stałych flag. Flaga PORF z kolei może być wyzerowana
tylko przez wpisanie do niej zera.
Teraz, co ważne, jeśli nie wyzeru-
jemy naszego rejestru i gdy po
włączeniu zasilania wystąpi zero-
wanie z zewnętrznego wyprowa-
dzenia, a później, na przykład
z WDT – wszystkie trzy flagi
(PORF, EXTRF, WDRF) będą
ustawione. Gdy już odpowiednio
zareagujemy na zawartość flag, re-
jestr MCUCSR powinniśmy pro-
gramowo wyzerować. Wiele źró-
deł zaleca zrobić to jak najszyb-
ciej, ale przekonamy się, że nie za-
wsze jest to dobre wyjście.
E l e k t ro n i k a d l a Ws z y s t k i c h

czyszczony. W rejestrze MCUCSR cały czas
ustawiona jest także flaga PORF. Dlatego
też bezpieczniej jest sprawdzić, czy nie wy-
stąpiło zdarzenie wymagające czyszczenia
zmiennych, niż czy nie wystąpiło zdarzenie,
które umożliwia ominięcie tej części kodu.
Rejestr zawierający flagi zerowania
czyścimy dopiero po zainicjowaniu zmien-
nych, nie wcześniej. Łatwo wyobrazić sobie
sytuację, gdy awaria zdarzy się w chwili
czyszczenia bufora – jeśli wyzerujemy
MCUCSR przed skończeniem jego czysz-
czenia, nie wyłapiemy takiego zdarzenia.
Przedstawione powyżej przypadki to
przypadki skrajne. Jednak ich uwzględnienie
sprawi, że nasze urządzenie będzie miało
mniejszą szansę, aby paść po wielu miesią-
cach/latach pracy bez przerwy.
Jak sprawdzić,
czy program prawidłowo
reaguje na reset WDT?
Teraz powinno pojawić się pytanie, jak prze-
testować reakcję urządzenia na awaryjne ze-
rowanie? Raczej nie możemy liczyć na testy
za pomocą starej suszarki. Jest na to inne
R E K L
Programowanie
rozwiązanie. Zasymulujemy zerowanie
watchdoga przyciskiem RESET na płytce.
Nie odpowiada to na wszystkie pytania, ale
umożliwia bardzo wygodne testy, które dużo
mówią już o napisanym programie.
Aby nie zmieniać nic w naszym kodzie,
zmienimy raczej przypisanie bitów w reje-
strze. Ponieważ do każdego praktycznie pli-
ku dołączamy nagłówek „harddef.h”, może-
my zrobić to właśnie tutaj. Dodane linijki
przedstawia listing 237.
A
Listing 237 Zmiana przypisania flag zerowania
M
#undef EXTRF
A
#define EXTRF WDRF
L
I to wszystko. Teraz, gdy po skompilow-
niu i wgraniu programu naciśniemy przycisk
K
RESET, wyświetlacz mignie, ale sam pło-
E
mień nie zacznie się od początku – jego ge-
R
nerowanie będzie kontynuowane – czyli
wszystko działa tak, jak chcieliśmy.
Po skończeniu testów pamiętaj, aby usu-
nąć (wykomentować) dodane linie z listingu
237.
Radosław Koppel
radoslaw.koppel@elportal.pl
A M A