Andrzej Pawluczuk
Sztuka programowania mikrokontrolerów AVR
podstawy

Wydawnictwo BTC, 2006

Dlaczego ta książka jest inna...

      To było ponad półtora roku temu...dokładnie 7 luty 2005.
Wtedy właśnie dowiedziałam się, że powstaje to dzieło, po raz pierwszy ujrzałam roboczy tytuł: "Sztuka programowania...". Półtora roku, przecież to szmat czasu. W międzyczasie wymieniłam kilka elektronicznych listów z Autorem na temat próbek tekstu - ot, drobnych uwag. Półtora roku...i nagle przeszłość stała się teraźniejszością. Dzięki staraniom bliskiej mi osoby, po odbyciu długiej podróży, wczoraj (4 listopad) późnym wieczorem trzymałam w rękach "Sztukę programowania mikrokontrolerów AVR".
Schowałam się przed światem w głębokim fotelu, zawinęłam w koc i zaczęłam się zastanawiać - co jest w środku? Jaka jest ta książka i jak ją teraz czytać? I przeczytałam ją bez przerw, od początku do końca, w niecałe siedem godzin... To dziwne uczucie, dość niezwykłe...przecież ja pamiętam te fragmenty tekstu, poznaję je...choć teraz są już nieco inne - pełniejsze, dojrzalsze, po prostu gotowe. W końcu są całością.
Czy to zwykła książka, jak wiele innych o mikrokontrolerach?
Tak, to jest zwykła książka. W zwykłej, typowej dla BTC twardej okładce, pachnąca świeżą farbą drukarską...
Niezwykła jest natomiast jej historia. Niezwykłe jest to, że dane mi było choć przez moment przyglądać się jak powstaje, że mogłam zobaczyć jak wygląda proces twórczy, którego owoc właśnie trzymam w dłoniach.
I dlatego właśnie ta książka jest inna. A jej inność, to wystarczający powód aby napisać ten tekst.

Programowanie to sztuka?

      Sztuka...to pojęcie bardzo obszerne i dość łatwo znaleźć jego encyklopedyczną definicję, choćby w Wiki.
"Sztuka to dziedzina działalności ludzkiej mająca między innymi na celu przedstawienie świata widzialnego i odczuwanego; dostarczenie wrażeń estetycznych jest celem ubocznym [...]".
I tak dalej...garść zdań twierdzących, które chyba możemy przyjąć za pewnik. Ale możemy też pokusić się o zbudowanie własnej, unikalnej definicji bazując na sposobie w jaki postrzegamy świat który nas otacza.
Czym więc jest sztuka? Sztuka to dialog twórcy z odbiorcą, próba przekazania pewnych wartości, pewnych prawd, ale w sposób pozostawiający miejsce na własną interpretację, na refleksję, tak aby wzbogacić wewnętrznie odbiorcę. Czy takie rozumienie sztuki można w jakikolwiek sposób dopasować do zimnego, zerojedynkowego świata? Do świata, którym rządzą prawa logiki i ściśle określone zależności przyczynowo-skutkowe? Czy programowanie może być sztuką?
      Program komputerowy - można go postrzegać na wiele sposobów. Jako algorytmiczny opis otaczających nas realiów, jako zbiór instrukcji dla jednostki centralnej wykonujący jakąś użyteczną czynność. Wariantów jest wiele, a niektóre z nich mogą naprawdę zaskakiwać...
Spójrzmy na kawałek laminatu, na mikroprocesor, układy scalone i inne towarzyszące im elementy elektroniczne - kolejna konstrukcja z "mikrokontrolerem w środku". Ale tak naprwadę...to tylko rzecz. Martwa, aż do chwili gdy do procesora zostanie załadowany napisany przez nas program. Wtedy zaczyna się coś dziać. Urządzenie nagle zaczyna działać, możemy jakoś się z nim komunikować. Dzięki oprogramowaniu, urządzonko jest w stanie wejść w interakcję z otoczeniem, w szczególności ze swoim twórcą. Czasam nawet daje się polubić. Tylko że...
No właśnie, podobnie jak z ludźmi...pod przyjazną maską może ukrywać się zupełnie inne, niestety mniej sympatyczne oblicze. Coś, czego nie potrafimy lub czasem wręcz nie chcemy zobaczyć, w końcu to nasze dzieło i wydaje się być doskonałe.
Programy można pisać bardzo różnie, choć cel jest zawsze ten sam - kod ma działać poprawnie i zgodnie z przyjętymi założeniami. Często jednak nie dbamy o estetykę kodu, o odpowiednio treściwe komentarze w wersji źródłowej. Często program przypomina strumień beznamiętnie następujących po sobie instrukcji uporczywie płynących w jednym kierunku - niech to w końcu "jakoś" zadziała.
Wynika to czasem z pośpiechu, czasem z braku wiedzy...Często też zdarza się, że nie wykorzystujemy w stu procentach możliwości jakie oferuje nam narzędzie czy środowisko w którym przygotowujemy nasz program.
"Sztuka..." wskazuje inne podejście. Uświadamiając znaczenie zjawisk zachodzących w strukturze mikrokontrolera, jednocześnie sugeruje jak z nimi postępować i jak najefektywniej z nich korzystać. To samo dotyczy narzędzi programistycznych. Dokładne omówienie znaczenia dyrektyw assemblera czy zagadnień kompilacji warunkowej to swoisty zastrzyk wiedzy, który w efekcie pozwala pisać kod nie tyle bardziej skutecznie, co pozwala go pisać bardziej świadomie, bez błądzenia po omacku.
I właśnie napisanie takiego - dobrego programu - to sztuka.
Ponieważ sztuką jest skonstruować poprawny kod nie tylko pod względem logicznym, ale też skonstruować go tak aby dał się w przyszłości łatwo rozbudowywać. Aby nie zawierał nieporadnych, dziwnych rozwiązań lecz aby był elegancki w swojej prostocie, a jednocześnie poprawnie i w sposób deterministyczny działał. I w końcu, aby wersja źródłowa programu była czymś, czym można się pochwalić, podać za wzór a nie skrzętnie ukrywać w czeluściach dysku domowego komputera. Tego właśnie uczy nas "Sztuka...".

Książka kucharska

      Przyznaję, z gotowaniem u mnie kiepsko...jakoś nigdy nie miałam do tego typu aktywności specjalnego nabożeństwa i nie wiem czy to się kiedykolwiek zmieni. A przecież gotowanie to także...sztuka. Łatwo zgadnąć, że gwarancją sukcesu oprócz ogromnego wyczucia smaku jest też posiadanie zestawu sprawdzonych, przetestowanych na innych (o zgrozo!) przepisów; przepisów na wszelkie możliwe (choć lepiej powiedzieć - typowe) okazje. To pozwala uniknąć różnego rodzaju improwizacji, które gdy okażą się chybione, mogą dostarczyć rodzinie lub bliskim dość traumatycznych przeżyć (to sprawdziłam...).
      A przecież taką właśnie "książką kucharską" jest "Sztuka...". Przepisy zaczynają się już w rozdziale dziesiątym ("Zasady arytmetyki"). Są to początkowo niewielkie fragmenty kodu ilustrujące proste dodawanie czy zmianę znaku liczb. Mnożenie liczb dwubajtowych to taka zaprawka, potem czytamy o operacjach mnożenia/dzielenia liczb przez 2 i 10, kończąc na operacjach porównywania liczb wielobajtowych. Niby nie są to skomplikowane sprawy, ale gdy nagle zapragniemy obrabiać matematycznie wyniki zwracane przez przetwornik analogowo-cyfrowy - nie znając ogólnych algorytmów postępowania możemy napotkać spore trudności.
Rozdział "Wybrane algorytmy i ich użycie" to gruntowny opis dwóch chyba podstawowych zagadnień - obsługi przerwań od nieubłaganie "tykającego" układu timera oraz obsługa prostej klawiatury. Wyposażenie programu w cyt.: "świadomość upływającego czasu" to ważna sprawa, nasze urządzenie jest w ten sposób bardziej związane z otaczającą rzczywistością. Równie ważna jest świadomość, jak poprawnie implementować procedury obsługi tego typu przerwań, jak unikać pułapek polegających przykładowo na umieszczeniu długotwałych obliczeń w tych procedurach. Klawiatura to jedno z bardziej typowych urządzeń w konstrukcjach mikroprocesorowych. A z tym na pozór niewinnie wyglądającym zestawem przycisków nieodłącznie związane jest zagadnienie drgań zestyków, potrafiące osobę piszącą oprogramowanie często przyprawić o ból głowy. Małe, a podłe. Stąd też obsłudze klawiatury i sposobom eliminacji "dzwonienia" poświęcone zostało sporo miejsca. Podejście Autora do tego zagadnienia jest o tyle ciekawe, że zastosowano programowo zrealizowany automat (maszynę stanów) niejako obserwujący otoczenie i reagujący na zachodzące w nim zdarzenia w dziedzinie upływającego czasu. Sądze, że warto dokładnie "rozpracować" zasadę działania przykładowych programów, choćby ze względu na ciekawy sposób realizacji automatu i obsługi grafu przejść. Znajomość tych technik bardzo ułatwia projektowanie oprogramowania komunikującego się ze światem zewnętrznym i to nie tylko przy pomocy klawiatury.
      Skoro już jesteśmy przy przepisach, zastanówmy się nad jedną rzeczą. Zapytam troszkę przekornie - z czego składa się typowy program w assemblerze? No, oczywiście z poukładanych pracowicie instrukcji, dyrektyw i komentarzy, które zebrane razem coś mądrego robią. To jest jeden punkt widzenia. Patrząc na program bardziej abstrakcyjnie, zauważymy pewne (czasem przenikające się wzajemnie) obszary, którym w miarę łatwo możemy przypisać pewne funkcje w programie. To instrukcje podstawienia, warunku, to iteracje, to w końcu wywołania funkcji i procedur - pojęcia spotykane raczej w programowaniu wysokopoziomowym. I właśnie dlatego szczególnie ważny jest rozdział "Assembler a język wysokiego poziomu", ponieważ tam znajdziemy assemblerowe odpowiedniki instrukcji, którymi na codzień posługujemy się programując w takich językach jak na przykład Pascal. Opis dotyczy "rozebranych na czynniki pierwsze" instrukcji warunkowych IF-THEN-ELSE, wyboru CASE, pętli typu FOR, WHILE-DO, REPEAT-UNTIL oraz pętli nieskończonych - wszystko co potrzeba do szczęscia. Zagadnienie wywoływania funkcji i procedur także zostało potraktowane z należytą uwagą, ze szczególnym naciskiem na metody przekazywania parametrów wejściowych i zwracania wyników.
      Program to nie tylko kod, to także i dane, na których on operuje. Typy proste z reguły nie sprawiają problemów, ale z implementacją obsługi struktur (rekordów) czy tablic czasem miewamy kłopoty. Wiele informacji jak sobie w takich sytuacjach poradzić znajdziemy właśnie w rozdziale "Assembler a język wysokiego poziomu".
      Wspomniałam o języku wysokiego poziomu Pascal. W "Sztuce..." znajdziemy moim zdaniem dość unikalny sposób prezentacji pewnych zagadnień natury implementacyjnej - widzimy fragment kodu źródłowego właśnie w Pascalu, za chwilę bogato opatrzony komentarzami, odpowiadający mu funkcjonalnie fragment w assemblerze. Takie podejście niesamowicie ułatwia zrozumienie zasady działania kodu niskopoziomowego, a z okruchami Pascala w assemblerowych komentarzach należy się szybko zaprzyjaźnić - są w "Sztuce..." wszechobecne.

"(...) zaburzenie zwane przerwaniem"

      Zastanowiły mnie te słowa. To jeszcze początek, raptem czwarty rozdział, ale właśnie od tej chwili zaczęłam zwracać uwagę nie tylko na treść, na zawartość stricte merytoryczną, ale też na słownictwo używane przez Autora. W miarę lektury w głowie budowała się taka jakby trójwymiarowa mapa: pojęcie-znaczenie-kontekst. I to samo podejście sugeruję wszystkim potencjalnym czytelnikom; powód jest równie prosty do ogarnięcia co w sumie smutny. Odwiedzając fora dyskusyjne, czasem uczestnicząc w prowadzonych tam dyskusjach, chwilami nie mogę oprzeć się wrażeniu, że posługujemy się dość ubogim słownictwem. Próby opisania danego problemu, który jako dotyczący elektroniki czy informatyki ma podłoże ścisłe i wymaga pewnej precyzji, kończą się czasami powstaniem typowych "potworków językowych". Próba identyfikacji o co tak naprawdę osobie piszącej chodzi wymaga sporego wysiłku, a momentami przypomina przysłowiowe wróżenie z fusów. Nie jest to na szczęście zjawisko nagminne, niemniej jednak zachodzi i nie ukrywam - czasem irytuje. A powód, w mojej opinii jest jeden - zbyt mało czytamy, po prostu. Przecież to właśnie przez lekturę wzbogacamy słownictwo, przyswajamy sobie nowe pojęcia i uczymy się w jakim kontekście należy ich użyć. Uczymy się operować technicznymi terminami, wyrażać precyzyjnie i w sposób zrozumiały dla odbiorcy.
Myślę, że "Sztuka..." to dobry przykład lektury pozwalającej oswoić się z fachową nomenklaturą, pozwalającej przy odrobinie chęci wzbogacić własny, osobisty słownik pojęć na temat mikroelektroniki i programowania.

Ja, konsumentka

      A teraz nieco inny punkt widzenia. Spoglądam na tę książkę okiem rozkapryszonej, konsumpcyjnie nastawionej do otoczenia czytelniczki...I co widzę? Okładka, skrywająca 349 stron żywej treści (reklamowe wkładki odliczyłam), no pięknie... Choć odnośnie pewnych (ponad stu) stron rozdziału siódmego mam drobne wątpliwości. Wspomniane strony to skrócony (choć kompletny) opis instrukcji mikrokontrolera AVR. I tak się jakoś dziwnie ułożyło, że jedna instrukcja zajmuje dokładnie jedną stronę. Instrukcje typu LD, LPM czy FMULS rzeczywiście wymagają odrobiny komentarza i komentarz ten (czy jak kto woli - objaśnienie) ładnie zapełnia stronę. Strony dotyczące prostych, trywialnych rozkazów jak NOP, SLEEP, SET niepokoją dużą ilością bieli. Zapisane jest czasem pół, czasem odrobinę więcej strony...Hmm, cóż tu pomyśleć? Z jednej strony ma to uzasadnienie, jeden rozkaz to jedna strona książki, łatwo coś odszukać w spisie treści, sposób prezentacji opisu rozkazu jest jednolity i estetyczny. Jednak ta biel inspiruje, chociażby do tego, aby puste miejsca zapełnić własnymi notatkami na temat danego rozkazu. A przecież pisanie po książkach, nawet ołówkiem, jest co najmniej nie na miejscu, prawda? Ufam jednak, że BTC w przyszłych wydaniach tej pozycji tę niesamowitą pokusę bazgrania po kartkach jakoś wyeliminuje...

Dla kogo?

      Jak każda pozycja książkowa, także i ta ma swój w miarę dobrze określony krąg odbiorców.
"Książka jest adresowana przede wszystkim do szerokiego kręgu hobbystów i pasjonatów techniki mikroprocesorowej, ale ze względu na poruszaną tematykę [...]"
To czytamy na wkładce zaraz na początku, a podobne sformułowanie znajdziemy chyba we wszystkich książkach dotyczących mikrokontrolerów i technik ich programowania.
Ja chciałabym ująć to nieco inaczej - moim zdaniem "Sztuką..." powinne zainteresować się osoby, które chcą pisać naprawdę dobre programy dla mikrokontrolerów AVR. Które chcą czerpać satysfakcję również z samego faktu powstawania oprogramowania i chcą się w ten sposób twórczo realizować. Przecież pisanie programów to jedna z najwyższych form kreacji, to proces w wyniku którego z garści nic nie znaczących słów powstaje nowa jakość. A ta książka pomaga to zrozumieć.

Brakująca dedykacja...

A mnie, gdy znowu znajdę chwilę czasu tylko dla siebie, pozostało ponownie usiąść gdzieś w cichym kącie i powolutku, szeptem przeczytać tę książkę jeszcze raz. Wiem, że ona usłyszy i że będzie dumna, a przynajmniej bardzo chcę w to wierzyć...

Howth, 5 listopad 2006