vmario techblog » Elektronika

Edytor heksadecymalny na Linuksa

vmario — Wed, 10 Mar 2010 21:17:53 +0000

Nie tylko crackerzy i miłośnicy inżynierii wstecznej potrzebują czasem zajrzeć do jakiejś binarki. Niejeden elektronik potwierdzi, że dobrze jest mieć możliwość odczytu czy nawet edycji tzw. „wsadów”, a sam nieraz podglądałem pliki wykonywalne, by sprawdzić, z jakich bibliotek korzystają, w szczególności, gdy programu nie dawało się uruchomić i nie było mowy o skorzystaniu z lsof.

Na ogół używałem do tego po prostu mojego ulubionego Vima i to w zwykłym trybie tekstowym. Uruchomienie trybu heksadecymalnego, zwłaszcza z możliwością edycji wymaga zaklęć tak długich i bezecnych, że do dziś boję się je wpisywać.

Zmuszony jednak przez los postanowiłem wyposażyć się w jakiś porządny edytor heksadecymalny, najlepiej działający w X-ach, żeby mieć pełną wygodę użytkowania.

Na pierwszy ogień poszedł GHex, ale odpadł w przedbiegach ze względu na stabilność i małe możliwości. Następnie trafiłem na Blessa. Szczęśliwie nie zauważyłem, że został napisany w Mono/Gtk# (nie lubię Mono) i dałem mu szansę. Program ma możliwości chyba niewiele większe niż GHex, ale działa całkiem sprawnie.

Z ciekawości sprawdziłem jeszcze, co zaoferuje produkt ze stajni KDE — Okteta. Pierwsze wrażenie było negatywne — ot, kobylasta aplikacja o przeładowanym interfejsie, która długo się uruchamia, a na dodatek zdarzyło się jej nawet wyłożyć.

Warto jednak dać temu programowi szansę, gdyż jest to prawdziwy kombajn. Nie nadaje się może do edycji dysków twardych, ale świetnie sprawdza się w pracy z plikami. Z ciekawszych opcji warto wymienić:

przeglądanie wielu plików w kartach,
dzielenie okna w pionie i poziomie,
obliczanie wielu rodzajów sum kontrolnych dla wskazanego obszaru,
zapełnianie obszaru wzorcami,
wykonywanie operacji bitowych,
wyszukiwanie łańcuchów znaków (program „wyłapuje” wewnątrz pliku binarnego całe fragmenty tekstu, pasujące do podanej frazy).

Ponadto wystarczy poświęcić chwilę na zagospodarowanie przestrzeni roboczej, by praca z programem stała się przyjemna i intuicyjna. O ile nie pojawią się problemy ze stabilnością, Okteta stanie się zatem moim podstawowym narzędziem do hackowania plików binarnych. A może Czytelnicy znają jakieś inne dobre hex edytory?

Minicom jako terminal szeregowy

vmario — Fri, 05 Mar 2010 21:21:24 +0000

Ostatnio dużo pracuję na porcie szeregowym RS-232, przez który obsługuję także linuksową powłokę. Niezbędny jest do tego emulator terminala szeregowego. Dotychczas korzystałem przede wszystkim z programu GTKTerm, znacznie rzadziej z CuteCom. Na dłuższą metę w GTKTermie doskwierają dwie niedogodności. Po pierwsze na moim systemie lubi on wstawiać od czasu puste linie, jest to jednak tylko pewien wizualny mankament. Po drugie GTKTerm nie radzi sobie z edycją już wydrukowanej linii tekstu, przez co przeglądanie historii poleceń powłoki owocuje ciągłym zadrukowywaniem ekranu, nie mówiąc już o różnej maści paskach postępu, które błyskawicznie zapełniają dostępną historię ekranu; w tych warunkach na vi w ogóle nie da się pracować. Po trzecie — aplikacja ma bardzo krótką historię ekranu, przez co zwykłego dmesg-a trudno obejrzeć w całości.

CuteCom w ogóle jest nieporozumieniem: nie obsługuje kolorów, wejście działa w trybie liniowym a nie znakowym, a jego log potrafi zapchać RAM, zwłaszcza jeżeli będzie monitorował port, na którym działa programator ISP (co ma miejsce w ATmedze128). W pewnych zastosowaniach mógłby się sprawdzić, ale na pewno nie jest to wygodny emulator terminala.

Oczywiście, oprócz tych dwóch programów, znałem też Minicoma, ale zawsze miałem go za program bardzo nieprzyjazny użytkownikowi i nadający się tylko do współpracy z modemami. Okazuje się jednak, że bardzo prosto jest zmusić go do pracy w roli pełnoprawnego terminala szeregowego. To tylko kwestia dodania kilku opcji w wierszu poleceń:

$ minicom -m -o -w -c on

lub krócej:

$ minicom -mowc on

Znaczenie poszczególnych opcji:

-m umożliwia korzystanie ze skrótów klawiaturowych z wykorzystaniem Alta (np. Alt+Q w celu wyjścia z programu),
-o wyłącza zupełnie w tym przypadku zbędną inicjalizację modemu,
-w zawija wiersze,
-c on włącza kolorki.

Jeżeli nie chcemy za każdym razem wpisywać wszystkich przełączników, wystarczy dopisać do ~/.bashrc:

export MINICOM="-m -o -w -c on"

i uruchamiać minicom bez ręcznego dopisywania tych opcji.

Po starcie pod Alt+Z zobaczymy wykaz komend, z których najbardziej będzie nas interesować Alt+O, czyli konfiguracja. Należy pamiętać, by w ustawieniach portu szeregowego wyłączyć kontrolę przepływu, a w ustawieniach ekranu dobrać odpowiedni dla nas schemat kolorów (czerwony pasek stanu to moim zdaniem przesada).

Zdaje mi się, że podczas zmiany konfiguracji portu program lubi zawiesić połączenie. Na szczęście rzadko muszę zmieniać parametry portu, zresztą wystarczy wtedy ponownie uruchomić Minicoma. Inny problem, który zauważyłem, to nieprawidłowe wyświetlanie polskich znaków. Znaki dwubajtowe wprawdzie wyświetlają się, ale są poprzedzone znakiem zapytania. Próbowałem korzystać z opcji -L, -l, -8 i zmieniać tablicę znaków, ale nie udało mi się z tym uporać. Brakuje mi też trybu szesnastkowego, dlatego nie mogę całkowicie zrezygnować z GTKTerma.

Niemniej Minicom okazał się całkiem niezłą aplikacją, a jego zaletą jest popularność (nie powinno być problemów ze znalezieniem go w repozytorium) i możliwość pracy bez środowiska graficznego.

PS Miłośnikom programu PuTTY warto przypomnieć, że radzi on sobie całkiem nieźle także z RS-232!

Przywracanie SAM-B-y w MMnecie1002

vmario — Thu, 04 Mar 2010 15:04:48 +0000

Eksperymentując z bootloaderami i jądrami Linuksa na AT91SAM9260 zablokowałem sobie w pewnym momencie moduł MMnet1002. Mikrokontroler programowany jest przez atmelowski interfejs ISP o nazwie SAM-BA (SAM Boot Assistant), który jest bardzo wygodny, bo nie wymaga żadnego sprzętowego programatora — wystarczy podłączyć się przez USB do ARM-a i użyć oprogramowania dostarczonego przez Atmela.

Niestety, nie jest tak, że tryb programowania włącza podanie odpowiedniego stanu na jakiś pin i restart mikrokontrolera. SAM-BA znajduje się na samym końcu sekwencji startowej i jest uruchamiana tylko wtedy, gdy nie uda się wczytać programu z pamięci DataFlash i NANDFlash. Wprawdzie na płytce MMnet1002 znajduje się zworka SAMBA podłączona do pinu PC15 (NWAIT), której założenie w połączeniu z dwukrotnym restartem wprowadza system w stan programowania, ale ta tajemnicza metoda nie zawsze skutkuje. W szczególności, gdy doprowadzimy system do takiego stanu, że będzie w stanie wczytać z pamięci wadliwy program, utkniemy w miejsu — algorytm startowy stwierdzi, że program wczytano i nie ma potrzeby uruchamiania SAM-B-y, nawet gdy program będzie błędny. W efekcie na konsoli DBGU zobaczymy tylko smutne:

RomBOOT

>

Jak się ratować w takiej sytuacji? Szereg rozwiązań znajdziemy w nocie Atmela AT91SAM9260-EK SAM-BA Recovery. Przede wszystkim bootloader AT91Bootstrap może być skompilowany tak, że podczas startu monitoruje stan wskazanego pinu i w razie żądania (zwarcia pinu do masy), czyści pierwszy blok pamięci NANDFlash, co uniemożliwia wczytanie z niej programu, a w konsekwencji wywołanie SAM-B-y. Nota mówi o pinie ~~PB4~~ PA31 (chodzi o przycisk BP4 na płytce ewaluacyjnej AT91SAM9260-EK, podłączony do pinu PA31), ale dla MMneta1002 powinien to być PC15, podłączony do zworki SAMBA. Trick ten jednak nie pomoże nam, jeżeli majstrowaliśmy przy AT91Bootstrapie.

Podobne rozwiązanie stosuje aplikacja AT91bootstrap-recovery, którą można wgrać na kartę DataFlash, trzeba jednak najpierw mieć taką kartę i możliwość jej podłączenia do systemu. Zatem to rozwiązanie odpada, tak samo jak użycie programatora SAM-ICE, którego nie posiadam.

Na szczęście jest prosta metoda sprzętowa, odradzana przez Atmela, ale moim zdaniem najlepsza. Wystarczy odciąć pamięć nieulotną od mikrokontrolera, choćby na krótką chwilę podczas startu. Zostanie uruchomiona SAM-BA, a wtedy wystarczy z powrotem podłączyć pamięć i programować.

Moja płytka wyposażona jest w pamięć NANDFlash, którą można w prosty sposób odciąć, wylutowywując rezystor R48 (0Ω) i zastępując go zworką w pozycji NF (możliwe, że niektóre płytki domyślnie są przygotowane właśnie w taki sposób — wtedy nie trzeba nawet wyciągać lutownicy i można od razu przejść do kolejnego kroku). Na poniższych zdjęciach zaznaczyłem, który rezystor należy usunąć i którą zworka nas interesuje.

Teraz, aby zaprogramować mikrokontroler, wystarczy zdjąć zworkę NF, zrestartować system i założyć zworkę z powrotem.

JTAG do ATmegi w wersji USB

vmario — Wed, 20 Jan 2010 18:25:52 +0000

Jakiś czas temu przedstawiałem prosty układ elektroniczny pełniący rolę JTAG-a dla mikrokontrolerów ATmega. Był to znaleziony w Sieci klon firmowego JTAGICE, który to klon mimo prostej budowy znakomicie pełni swoją rolę. Jedyną istotną jego wadą jest sterowanie przez port szeregowy RS-232. Port ten jest już rzadkością w komputerach, co wymusza stosowanie przejściówek USB<–>RS-232. Z mojego doświadczenia wynika, że przejściówki takie często sprawiają wiele kłopotów, dlatego doszedłem do wniosku, że czas ulepszyć JTAG-a, a przy okazji dorobić się wreszcie czegoś konkretnego w miejsce poprzedniej prowizorki.

Tak naprawdę nie czekało mnie wiele pracy — musiałem tylko dodać do układu jakąś przejściówkę USB<–>RS-232 i zaprojektować płytkę, najlepiej pod elementy SMD. W roli konwertera postanowiłem wykorzystać układ scalony firmy FTDI — FT232RL. Kosztuje on wprawdzie kilkanaście złotych, ale ma wbudowany zegar i do działania nie potrzebuje prawie żadnych elementów zewnętrznych.

Opis układu

Schemat ideowy można obejrzeć na poniższym rysunku.

Do ATmegi16 dodałem złącze J3, służące do wgrywania firmware’u, a MAX232 zastąpiłem wspomnianym FT232RL. Ponieważ chciałem wykorzystać możliwość zasilania JTAG-a i debugowanego systemu z portu USB, musiałem również zastosować automatyczny przełącznik zasilania w postaci tranzystora T1 z obwodem soft start (R1, C5). Specyfikacja USB uwzględnia różne tryby zasilania i korzystające z tej magistrali urządzenia powinny w odpowiedni sposób ograniczać swój prąd. Oczywiście FT232RL potrafi przejść w odpowiedni tryb, powiadamiając przy tym zewnętrzne urządzenia, np. po skonfigurowaniu wyjścia SLEEP#, ale takie rozwiązanie nie sprawdziłoby się we współpracy z dołączonym urządzeniem debugowanym. Dlatego zastosowałem polecany przez notę aplikacyjną tranzystor sterowany sygnałem PWREN# (tu: nóżka CBUS3). W razie potrzeby tranzystor odcina zasilanie i całość przechodzi w stan uśpienia.

Diody D1, D2 i D3 mogą być pomocne w diagnozowaniu problemów z JTAG-iem. D2 informuje o tym, iż port USB przyznał nam zasilanie, D1, iż zachodzi komunikacja z komputerem, zaś D3 mówi o pracy samego interfejsu JTAG.

Montaż i uruchomienie

Płytkę drukowaną zaprojektowałem z myślą o jej wykonaniu w warunkach domowych, stąd dość duże przelotki i brak ścieżek prowadzonych do złącz po stronie elementów.

Podczas montażu musimy zwrócić szczególną uwagę na układ FT232RL. Jest on wykonany w stosunkowo drobnym rastrze i przy jego lutowaniu warto wspomóc się topnikiem. Ja używałem RF800.

Jeżeli sami wykonywaliśmy płytkę i musimy lutować przelotki, należy pamiętać, iż kilka z nich znajduje się pod złączem J2. Nie jest to zbyt eleganckie rozwiązanie, ale nie chciało mi się poprawiać tego fragmentu PCB.

Po sprawdzeniu poprawności montażu możemy podłączyć urządzenie do portu USB (stan zworek J4 i J5 jest na razie nieistotny). Teraz należy uruchomić program FT_PROG i skonfigurować układ FT232RL. W zakładce USB_Config_Descriptor zaznaczamy opcje Bus Powered, USB Remote Wakeup i Pull Down IO Pins in USB Suspend zaś wartość Max Bus Power ustawiamy na 500mA. Nazwę urządzenia w USB_String_Descriptors ustawiamy wedle własnego widzimisię. W zakładce Hardware_Specific –> IO_Controls ustawiamy funkcje pinów IO:

Property	Value
C0	TX & RXLED#
C3	PWRON#

Następnie programujemy wprowadzone zmiany. Po zamknięciu FT_PROG-a i ponownym podłączeniu urządzenia powinniśmy zobaczyć dodatkowy port COM w systemie (lub prośbę o doinstalowanie sterowników).

Teraz ustawiamy zworkę J5 w pozycji PROG, programujemy ATmegę i wgrywamy firmware zgodnie z opisem pierwotnej wersji urządzenia (linki we wspomnianym wcześniej wpisie).

Po wgraniu firmware’u zworkę J5 ustawiamy w pozycję WORK, zaś J4 wedle potrzeby — USB PWR, jeżeli debugowany układ ma być zasilany z portu USB lub DEVICE PWR, jeżeli dysponuje on własnym zasilaniem. Teraz JTAG jest gotowy do pracy.

Możliwości zmian

Zgodnie z zaleceniem noty aplikacyjnej zastosowałem przeciwzakłóceniowy koralik ferrytowy FB1 na dodatniej linii zasilania USB. Nie jest on niezbędny — można go zastąpić jakimś dławikiem lub po prostu zworą. Jeżeli będziemy mieli wyjątkowego pecha może to jednak wiązać się z zakłóceniami pracy magistrali USB.

Podobnie bezpiecznik polimerowy F1 nie jest niezbędny, zwłaszcza, że porty USB są wyposażone we własne bezpieczniki. Taki bezpiecznik jednak kosztuje niewiele a zwiększa nieco bezpieczeństwo naszego komputera.

Mimo iż układ w całości został zaprojektowany na Linuksie, uruchomiłem go na Windowsie ze względu na aplikację FT_PROG. Za to próbowałem korzystać z JTAG-a na Linuksie, posługując się programem AVaRICE. Niestety, mimo iż program zdawał się wgrywać kod na mikrokontroler, to debugowanie kończyło się niepowodzeniem. Na razie pozostałem więc przy AVR Studio w środowisku Windows. Zresztą AVR Studio ma tę przewagę nad wszystkimi innymi rozwiązaniami, iż udostępnia świetny graficzny monitor zasobów mikrokontrolera.

Wykaz elementów

Półprzewodniki:

1 × FT232RL
1 × ATMEGA16-16AU
1 × IRLM6402 (użyłem IRLM6302)
1 × LED SMD 1206 zielona
1 × LED SMD 1206 zółta
1 × LED SMD 1206 czerwona

Kondensatory SMD 0805:

2 × 22pF

Kondensatory SMD 1206:

4 × 100nF
1 × 10nF
1 × 4,7µF
1 × 10uF

Rezystory SMD 1206:

3 × 270Ω
2 × 1kΩ
1 × 4,7kΩ
2 × 10kΩ
1 × 36kΩ (użyłem 33kΩ)
1 × 150kΩ

Elementy stykowe:

2 × jumperek
1 × gniazdo USB B kątowe do druku przewlekane
1 × gniazdo męskie proste IDC10 do druku przewlekane
1 × goldpin 2×3
2 × goldpin 1×3

Pozostałe:

1 × rezonator kwarcowy 7.3728MHz SMD (oznaczany czasem w katalogach jako 7.372MHz)
1 × LCBA-601 (koralik przeciwzakłóceniowy) — może być 1206, 0805 lub 0603
1 × bezpiecznik polimerowy 0,5A SMD 1812

Pliki

W spakowanym archiwum dostępne są schematy w formacie programu KiCad oraz w formacie PostScript.

Sage policzy to za Ciebie

vmario — Thu, 21 May 2009 18:07:57 +0000

Z pewnym żalem obserwuję czasem wśród moich kolegów z uczelni prawie że kompletny brak umiejętności posługiwania się oprogramowaniem matematycznym. Rozumiem jednak niechęć do MATLAB-a, a nawet do samej matematyki; ze wstydem przyznaję też, że sam, po blisko czterech latach na politechnice, posiadam wciąż bardzo ubogi aparat matematyczny i z trudem udaje mi się zmusić komputer do tego, do czego został stworzony, czyli do… liczenia.

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 na Linuksie i MMnet104

vmario — Wed, 06 May 2009 19:29:57 +0000

Tydzień temu pisałem o przywróceniu do życia modułu MMnet104. Dziś opiszę krótko instalację i uruchomienie środowiska, które pozwoli oprogramować ten moduł pod Linuksem z użyciem systemu operacyjnego Nut/OS.

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.

JTAG vs. fuse bity ATmegi128

vmario — Wed, 29 Apr 2009 20:38:59 +0000

W naszym projekcie grupowym na ETI korzystamy z modułu MMnet104 z mikrokontrolerem ATmega128. W wyniku bliżej nieokreślonych manipulacji procesor przestał odpowiadać na próby komunikacji po SPI za pomocą programatorów ISP.

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ł.

PS Zapraszam do zapoznania się z nowszym rozwiązaniem — tym samym JTAG-iem w wersji USB.

Rzecz o efkach

vmario — Wed, 21 Jan 2009 17:22:45 +0000

Stanąłem przed zadaniem rozdzielenia sygnału telewizyjnego na dwa telewizory. Zdawało mi się, że zakup rozgałęźnika rozwiąże cały problem. Okazało się jednak, że nie wziąłem pod uwagę jednego — w powszechnym użyciu są dwa standardy złącz: złącze F, w które był wyposażony rozgałęźnik, oraz zwykłe złącze antenowe (Belling-Lee connector, IEC 169-2 connector, TV aerial plug), w które wyposażone są odbiorniki i gniazdo z sygnałem. Byłem tą niespodzianką lekko skonfundowany, w końcu student elektroniki powinien sobie z tak podstawowych rzeczy zdawać sprawę.

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

Programator AVR USBasp na Linuksie

vmario — Wed, 22 Oct 2008 15:28:59 +0000

Z braku portu LPT w nowym komputerze zaopatrzyłem się w programator USB, żeby móc czymś męczyć AVR-y. Padło na urządzenie na bazie USBasp, konkretnie model firmy Protech Micro (można ich znaleźć także na Allegro). Zakup był trochę ryzykowny, gdyż producent nie gwarantował, że programator będzie obsługiwany pod Linuksem, choć fakt, iż układ jest wspierany przez AVRDUDE dobrze rokował. I rzeczywiście, pod rootem programator śmigał od ręki. Gorzej było z uruchomieniem go z konta zwykłego użytkownika. Drogą eksperymentów z udev udało mi się w końcu nadać odpowiednie uprawnienia i mogę spokojnie zająć się programowaniem. Oto droga do celu pod Arch Linuksem.

Instalujemy AVRDUDE:

# 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.

Nie umiem wróżyć z fusów

vmario — Thu, 31 Jan 2008 11:49:26 +0000

Próbowałem wczoraj ugryźć wreszcie dekodowanie RC5 z użyciem timera w ATtiny2313. Miałem jednak spore problemy z wyliczeniem czasów, przede wszystkim dlatego, że wcześniej pracowałem na AT90S2313, który przyzwyczaił mnie do tego, że domyślnie taktowany jest przez zewnętrzny oscylator. Z nowymi AVR-ami rzecz ma się nieco inaczej, bowiem chociażby w takim ATtiny2313 mamy do wyboru całkiem sporo wewnętrznych oscylatorów RC. Wyboru dokonuje się przez młodsze fuse bity (Fuse Low Byte). W szczególności interesują nas bity CKSEL3..0 (Select Clock source) i bit CKDIV8 (Divide clock by 8). W dokumentacji jasno stoi, iż domyślnie bity CKSEL3..0 ustawione są na 0100 tak, że pracuje wewnętrzny oscylator 8MHz. CKDIV8 jest zaś ustawiony na 0, byłem więc przekonany, że dzielnik zegara systemowego jest wyłączony.

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.