TL;DR — Bawię się ATmegą8a, przyszedłem pomarudzić.
Od zawsze byłem osobą ciekawską, może o tyle jest to zaletą, że bardziej niż życie sąsiada interesowało mnie to jak działa sprzęt (w szczególności elektroniczny) który mnie otacza. Przez wiele lat na zainteresowaniu i studiowaniu bebechów — często ze skutkiem fatalnym dla samych urządzeń — przygoda z tym tematem się kończyła, zanikając pod presją kurczącego się wolnego czasu, jak i zużywaniem go na naukę programowania i administracji systemami uniksowatymi.
Jednak z powodu nagłego widzimisię oraz możliwości ku temu powróciłem do studiowania wszelkiej maści elektroniki, tym razem od bardziej naukowej strony tematu. Po zrozumieniu podstawowych zasad rządzących światem prądu poczułem, że przecież to nie jest tak wciągający temat — prawdę mówiąc jest zbyt prosty. Tak więc wzrok mój padł na µC — mikrokontrolery.
Po chwili dłubania w otchłaniach http:// wywnioskowałem, jak i wielu innych przede mną, że na początek miłym urządzeniem będzie AVR ATmega8 (wersja 8A-PU, choć teraz wiem, że lepszym wyborem byłaby 88). Jest czym się pochwalić i na co ponarzekać — temat na artykuł jak znalazł. Zacznijmy więc od narzekania.
Wady (subiektywnie)
Jestem zagorzałym uniksiarzem i windowsa nie wypuszczałem poza moje VMWare od baaardzo dawna. Przykrą niespodzianką więc było, że o ile pisać programy w QtCreator czy Emacsie, kompilować przez AVR-GCC, flashować przez avrdude mogę bez problemu, o tyle debugowanie ich przez zestaw AVR-GDB plus symulator simavr lub simulavr (ach ten polot i finezja przy wymyślaniu nazw) jest męczące, upierdliwe i niewygodne. Chyba jedyny istniejący dodatek do jakiegokolwiek IDE to przestarzały, nierozwijany od prawie 3 lat AVR-Eclipse, a i on niewiele ponad to co QtCreator czy Emacs nie oferuje (SIC!). Oficjalne IDE (Atmel Studio) oparte jest o MS Visual Studio więc o odpaleniu go pod WINE można pomarzyć — tak więc za dostępność środowiska srogi minus.
Programować można w C, C++ (używając API w C) oraz Assembly (a pewnie i sporo innych języków, jakby komuś chciało się owrapować funkcje). Zdziwiło mnie, że większość rozszerzeń LibC o funkcje specyficzne dla platformy to przeważnie kalka odpowiednich mnemoników Assembly, a wszelkie porty, piny i tryby ustawia się poprzez zmianę bitów zmiennych o nazwach adekwatnych do rejestrów procesora na których operują… A można było zaimplementować ładne API.
Zalety (tak samo subiektywne)
Jestem szczerze zaskoczony mnogością funkcji scalaka, który kosztuje grosze — nie licząc kosztów dostarczenia polskie firmy oferują kostkę w cenach 8–9zł za sztukę, a jeszcze taniej przy zamówieniu kilku. Na ibeju od chińczyka zamówić można w cenach $3 za sztukę, a przy zamówieniu pięciu czy dziesięciu sztuk cena jednej spada do okolicy dolara.
Drugim atutem jest niewątpliwie wieloplatformowy zestaw narzędzi programistycznych o którym wspomniałem wcześniej, t.j. zestaw kompilatorów oparty o GNU GCC i GNU BinUtils — w świetle ostatnich rewolucji w świecie kompilatorów przyczepić się można o brak LLVM/Clang, ale to już kwestia bycia wybredną marudą — debuggera GNU GDB, symulatorów simavr i simulavr oraz flashera AVRDude. Programować się da, szkoda tylko, że nie tak wygodnie jak pod Atmel Studio.
Wydajność scalaka również robi wrażenie — architektura pozwala na wykonywanie prawie wszystkich instrukcji z wydajnością 1MIPS na każdy 1MHz, a kolejne instrukcje buforowane są w trakcie wykonywania poprzedniej co pozwala na ciągłą pracę kodu, bez najmniejszych przestojów.
Energooszczędność nie jest dla mnie wielce ważna, jednak procesor ten umożliwia wprowadzanie go w kilka stanów uśpienia, wyłaczanie niepotrzebnych modułów, a także w pełni sprawny pobiera kilka mA. Warto też nadmienić, że podczas uśpienia zużycie prądu może spaść do ~0.5µA (udało mi się zmierzyć 1µA, ale pewnie to tylko niedokładność multimetru).
Ale tobie się nudzi…
Trochę… Programowania zacząłem się uczyć na własną rękę jakieś 16 lat temu. Przez ten czas poznałem masę różnych, niekiedy bardzo dziwnych języków od bardzo niskopoziomowych (Assembly x86) po całkowicie abstrakcyjne względem sprzętu (Java, Scala, Python, …) W końcu przyszedł ten moment, że programowanie przestało sprawiać frajdę, zaczęło brakować pomysłów na własne projekty i całość ograniczyła się do pisania krótkich helperów codziennej pracy, w py czy sh. AVRki pozwoliły mi na dalszą zabawę.
Poniżej jeden z pierwszych projektów, wideo nagrywane rzutnikiem z przesłoną z wczorajszej skarpetki i konwertowane młynkiem do mięsa.