SD Drive/Loader dla HackVision

Bardzo tęskniliście? W czasie, gdy Wy objadaliście się jajkami, białą kiełbasą i żurkiem, albo odgarnialiście wiosenny śnieg z podjazdu – ja również nie próżnowałem. Projekt, który zaraz przedstawię, pomimo, że początkowo wyglądał na niespecjalnie skomplikowany, przysporzył mi masy nieoczekiwanych problemów i nawet kilka razy byłem bliski rzucenia wszystkiego w kąt. Ale udało się! Nie ukrywam, że nie dałbym rady bez pomocy internetu i bez mojego wrodzonego uporu. A teraz przyszedł moment, aby podzielić się z Wami zdobytą w bojach wiedzą i pochwalić osiągniętym z wielkim trudem sukcesem.

Już jakiś czas temu zainteresowałem się biblioteką TvOut przeznaczoną dla Arduino, która umożliwia wyświetlanie obrazu na telewizorze przy pomocy standardowego wejścia kompozytowego (zazwyczaj żółty chinch).  Sam układ jest banalnie prosty do wykonania i wygląda tak:

Jak widać potrzebujemy tylko dwóch rezystorów i możemy wyświetlać obraz na ekranie telewizora!!!

Niestety, możliwości naszego mikroprocesora są niewielkie i pamiętajmy, że cały obraz musimy generować w pamięci RAM, której w przypadku Arduino mamy 2Kb. Zatem maksimum jakie możemy wyciągnąć wygląda następująco:

• rozdzielczość maksymalna 128×96
• obraz czarno-biały i to dosłownie. Mamy tylko dwa kolory.
• biblioteka TvOut.h – a dokładniej  – bufor obrazu zajmuje tyle pamięci, że należy bardzo uważać przy programowaniu i nie używać dużych struktur danych, ani dużej ilości zagłębień z funkcji do funkcji, bo może to powodować szybkie przepełnienie stosu.
• nie ma miejsca na “frame-buffer” (dodatkowy bufor obrazu), zatem wszystkie zmiany obrazu wyświetlamy bezpośrednio na ekranie, co przy szybkich animacjach może powodować migotanie.

Biorąc pod uwagę, że to wszystko mamy tylko dzięki dwóm rezystorom, to i tak nie ma co narzekać :) Podstawowe możliwości biblioteki TvOut prezentuje poniższe demko dostarczane wraz z biblioteką:

Fajnie co? Moja pierwsza myśl: TETRIS! Oczywiście okazało się, że już ktoś na to wpadł i mamy tetrisa na Arduino:

Po dłuższej chwili googlania, okazało się, że ktoś już nawet zrobił mini-konsolę do gier opartą o Arduino: http://nootropicdesign.com/hackvision/

Wow! Chce to! Mam już wprawdzie niemal w stu procentach identyczny prototyp na płytce stykowej, ale bez takich ładnych przycisków i kolorowych gniazdek. Zapragnąłem oryginalnego hackvision.

Okazało się, że rzeczone – jak gdyby nigdy nic – znajduje się w ofercie sklepu Nettigo. O tutaj: klik ! Cudownym zbiegiem okoliczności, za mój poprzedni artykuł o zegarze otrzymałem od Nettigo, 50% zniżkę na zakupy, więc nie zastanawiałem się długo. Dorzuciłem do koszyka jeszcze ze trzy Atmegi, bo już mi się pokończyły i kliknąłem “zamawiam”.

Po dwóch dniach truchtem odwiedziłem paczkomat i rzuciłem się do lutowania. Płytka do samego hackvision, jest wykonana naprawdę ładnie i solidnie. Jest czarna i błyszcząca i wyjątkowo ciężka jak na laminat. Sprawia wrażenie jakby była wykonana z ceramiki, a może nawet jest?

Samego lutowania było 15 minut, bo elementów jest naprawdę niewiele. O dziwo polutowałem wszystko sprawnie za pierwszym razem i układ zaskoczył, bez żadnych problemów. Na “fabrycznym” 328 dostarczonym z hackvision, są wrzucone dwie gry: SPACE INVADERS i PONG. Po zapełnieniu całej listy rekordów w SPACE INVADERS, postanowiłem w końcu zabrać się za programowanie swoich gier.

I tutaj pierwsza kłoda pod nogi. Samo hackvision – owszem – posiada bootloader Arduino, ale nie ma portu USB. Ma wyprowadzony jedynie port szeregowy w standardzie TTL. Zatem, aby coś na nie “wrzucić”, potrzebujemy przejściówki z portu COM na poziomy TTL, lub jakiś interfejs FTDI (na przykład taki: http://nettigo.pl/products/119 ). Niestety, w śnieżny kwietniowy weekend nie było szans, abym coś podobnego nabył. Zatem aby wymienić SPACE INVADERS na inną grę, nie pozostało mi nic innego, jak programowanie samego układu 328 w podstawce Arduino, czyli przekładanie układu tam i z powrotem. Niespecjalnie wygodne, poza tym, przypuszczam, że po kilku takich operacjach, układ nie “siedziałby” w podstawce już tak jak powinien.

Z drugiej strony, skoro ma to być przenośna konsola, to trochę bez sensu że za każdym razem do wymiany gry potrzebny był komputer, prawda? I tak właśnie urodził się pomysł: skoro do programowania HackVision potrzebujemy portu szeregowego, to przecież możemy do tego celu użyć drugiej Atmegi. W końcu ma port szeregowy i to w dodatku od razu w standardzie TTL!

Będzie jeszcze potrzebne jakieś źródło danych dla naszego bootdysku – padło na moduł karty SD podłączany po SPI.

Kupiłem jeden onegdaj, sprawdziłem że działa i do tej pory się kurzył. No to w końcu się przyda. Nie będę się tutaj rozpisywał, na temat użycia kart SD wraz z Arduino. W sieci jest masa dobrze opisanych przykładów i jest to w sumie całkiem proste. Jedyna uwaga, to może to, że dostarczana wraz z Ardiono IDE biblioteka SD.h, po skompilowaniu zajmuje prawie 19KB. Początkowo jako główny układ chciałem użyć Atmegi 168 (16kB flash), ale właśnie ze względu na rozmiar biblioteki SD musiałem jednak sięgnąć po 328 (32kB pamięci flash).

Podsumowując powyższe, pomysł jest generalnie taki:

• Program (grę) do wgrania na hackvision umieszczamy na karcie SD 
• Kartę SD umieszczamy w naszym układzie – od tej pory roboczo zwanym “SD Drive“
• SD Drive podłączamy łączem szeregowym (TTL) z hackvision
• Inicjujemy (jakoś) procedurę ładowania – i pakujemy program z karty do konsoli

Idea jest – czas na realizację. Zacząłem szukać jakiegoś opisu jak działa bootloader i jak musimy przygotować dane, żeby je sprytnie “wepchać” do naszej konsoli. Okazało się, że nie jest to wcale takie proste. Aby przełączyć bootloader w tryb programowania układu, musimy użyć protokołu programatora stk500, ale na szczęście już ktoś próbował zrobić coś podobnego tutaj:

http://baldwisdom.com/bootdrive/

Super. Czyli w zasadzie mamy prawie gotowe rozwiązanie!!! Niestety – mielibyśmy – gdyby działało tak jak powinno. Ale o tym dopiero za chwilę. Zachęcony projektem BootDrive postanowiłem nie bawić się w płytkę stykową i od razu wykonałem sobie cały układ na na płytce uniwersalnej. Pewnie gdyby nie to, że zrobiłem już płytkę – to rzuciłbym tym w cholerę przy późniejszych perypetiach, a tak – miałem dodatkową motywację aby to dokończyć. 

A oto schemat mojego układu SD Drive:

oraz gotowy prototyp:

Projekt BootDrive – czyli nasz wyjściowy soft który będziemy modyfikować – zakłada, że w katalogu głównym karty znajduje się plik program.hex, i właśnie ten plik jest ładowany poprzez złącze szeregowe. Tylko skąd wziąć plik w formacie hex? Za każdym razem, gdy w naszym Arduino IDE naciśniemy przycisk Weryfikuj/Kompiluj (CTRL+R), kod naszego programu kompilowany jest do kodu binarnego i zapisywany właśnie w pliku hex. W windows 7 lokalizacja tego pliku jest następująca:

C:UsersbocianuAppDataLocalTempbuild7043948574983502558.tmp

Oczywiście “bocianu” to nazwa usera i u Was pewnie będzie inna. Podobnie cyferki w nazwie ostatniego katalogu – z pewnością tez będą inne.

Wrzucam na kartę program.hex, odpalam BootDrive… i lipa. Nic się nie dzieje – pierwszy problem okazał się dosyć prosty do rozwiązania: BootDrive zakłada, że mamy do czynienia z bootloaderem Arduino Uno, który programowany jest z szybkością 115200 bps. Okazało się jednak, że hackvision domyślnie korzysta z bootloadera z Arduino Duemilanove, i należy w kodzie programu zmienić prędkość na 57600 bps. Programowanie w końcu zaskoczyło, ale  znów nie do końca. Z ośmiu plików hex jakie sobie przygotowałem do testów, tylko 3 ładowały się poprawnie. Pozostałe uparcie nie chciały działać. I nie zależało to od rozmiaru, bo akurat plik (gra) o największym rozmiarze ładowała się bez problemu.

No i zaczęło się pierwsze żmudne debugowanie i po kilku godzinach braku efektów – pierwsze zwątpienie. Nie mam pojęcia co jest nie tak. A kiedy po chyba czterech godzinach zapisywania w logach i analizowania całej komunikacji w końcu udało mi się zlokalizować problem i wiedziałem już przynajmniej czego szukać. Okazało się, że gotowe rozwiązanie leży na forum Arduino:

http://arduino.cc/forum/index.php?topic=92371.0

Dla osób nieobeznanych z językiem Szekspira podaję skrócone wyjaśnienie. Problem leżał w funkcji readPage(), która w wypadku kiedy w pliku hex znajdowała się linia krótsza niż 16 bajtów, nieprawidłowo formatowała dane przekazywane przez port szeregowy. Po poprawieniu funkcji wszystkie osiem plików zaczęło ładować się poprawnie. Ufff ! Straciłem parę godzin, ale jest sukces.

Wszystko bardzo pięknie, ale nadal potrzebujemy komputera, żeby wymienić grę w naszej konsoli – przecież nasz BootDrive potrafi odczytać z SD tylko jeden konkretny plik. A co gdybyśmy chcieli umieścić na karcie wszystkie 8 plików i potem wybierać który ładujemy? Byłoby jeszcze piękniej – tylko jak to zrobić? Z góry założyłem, że nie robimy żadnych dodatkowych przycisków na samym układzie SD Drive – w końcu mamy już piękne przyciski na naszym hackvision i to właśnie z nich zaplanowałem sobie skorzystać.

Idea:

• podłączamy SD Drive do hackvision
• SD Drive sprawdza czy na hackvision uruchomiony jest specjalny program ładujący (SD Loader)
• jeżeli nie – SD Drive programuje hackvision plikiem SD Loadera i restartuje. Jeśli SD Loader już jest – czeka na komunikaty.
• po uruchomieniu, SD Loader zgłasza swoją gotowość i odpytuje SD Drive o listę plików
• SD Drive po zgłoszeniu sie SD Loadera wysyła mu listę dostępnych plików hex
• hackvision (SD Loader) po otrzymaniu listy wyświetla ją na ekranie telewizora i czeka na wybór
• po wybraniu przez użytkownika pliku, SD Loader wysyła odpowiedni komunikat do SD Drive
• SD Drive otrzymawszy powyższą informacje, ładuje wybrany plik z SD i programuje nim hackvision

Pomysł zacny, prawda? Nie potrzebujemy już komputera. Wrzucamy wszystkie gry na SD i bierzemy konsole na wakacje :)

Tylko jak zrobić żeby to wszystko tak ładnie działało? Oprócz stworzenia oprogramowania dla samego SD Drive będziemy musieli napisać program ładowany do hackvision, który będzie się komunikował z naszym układem – SD Loader. Oba układy mamy spięte przez port szeregowy, więc w kwestii komunikacji wydawałoby się, że nic więcej nie potrzebujemy.

Zaplanowałem sobie następujący schemat komunikacji pomiędzy układami:

Niewiele myśląc zacząłem pisać sobie funkcje do przesyłania komunikatów pomiędzy układami i wszystko zadawałoby się zbliżać wielkimi krokami do upragnionego sukcesu… ale. Jak zwykle MAŁE ALE.

Żeby przekazać listę zawartości karty SD z układu SD Drive do SD Loadera musiałem sobie jakoś te dane przechować, chociaż na chwilę. A przypominam, że nasz SD Drive używa już biblioteki SD.h, biblioteki stk500.h, oraz paru kilobajtów kodu z projektu BootDrive. Okazało się, że próba zadeklarowania całkiem małej struktury przechowującej 8 nazw plików po 8 znaków każda (niby tylko 64bajty), powoduje przepełnienie pamięci i wszystko trafia szlag. Takie uroki programowania mikrokontrolerów. Wieczne kłody pod nogi i mało mało mało miejsca…

Pierwsze co zrobiłem, to odchudziłem cały projekt BootDrive z funkcji debugujących i powywalałem wszystkie możliwe komunikaty błędów. W końcu zakładamy, że nasz projekt będzie działał bezbłędnie, więc te komunikaty i tak NIGDY się nie pojawią ;) prawda?  Pozwoliło mi to dodatkowo na rezygnację z wykorzystania w projekcie biblioteki SoftwareSerial.h, która była używana wyłącznie do debugowania. Po “odchudzeniu” udało mi się bez specjalnego problemu utworzyć strukturę przechowującą nawet 16 nazw plików. Szału nie ma, ale myślę, że na początek zupełnie wystarczy.

Nie będę teraz prezentował całego kompletnego kodu,  wrzucę go na końcu artykułu dla zainteresowanych, bo jest go całkiem sporo. W tej chwili pokażę tylko funkcje odpowiedzialne za komunikację, na przykładzie uproszczonego kodu SD Loadera:

Jak widać kod nie jest specjalnie skomplikowany. Na razie potrafimy zgłaszać gotowość i odbierać listę nazw plików od hosta.

Wyobraźmy sobie teraz, że drugiej stronie kabla siedzi już bardzo podobny kod, wyposażony dodatkowo w obsługę SD i właśnie z karty odczytuje dane i elegancko nam je podaje. I tak właśnie było u mnie. I do tego etapu wszystko działałało jak powinno. Dane przechodziły w obie strony bez zakłóceń, cud miód. Pozostało mi teraz tylko dorobić wyświetlanie listy pobranych nazw, pozwolenie użytkownikowi na dokonanie wyboru i wysłanie tego poleceniem “load<numer>”. Zdawałoby się – nic prostszego!

Dołożyłem bibliotekę TvOut.h i Controllers.h, która umożliwia odczyt stanu przycisków na hackvision. I nagle z komunikacją zaczęły dziać się cuda. Raz działała, raz zupełnie nie, czasem przychodziły tylko urwane kawałki nazw. Kompletny chaos. Ale działo się to tak zupełnie losowo, że zacząłem podejrzewać jakiś błąd “analogowy” w stylu zimny lut, albo luźna wtyka. Przemierzyłem wszystko wzdłuż i wszerz, po czym wiedziony smutnym przeczuciem wyłączyłem bibliotekę TvOut i jak pewnie się domyślacie – wszystko wróciło do normy…

Okazało się, że do generowania sygnału TV wykorzystywany jest timer1, czyli ten sam, który wykorzystywany jest przez port szeregowy (o timerach było nieco więcej  w moim poprzednim artykule). No i klapa – nie da się go “przerzucić” na inny timer, bo tylko ten posiada 16 bitowy rejestr i odpowiednią dokładność. I znów uroki mikrokontrolerów – strasznie tu ciasno.

To był chyba największy moment zwątpienia. Początkowo kombinowałem, aby pobierać wszystkie dane, zanim zainicjuję bibliotekę TvOut, ale niestety. Po pobraniu listy plików i jej wyświetleniu, nadal potrzebuję komunikacji – przecież muszę jeszcze wysłać do SD Drive numer wybranego pliku. A wystarczy raz zainicjować bibliotekę TvOut i cała komunikacja po porcie szeregowym idzie w diabły… Wpadłem nawet przez moment na karkołomny pomysł, aby po dokonaniu przez użytkownika wyboru, zapisywać go pamięci EPROM, restartować układ i przy ponownym starcie, zanim zainicjuję TvOut wysyłać komunikat odczytany z EPROM. Mało to eleganckie, ale co robić… a tu nagle olśnienie. Pośród katalogów dostarczonych z biblioteką TvOut, oprócz katalogu z fontami, znajduje się tez tajemniczy katalog pollserial. Brzmi znajomo?

https://code.google.com/p/arduino-tvout/source/browse/pollserial/

A dodatkowo pośród przykładów dostarczonych z TvOut znajduje się także przykład użycia tej biblioteki, która podobno umożliwia komunikację szeregową wraz z wyświetlaniem obrazu.

W teorii biblioteka ta działa to mniej więcej tak, że port szeregowy odczytywany jest tylko w momencie odświeżania pionowego – czyli przez krótki moment (około 62.5 us) pomiędzy wyświetleniami kolejnych klatek obrazu. Super. Tak się namęczyłem a tutaj gotowe rozwiązanie leży pod ręką. Jest tylko jeden feler – powyższy przykład po skompilowaniu – przynajmniej  u mnie – nie działał. Wyświetlał jakieś krzaki, albo najczęściej nic. Obniżenie prędkości transmisji do 19200bps spowodowało tylko tylko tyle, że więcej znaków wydawało się czytelne, ale niestety dalej nie nadawało się to zupełnie do wykorzystania w projekcie. A już miało być tak pięknie…

Nie ukrywam że w tym momencie dopadły mnie początki depresji. Ale po raz kolejny zakasałem rękawy i rzuciłem się w wir cudzego kodu. Analizując sobie budowę biblioteki pollserial znalazłem następujący fragment:

Hmmm… poszukałem więcej informacji o tym U2X, i okazało się, że jest to jeden z bitów rejestru kontrolnego układu odpowiedzialnego za komunikację szeregową, którego pełna nazwa brzmi:

Double the UART Transmission Speed

Z tego co się doczytałem (mogę się mylić) jest on odpowiedzialny za podwojenie prędkości próbkowania sygnału przychodzącego, co przy wysokich prędkościach transmisji umożliwia zmniejszenie ilości błędnych odczytów. Ale gdzie nam tam do dużych prędkości, więc wiedziony przeczuciem dodałem poniższą linię kodu, tuż za fragmentem, który pokazałem powyżej:

I nagle cud. WSZYSTKO zaczęło działać jak powinno. Dane przelatują w obie strony, wyświetlają się na ekranie… istny szok. Gdyby nie fakt, że była to już czwarta nad ranem i świt nieśmiało spozierał w me okna, pewnie oddałbym się radosnej celebracji sukcesu, odtańczył dziki taniec i otworzył schłodzonego szampana lub ewentualnie cztery. Ale, jako że jestem osobą stateczną i racjonalną, odtańczyłem tylko szybkiego trojaka, ryknąłem gromko “wiwat bocianu” i natychmiast zasnąłem.

Rano z niedowierzaniem uruchamiałem projekt co pół godziny, żeby sprawdzić, czy aby nie śnię. Nie śniłem. Wszystko działało bez zastrzeżeń i w dodatku nie chciało przestać :D

Od tej chwili  nie było już żadnych większych problemów. W kilka godzin dokończyłem cały kod i zabrałem się w końcu za pisanie swoich gier. Oto jak prezentuje się gotowy działający SD Drive/Loader:

Jakość filmu nie powala, ale widać wystarczająco dużo i widać że działa! Pozostało mi jeszcze przestawić ostateczny kod wszystkim zainteresowanym “nerdom”. Ze względu na jego sporą objętość, nie będę wklejał go bezpośrednio, tylko wrzucę w postaci spakowanej:

• SD_Drive.zip
• SD_Loader.zip

Niestety, musicie wybaczyć fakt, że powyższy kod skomentowany jest raczej szczątkowo. Ale jeżeli uważnie czytaliście artykuł, to nie powinniście mieć problemu z jego zrozumieniem. Wszelkie Wasze wątpliwości, chętnie rozwieję w komentarzach. A do zrobienia pozostało mi jeszcze:

• stronicowanie w przypadku ilości większej niż 8 plików
• podmiana bootloadera w hackvision na ten z Arduino UNO – pozwoli to na dwukrotnie szybsze programowanie

Po tych wszystkich moich perypetiach i wyzwaniach z jakimi przyszło mi się mierzyć, naszła mnie pewna błyskotliwa refleksja:

Nie ufaj kodowi pobranemu z internetu ślepo i bezwzględnie. To, że Ty nigdy nie robisz błędów, nie oznacza, że inni też tak potrafią :D

A tak już bardziej serio, to czasem warto nauczyć się czegoś na cudzych błędach. Chociaż nie zawsze jest łatwiej.

Dzięki, że chciało Wam się czytać, jak zwykle zapraszam do komentowania i do zobaczenia (mam nadzieję) w następnym artykule.