cz3

Programowanie

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ą operatoró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ć automatycznie zamieniona na warunek, przy czym 0 oznacza fałsz, inna wartość - prawdę. Poniższe zapisy są równoważne: if(a) <s> 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 jednak dobre zrozumienie zasady wykonywania obliczeń w C.

Operatory logiczne a operatory bitowe

Do tworzenia złożonych warunków wykorzystujemy 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 rzeczywistości:

Nastąpi porównanie liczby a z 12. Działanie 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ąkolwiek 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, żc jeśli okaże się, na przykład, że pierwsze porównanie zwróci fałsz - wartość zmiennej b nawet nie będzie sprawdzana. Uwaga: standard definiuje takie właśnie zachowanie, jednak nie dejiniuje, 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łą I0. 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(b<a && a<13)

Teraz wszystko będzie działało zgodnie z naszą intencją,

Nie wszystko naraz

Widzisz może teraz, że warunki w C pozwalają 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żonych 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)

1

if(a<lC)

1

//Ercqram dojdzie do tego //miejsca jeśli 5<a<10

}

}

zmieniamy typ tablicy g_DaneCom na prog_uint8_t. Zgodnie z opisem możesz zamiast tego dodać zaraz za deklaracją zmiennej słowo PROGMEM. Sposób, jaki wybierzesz, nie ma znaczenia. Efekt będzie taki sam. Ostatnim koniecznym do zmiany punktem 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 umieszczona tutaj w pamięci programu za pomocą słowa PROGMEM.

Po wprowadzeniu zmian skompiluj program... udało się? Kompilacja powinna przebiec bez problemów, po załadowaniu do procesora nie zauważymy z zewnątrz różnicy w porównaniu do poprzedniej wersji. W tej chwili część programu odpowiedzialna za obsługę wyświetlacza LED jest kompletna i w polni funkcjonalna. Jeśli jeszcze wprowadzimy do niej jakieś zmiany - będą to poprawki kosmetyczne.

Spodziewasz się może, że dostęp do pamięci programu, od strony kodu maszynowego, 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. Podsumowanie takie jest wykonywane po prawidłowym zakończeniu każdej kompilacji. Obydwa programy, zgodnie z proponowaną modyfikacją, zawierały wpisanie początkowej wartoś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 naszego przerwania.

Sinclude <svr\io.h>

Sinclude cinttypes ,h>

Sinclude <avr\signal.h>

Sinclude <avr\intB.rmpt.h>

Sinclude <avr\pgmspace.h>

(...)

•4insB_t q_DaneCoraM] PRCGMKK -

ł~(l«COMl), ~(l«COM2), ~(1«CCM3), ~{l«COK4));

int raain (void)

// Cosłuoa przerwań S1GNAŁ(SIG OVERFLCW0)

{

(...)

COKSORT s= pgn cea<i_byte (Sg_DaneCcm[g_ AkrWyswietlącz]) ;

Elektronika dla Wszystkich Lipiec2005 45