Chcąc nie chcąc, uczyłem się w ramach zajęć na ETI wykorzystywać MATLAB-a, a więc przy okazji i Octave’a, do podstawowych obliczeń, szybko jednak zapominałem pokręconą składnię tego środowiska. Brakowało mi też wsparcia dla obliczeń analitycznych i możliwości pisania programów z użyciem wygodnej składni. Potrzebowałem czegoś, co pozwoli mi zarówno policzyć analitycznie całkę, z którą nie poradzi sobie mój kalkulator (Casio Algebra FX 2.0 Plus), wykreślić przebieg dowolnej funkcji, wyznaczyć DFT sygnału, jak i szybko zaimplementować jakiś własny algorytm.

Cóż więc mi pozostawało? SciPy, Maxima, Scilab? A może coś jeszcze innego? W końcu trafiłem na środowisko Sage.

Powiedzieć, że Sage jest programem matematycznym, to nieścisłość. Określić go jako zgrabne środowisko do wszelkiego rodzaju obliczeń to nadużycie, przynajmniej jeżeli chodzi o mój pogląd na piękno. Uważam, że tutaj najbardziej pasuje określenie „duct tape”. Jeżeli jesteś matematykiem lub cenisz eleganckie rozwiązania programistyczne (albo miejsce na twardym dysku…), Sage może nie wzbudzić Twojego zachwytu. Jeżeli jednak masz w sobie ducha MacGyveryzmu, Sage może okazać się świetnym rozwiązaniem wielu problemów.

Sage jest zbiorem programów i bibliotek matematycznych, takich jak Maxima, SciPy czy GSL, powiązanych Pythonem i okraszonych interfejsem CLI i dziwacznym GUI w postaci… strony WWW. Jego niewątpliwą zaletą jest darmowość i otwartość (możemy więc poznać sposób, w jaki przeprowadzane są obliczenia).

Korzystam z Arch Linuksa, gdzie Sage dostępny jest w repozytorium AUR jako sage-mathematics i sage-mathematics-bin. Pierwszy pakiet chyba nie chciał mi się kompilować, a w każdym razie miałem z nim jakiś problem, ściągnąłem więc źródła bezpośrednio ze strony programu i próbowałem sam go zbudować. Niestety, udało mi się rozwiązać tylko część problemów i w końcu zakończyłem na błędzie po dwóch czy trzech godzinach kompilacji. Zrezygnowany sięgnąłem po binarkę. Pomijając fakt, że pobrałem bodaj 400MB, instalacja przebiegła bezboleśnie. Co prawda z dysku zniknęło mi 1,2GB, ale nie byłem zdziwiony — o ile dobrze zauważyłem, Sage zawiera w sobie wszystkie niezbędne biblioteki i programy, więc mam teraz zdublowanego Pythona, Maximę, SciPy i pewnie sporo innych rzeczy…

Przejdźmy jednak do meritum. Po uruchomieniu program może krzyczeć o odpowiednie uprawnienia do katalogu konfiguracyjnego. Poniższa komenda powinna rozwiązać problem:

# chmod +x ~/.sage/ipython

Teraz odpalamy powłokę Sage’a i możemy przystępować do liczenia. Jednak od interfejsu linii poleceń znacznie wygodniejszy jest interfejs webowy, uruchamiany poleceniem notebook(). Jego działanie polega na wystartowaniu serwera WWW i przeglądarki z aplikacją webową. Jest to rozwiązanie w takim samym stopniu dziwne, co wygodne. Zgodnie z nazwą, serwuje nam ono coś w rodzaju notesów, w których możemy zapisywać obliczenia i ich wyniki. Przyznaję, że jest to bardzo intuicyjne rozwiązanie. Niestety, jesteśmy pozbawieni jakiegoś zgrabnego IDE, pozwalającego wykorzystać możliwości Sage’a do pisania dłuższych skryptów czy programów. Może to i lepiej…

Odłóżmy jednak na bok ironiczne uwagi i przyjrzyjmy się bliżej notebookowi. Screencasty pokazują bogate możliwości tego interfejsu. W szczególności należy zwrócić uwagę na tryb interaktywny — możliwość szybkiego napisania skryptu, który na bieżąco wizualizuje parametry ustawiane suwakiem, zrobiła na mnie wrażenie. To aż się prosi o wykorzystanie w szkołach czy na uczelniach!

Wykresy są całkiem estetyczne, do wypisywania wzorów można wykorzystać składnię LaTeX-a, a możliwość zapisania stanu pracy i powrotu w każdej chwili do obliczeń jest bardzo wygodna. Brakuje mi tylko skrótu klawiaturowego, który obliczałby wyrażenie bez przenoszenia do kolejnego wiersza (a tak działa Shift + Enter). Może jednak to tylko mój brak znajomości klawiszologii.

Jako podsumowanie cisną mi się na usta słowa: „To jest naprawdę świetne narzędzie, ale…”. Owych „ale” jest, niestety, sporo: od samej idei zlepienia różnych programów matematycznych, przez duże rozmiary aplikacji po dziwny interfejs. W zamian jednak otrzymujemy ogromne możliwości, pomysłowy tryb interaktywny i w sumie niegłupią ideę notebooków. Warto zatem instalować? Szczerze mówiąc, gdyby projekt Wolfram|Alpha wystartował trochę wcześniej, to pewnie nie sięgnąłbym po Sega’a, w każdym razie nie po to, by policzyć analitycznie kilka całek czy wykreślić przebieg funkcji. Myślę jednak, że warto spróbować przygody z tą aplikacją czy to przez LiveCD, czy przez instalację binarki. W mojej krótkiej recenzji nie zabrakło złośliwości, ale nie mam zamiaru usuwać w najbliższym czasie programu z dysku — czas pokaże, czy to narzędzie rzeczywiście okaże się niezastąpione.

Nut/OS jest modularnym systemem operacyjnym czasu rzeczywistego (RTOS) opracowanym w ramach projektu Ethernut. Ethernut jest projektem typu „open source hardware”, mającym na celu udostępnienie systemów wbudowanych obsługujących Ethernet.

Nas w tej chwili interesuje jednak tylko część software’owa tego projektu, czyli Nut/OS, udostępniający gotowy stos TCP/IP i obsługę protokołów takich jak DHCP, DNS, SMTP, a nawet HTTP czy FTP. Nut/OS bardzo dobrze wspiera kompilator AVR-GCC, a poza tym autorzy projektu przewidzieli możliwość pracy na Linuksie, więc czas przystąpić do dzieła.

Zaczynamy od ściągnięcia źródeł, rozpakowania i uruchomienia konfiguracji:

$ tar jxvf ethernut-4.8.2.tar.bz2
$ cd ethernut-4.8.2
$ ./configure

Powinniśmy zobaczyć m.in.:

configure: nutconfgui is enabled

co oznacza, że będziemy mogli skorzystać z konfiguratora graficznego. W innym wypadku zapewne będziemy musieli doinstalować wxWidgets lub inną bibliotekę, której brak wskaże nam konfigurator.

Ja napotkałem inny problem, związany ze specjalną biblioteką wxPropertyGrid, wymaganą przez narzędzie nutdisc, czyli Discoverera:

configure: WARNING: wxpropgrid not found
[…]
configure: nutdisc requires propgrid

Discoverer nie jest na szczęście niezbędny, jest to dodatkowy program, umożliwiający odnalezienie w sieci Ethernet nie do końca skonfigurowanych hostów, pracujących pod kontrolą Nut/OS-a.

Niestety, u mnie Ethernut najpierw nie widział skompilowanej biblioteki, a po wprowadzeniu zmian w configure i tak kończył kompilację z błędem. Koniec końców zignorowałem więc brak Discoverera i odpaliłem:

$ make
$ make check
$ su -c "make install"

Podczas kompilacji może nas jednak spotkać kolejna przykra niespodzianka: proces przerwie się niespodziewanie, sypiąc błędami, zapoczątkowanymi przez komunikat

error: wx/setup.h: Nie ma takiego pliku ani katalogu

Na szczęście i na to jest prosta rada:

# ln -s /usr/lib/wx/include/gtk2-unicode-release-2.8/wx/setup.h /usr/include/wx-2.8/wx/setup.h

Teraz make clean i jazda od nowa z kompilacją!

Po zainstalowaniu nie zmieniamy katalogu, tylko uruchamiamy nutconf i wybieramy plik konfiguracyjny MMnet104.conf.

Następnie klikamy Edit -> Settings. W zakładce Build Source Directory powinien wskazywać na katalog, do którego rozpakowaliśmy źródła, zaś Platform powinien mieć wartość avr-gcc. Jako Build Directory podałem katalog ~/test/build, zaś jako Install Directory — ~/test/build/lib. W zakładce Samples wskazałem ~/test/samples.

Teraz klikamy Build -> Build Nut/OS i Build -> Create Sample Directory. W efekcie uzyskujemy gotowe środowisko pracy: jądro RTOS, liczne biblioteki i przykładowe aplikacje. Możemy zacząć np. od serwera HTTP — po wydaniu komendy make w katalogu samples/httpd powinniśmy otrzymać HEX-a gotowego do wgrania do naszego mikrokontrolera.

Przy okazji wspomnę, iż warto skorzystać z debugowania za pomocą interfejsu RS232. Interfejs ten coraz rzadziej spotyka się w komputerach, jeżeli jednak korzystamy z płytki wyposażonej w konwerter RS232<->USB na bazie układu scalonego FTDI, Linux powinien nam automatycznie wykryć port i przypisać go do urządzenia /dev/ttyUSB0. Na PC-cie wystarczy uruchomić terminal RS232, np. GTKTerm czy CuteCom (baudrate odczytamy z kodu źródłowego; w moim przypadku parametry transmisji wynosiły 115200, 8N1), a w kodzie programu mikrokontrolera umieścić wywołania printf() czy puts(), raportujące stan urządzenia.

Jedyną niedogodnością jest fakt, iż po odłączeniu kabla lub zasilania płytki oba terminale zawieszają się, zajmując przy okazji całą moc CPU PC-ta. Dlatego w takich sytuacjach warto pamiętać o wcześniejszym rozłączeniu połączenia w terminalu.

Po konsultacjach uzgodniliśmy, że przed dramatyczną próbą wybebeszenia ATmegi i potraktowania ją programatorem równoległym spróbujemy użyć JTAG-a. Szczęśliwie okazało się, że da się w miarę prosto zbudować taki programator w warunkach domowych.

W Internecie nietrudno natrafić na opisy wykonania JTAG-a, także w języku polskim. Jak widać, schemat ideowy jest całkiem prosty, a elementy dosyć popularne i łatwe do zdobycia. Wyjątkiem jest oscylator kwarcowy o częstotliwości 7,3728MHz. Ja znalazłem go dopiero w czwartym sklepie (jeżeli ktoś mieszka w trójmieście, radzę od razu odwiedzić sklep Jacktronic). Warto też pamiętać, by kupić dwie ATmegi16, dzięki czemu będziemy mieli jeden czysty mikrokontroler, który posłuży do sprawdzenia poprawności działania JTAG-a.

Postępując zgodnie z opisem powinniśmy uruchomić całość w miarę szybko i sprawnie. Ja napotkałem tylko na problem z wgraniem bootloadera za pomocą programatora AVR USBasp, który opisywałem kilka miesięcy temu. Programator ciągle przerywał pracę, strasząc jakimś „broken pipe”. Nie udało mi się znaleźć wytłumaczenia tego problemu — być może jest to kwestia zakłóceń, powstających na skutek montażu na płytce stykowej. W każdym razie wystarczy odrobina cierpliwości i wgrywanie wsadu aż do skutku (w trybie spowolnionego programowania, które wlecze się niemiłosiernie, ale w końcu odnosi skutek). Co do samego wsadu, to radzę zastosować gotowy (u mnie samodzielna kompilacja nie zaowocowała działającą binarką).

Jeżeli komuś nie chce się przeliczać fuse bitów dla ATmegi16 w JTAG-u, poniżej podaję gotową komendę dla avrdude (Fuse Low Byte równy 0xFF i Fuse High Byte równy 0xD8).

$ avrdude -p m16 -c usbasp -v -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m

Przypominam, że należy starannie zaciskać złącza IDC10 na taśmie programującej, a w przypadku użycia scrossowanego kabla RS232 należy zamienić odpowiednie końcówki w gnieździe.

Jeżeli ktoś chciałby uruchomić cały programator pod Linuksem, to, niestety, nie jestem w stanie służyć pomocą. Pod Linuksem wgrałem tylko bootloader, a resztę załatwiło AVR Studio pod Windowsem.

Co do naszej nieszczęsnej ATmegi128 — za pomocą JTAG-a odblokowałem lock bity, ustawiłem poprawną konfigurację oscylatora i wyłączyłem flagę WDTON, która niepotrzebnie włączała watchdoga, dzięki czemu moduł w końcu ruszył.

Na szczęście kilka przejściówek pozwoliło to wszystko ze sobą sprawnie połączyć:

# pacman -S avrdude

Sprawdzamy, czy programator jest poprawnie podłączony. Komenda

# avrdude -p t13 -c usbasp -v

(obecnie używam ATtiny13) powinna m.in. odczytać fuse bity z naszego uC. Nie dajmy się tu zwieść informacji o używanym porcie

Using Port            : /dev/parport0

gdyż, rzecz jasna, nie korzystamy wcale z LPT, lecz z USB.

Spróbujmy jednak szczęścia z poziomu użytkownika:

$ avrdude -p t13 -c usbasp -v

Jeżeli znów się nam udało, możemy spokojnie zająć się pracą, jednak komunikat

avrdude: Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
avrdude: error: could not find USB device "USBasp" with vid=0x16c0 pid=0x5dc

wróży nam odrobinę walki o uprawnienia.

Zacznijmy od tego, że AVRDUDE podaje nam identyfikator urządzenia, co pomaga szybko sprawdzić, jak wygląda dostęp do niego. Poleceniem

# lsusb -v|grep -i 16c0:05dc

odnajdujemy ścieżkę do naszego programatora. Przykładowo może to wyglądać tak:

Bus 006 Device 006: ID 16c0:05dc

Nie jest trudno rozszyfrować tę informację i wyświetlić uprawnienia urządzenia:

# ls -l /dev/bus/usb/006/006

Zapewne zobaczymy, że do naszego programatora może pisać tylko root. Tu z pomocą przychodzi nam udev, który ochoczo przystanie na zmianę uprawnień, jeżeli ładnie go o to poprosimy. Tworzymy plik /etc/udev/rules.d/95-myrules.rules, który zawiera tę prośbę:

# Programator AVR USBasp
ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", ATTRS{product}=="USBasp", GROUP="usb", MODE="0664"

Tu należy zauważyć, że nazwa pliku zaczyna się od 95, aby nasze reguły zostały przetworzone pod koniec przeglądania urządzeń. Dzięki temu domyślne ustawienia nie nadpiszą naszych. W razie problemów możemy użyć opcji MODE:="0664", która zablokuje przetwarzanie uprawnień przez inne reguły.

Oczywiście, dla bezpieczeństwa, a raczej dla elegancji, nie zastosowaliśmy uprawnień 0666, lecz utworzyliśmy grupę usb z możliwością zapisu. Grupę tę dodajemy chyżo do systemu, po czym się do niej dopisujemy:

# groupadd usb
# gpasswd -a użytkownik usb

Odłączamy i podłączamy programator, po czym sprawdzamy, czy możemy już zaprogramować uC z poziomu użytkownika. Jeżeli nie, problemu należy szukać przede wszystkim w uprawnieniach. Przypominam, że po ponownym podłączeniu programator będzie dostępny pod innym adresem — zapewne o numer większym, a więc w tym przypadku: /dev/bus/usb/006/007, zresztą w każdej chwili możemy to sprawdzić za pomocą lsusb.

W przypadku kłopotów można też spróbować polecenia

# udevadm control --reload-rules

lub po prostu restartu komputera.

Niestety, ciągle coś mi nie grało — wartości w rejestrze timera znacząco odbiegały od moich przewidywań. W końcu postanowiłem uruchomić USART, żeby móc na bieżąco wysyłać mierzone czasy (dotąd kilka diod informowało mnie, czy czasy mieszczą się w zadanych granicach). Po uruchomieniu GtkTerma, okazało się, że transmisja przebiega poprawnie ale nie przy 9600bps, jak ustawiłem, lecz przy 1200bps. Odczytałem więc fusy

$ uisp -dprog=stk200 -dlpt=/dev/parport0 --rd_fuses

otrzymując

Fuse Low Byte      = 0x64

Wyglądało na to, że najstarszy bit (CKDIV8) jest wyzerowany. Więc skąd ośmiokrotnie niższe taktowanie? Po głębszej analizie dokumentacji i chwili googlowania w końcu zrozumiałem — wartość 0 oznacza programmed, czyli ustawienie fuse bita.

Poprawiłem więc F_CPU w Makefile z 8000000 na 1000000 i… transmisja oszalała. Rzut oka na tabelę błędów USART (jakiś dobry człowiek zamieścił ją w dokumentacji) — aha, przy takim taktowaniu dla 9600bps mamy błąd zegara -7,0%. Zmieniłem więc bitrate na 4800bps i teraz wszystko zdaje się być w porządku.

Po pierwsze większość pakietów musiałem zainstalować z AUR, czyli repozytorium źródeł utrzymywanych przez użytkowników, bo w oficjalnych binarkach był tylko avrdude.

Gdy się już z tym uporałem, okazało się, że avrdude nie może dostać się do portu LPT. Zmieniłem więc ustawienia, ale po restarcie wszystko wróciło do stanu wyjściowego. W końcu znalazłem sposób na trwałą zmianę uprawnień. Do /etc/udev/rules.d/udev.rules w sekcji Permissions and Symlinks dopisałem:

KERNEL=="parport[0-9]*",        GROUP="lp"

Rzecz jasna, musimy dodać się później do odpowiedniej grupy:

# gpasswd -a użytkownik lp

Mam nadzieję, że najbliższa aktualizacja udev nie nadpisze moich ustawień.

Sam proces spawania nie był szczególnie trudny, tym bardziej, że spawarka, choć ręczna, nie automatyczna, była przygotowana do pracy.

Aby zespawać dwa światłowody trzeba usunąć z nich warstwę ochronną — jest to jakieś tworzywo, które nie nadaje się do spawania (w przeciwieństwie do samego włókna, które w tym wypadku musi być wykonane ze szkła kwarcowego). Do wykonania tej czynności służy stripper.

Włókna muszą być równo przycięte, tak aby podczas justowania w spawarce stykały się całą płaszczyzną przekroju. Szkła kwarcowego nie da się ciąć tak, jak np. metalu, gdyż jest zbyt kruche. Należy zatem, podobnie jak szklarz, zarysować lekko włókno. Jeżeli w tej samej chwili rozciągniemy światłowód, powinien ładnie pęknąć. Pomaga nam w tym specjalna obcinarka.

Tak spreparowaną parę włókien umieszczamy w spawarce, justujemy, czyli wyrównujemy we wszystkich płaszczyznach i dosuwamy do siebie. Czynność tę należy wykonać z dokładnością rzędu mikrometra, a nawet lepszą — pomaga w tym mikroskop, przedstawiający obraz w dwóch płaszczyznach jednocześnie (z góry i z boku). Gdy światłowody są poprawnie ustawione, załączamy łuk elektryczny i, w razie potrzeby, korygujemy położenie włókien podczas samego procesu spawania.

Później należy zabezpieczyć spaw, gdyż, jak się naocznie przekonaliśmy, pozbawione warstwy ochronnej włókno jest bardzo kruche.

P.S. Półtora roku temu mieliśmy okazję zobaczyć w akcji automatyczną spawarkę, która zamiast mikroskopu posiada kamery i monitor, a samo justowanie jest automatyczne.

Pierwszy kod to [numer]#, gdzie [numer] to numer wpisu w książce telefonicznej karty SIM. Po jego wybraniu pokazuje się menu z numerami w kolejności, w jakiej zapisane są na karcie. Po naciśnięciu zielonej słuchawki następuje wybranie numeru (być może w niektórych aparatach dzieje się to od razu po wpisaniu kodu). Po co to komu? Otóż jeżeli zapiszemy sobie najważniejsze osoby w pierwszych wpisach na karcie SIM (na ogół telefon pozwala określić numer rekordu), możemy do nich dzwonić po naciśnięciu trzech przycisków. Jest to mniej wygodne niż szybkie wybieranie, ale w moim przypadku się sprawdza.

Zaletą tego rozwiązania jest możliwość przypisania szybkiemu wybieraniu innej funkcji, np. skrótów do najczęściej używanych opcji menu. Ponadto mój telefon pozwala na posługiwanie się kodami w stylu 6# także w terminarzu, który interpretuje je jak podany explicite numer telefonu. Zasadniczą wadą jest konieczność pokopiowania wpisów do odpowiednich rekordów, a ponieważ w pierwszych rekordach już na pewno coś jest, mamy chwilę zabawy.

Drugi kod jest powszechnie znany. To *#06#, odczytujący unikalny numer IMEI aparatu, czasem pozwalający odczytać także wersję oprogramowania. IMEI pozwala na zablokowanie konkretnego telefonu w przypadku kradzieży (szczegóły na temat blokowania skradzionego telefonu). Oczywiście, numer należy sobie zapisać wcześniej…

Wczoraj postanowiłem wreszcie zabrać się za uruchomienie płytki testowej AVT3500 pod Linuksem, aby móc powoli przerabiać kurs AVR GCC z EdW. Nie mogłem znaleźć oryginalnego „programatora”, tj. kabla podłączanego na żywca do LPT, więc skorzystałem z programatora AVT2550/P, zgodnego z STK200. Płytka testowa nie ma typowego dwurzędowego gniazda ISP, znalazłem jednak skleconą kiedyś przejściówkę, więc od razu mogłem wszystko ze sobą połączyć. Problem w tym, że zaprogramowanie uC za pomocą tej przejściówki nigdy mi się nie udało, a próbowałem chyba nawet na Windows z AVRStudio…

Kompilacja za pomocą avr-gcc przebiegła bez większych zgrzytów, jednak komputer w ogóle nie widział AVR-ka. Zarówno uisp, jak i avrdude zgłaszały błędy wyraźnie sugerujące, że są kłopoty z komunikacją. Przez kilka godzin ściągałem i instalowałem jakieś beznadziejne programy, zmieniałem opcje, czytałem fora, mierzyłem napięcia… W końcu wymieniłem nawet scalaka, bo miałem kilka w zapasie (wbił się w podstawkę tak, że chyba już go nigdy nie wyjmę – czemu nie dałem precyzyjnej?).

Wraz z upływem czasu coraz głośniej słyszałem: „Czy dobrze zlutowałeś przejściówkę? Czy dobrze…”. W akcie desperacji wyłączyłem komputer, sprawdziłem połączenia i, rzecz jasna, okazało się, że skrosowałem dwa kable, czy to przez pomyłkę, czy też w przebłysku głupoty (były to linie MISO i MOSI). W każdym razie o drugiej w nocy wreszcie ujrzałem

vmario@pingwinek:~$ uisp -dprog=stk200 -dlpt=/dev/parport0
Atmel AVR AT90S2313 is found.

Nigdy nie lekceważ kabelków.