Niestety, opisując proces kompilacji Linuksa dla MMneta1002 zapomniałem o zapewnieniu dostępu do GPIO. Sterowanie pinami na potrzeby migania diodą, załączania przekaźnika czy sprawdzania stanu przełącznika jest jednak bardzo proste — wymaga tylko włączenia odpowiednich opcji w konfiguracji jądra i wykonywania operacji na plikach reprezentujących poszczególne piny. Dodatkowo mamy możliwość automatycznej obsługi LED-ów przez jądro w celu sygnalizacji np. dostępu do nośników danych.

Zaczynamy od tego, że w konfiguracji jądra zaznaczamy opcję /sys/class/gpio/… (sysfs interface) w zakładce GPIO Support (CONFIG_GPIO_SYSFS=y). Warto też włączyć LED Heartbeat Trigger i LED Timer Trigger w LED Support (CONFIG_LEDS_TRIGGER_HEARTBEAT=y i LEDS_TRIGGER_TIMER=y).

Następnie poprawiamy łatkę dla pliku arch/arm/mach-at91/board-sam9260ek.c. W pliku tym definiujemy, które piny będą dostępne dla jądra jako urządzenia LED:

/*
 * LEDs
 */
static struct gpio_led ek_leds[] = {
	{	/* "DISK" LED */
		.name			= "disk",
		.gpio			= AT91_PIN_PC1,
		.active_low		= 1,
		.default_trigger	= "nand-disk",
	},
	{	/* "USR" LED */
		.name			= "usr",
		.gpio			= AT91_PIN_PC15,
		.active_low		= 1,
		.default_trigger	= "heartbeat",
	}
};

Gotową łatkę można pobrać tutaj: linux-2.6.32.9-mmnet1002.patch.

Po rekompilacji jądra dostajemy dostęp do poszczególnych pinów w przestrzeni użytkownika. Przykład: jeżeli chcemy zaświecić diodę podłączoną do pinu PC2 (gpio98), najpierw eksportujemy ten pin:

# echo 98 > /sys/class/gpio/export

a następnie konfigurujemy go jako wyjście w stanie niskim:

# echo "low" > /sys/class/gpio/gpio98/direction

Oczywiście, jeżeli do tego pinu podłączymy przycisk, możemy sprawdzić jego stan za pomocą dwóch prostych poleceń:

# echo "in" > /sys/class/gpio/gpio98/direction
# cat /sys/class/gpio/gpio98/value

Szczegóły implementacji GPIO w Linuksie można znaleźć w dokumentacji jądra.

A teraz przyjrzyjmy się diodom podłączonym do PC1 i PC15. Pierwsza z nich (nie jest ona wlutowana w płytkę — dodałem ją samodzielnie na potrzeby własnego projektu) ma ustawiony wyzwalacz nand-disk, co można łatwo sprawdzić:

# cat /sys/class/leds/disk/trigger
none [nand-disk] timer heartbeat default-on

Oznacza to, że dioda będzie migać, gdy system będzie korzystał z pamięci NANDFlash. Dioda USR (umieszczona obok diody PWR) ma zaś wyzwalacz heartbeat, co oznacza, że imituje bicie serca, a jej „tętno” zależy od obciążenia systemu (przyśpiesza wyraźnie dopiero, gdy system jest bardzo obciążony).

Oczywiście, plik trigger możemy nadpisywać swoją wartością. Poniższe polecenia sprawią, że dioda będzie cieszyć nasze oczy krótkim błyśnięciem raz na sekundę:

# echo "timer" > /sys/class/leds/usr/trigger
# echo 100 > /sys/class/leds/usr/delay_on
# echo 900 > /sys/class/leds/usr/delay_off

Szczegóły implementacji urządzeń LED również można znaleźć w dokumentacji jądra.

Buildroot, z którego korzystam ma w paczkach jedynie Pythona w wersji 2.4. Pomyślałem, że byłoby dobrze mieć nieco świeższą wersję, więc postanowiłem zmodyfikować patche i skompilować wersję 2.6. Nie było to łatwe zadanie, ale łącząc oryginalne patche Buildroota z tym, co udało mi się wygooglować otrzymałem działające rozwiązanie.

Oto patch, który należy umieścić w katalogu package/python/: python-2.6-001-multi.patch.

Należy też wyedytować package/python/python.mk:

PYTHON_VERSION=2.6.4
PYTHON_VERSION_MAJOR=2.6

w konfiguracji Buildroota należy wybrać Pythona w Package Selection for the target -> Interpreter languages / Scripting. Jeżeli chcemy korzystać z Django należy także pamiętać, że będziemy jeszcze potrzebowali bibliotek dla programistów, czyli python -> development files on target. Należy przy okazji zaznaczyć Build options -> development files in target filesystem, niestety wyraźnie zwiększy to ilość zajętego przez system miejsca, bo Buildroot dołączy mnóstwo plików nagłówkowych. Na koniec należy wybrać jakąś bazę danych. Myślę, że w przypadku aplikacji uruchamianych na systemie wbudowanym w zupełności wystarczy SQLite: Package Selection for the target -> Database -> sqlite.

A tak wyglądają u mnie newralgiczne fragmenty pliku konfiguracyjnego:

# BR2_HAVE_MANPAGES is not set
# BR2_HAVE_INFOPAGES is not set
# BR2_HAVE_DOCUMENTATION is not set
BR2_HAVE_DEVFILES=y
BR2_UPDATE_CONFIG=y
 
BR2_PACKAGE_READLINE=y
 
BR2_PACKAGE_SQLITE=y
# BR2_PACKAGE_SQLITE_READLINE is not set
 
BR2_PACKAGE_OPENSSL=y
 
BR2_PACKAGE_NCURSES=y
# BR2_PACKAGE_NCURSES_TARGET_PANEL is not set
# BR2_PACKAGE_NCURSES_TARGET_FORM is not set
# BR2_PACKAGE_NCURSES_TARGET_MENU is not set
# BR2_PACKAGE_NEWT is not set
# BR2_PACKAGE_SLANG is not set
 
BR2_PACKAGE_PYTHON=y
BR2_PACKAGE_PYTHON_DEV=y
# BR2_PACKAGE_PYTHON_PY_ONLY is not set
BR2_PACKAGE_PYTHON_PYC_ONLY=y
# BR2_PACKAGE_PYTHON_PY_PYC is not set
 
# BR2_PACKAGE_PYTHON_BSDDB is not set
# BR2_PACKAGE_PYTHON_CODECSCJK is not set
# BR2_PACKAGE_PYTHON_CURSES is not set
# BR2_PACKAGE_PYTHON_PYEXPAT is not set
BR2_PACKAGE_PYTHON_READLINE=y
# BR2_PACKAGE_PYTHON_SSL is not set
# BR2_PACKAGE_PYTHON_TKINTER is not set
BR2_PACKAGE_PYTHON_UNICODEDATA=y

Po tych zabiegach Python powinien już działać, może jedynie wystąpić błąd podczas uruchamiania powłoki interaktywnej:

# python
Python 2.6.4 (r264:75706, Mar 18 2010, 09:24:08)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
python: can't resolve symbol 'BC'

Rozwiązaniem jest dopisanie do target_skeleton/etc/profiles:

# Dla interaktywnego Pythona:
export LD_PRELOAD=/usr/lib/libncurses.so

Jak dotąd nie napotkałem na żadne inne przeszkody. Django działa i współpracuje z SQLite, choć, rzecz jasna, demonem szybkości nie jest. Uruchomienie python manage.py runserver trwa wieki, ale gdy w końcu serwer wstanie, to działa w miarę sprawnie i zajmuje połowę RAM-u (ok. 30MB). Na razie jestem w stanie to zaakceptować, gdyż Django będzie w moim systemie główną aplikacją i nie jest problemem fakt, że pożera większość zasobów. Mam tylko nadzieję, że w połowie pracy nie zostanę zmuszony do przejścia na jakieś inne CGI.

Poniższy tutorial nie jest zbyt szczegółowy, zakładam, że Czytelnik pracuje na Linuksie i umie się nim posłużyć w podstawowym zakresie, a także, że zapoznał się z dokumentacją rzeczonej płyty ewaluacyjnej i umie posługiwać się programatorem SAM-BA.

Buildroot

Buildroot jest zestawem Makefile’i i patchy, ułatwiających budowę toolchaina z cross-kompilatorem, jądra Linux i głównego systemu plików z BusyBoksem na systemy wbudowane, na których potrzebujemy lekkiego systemu operacyjnego opartego o uClibc w miejsce GNU libc. Eksperymentowałem wprawdzie ze środowiskiem wyrosłym z Buildroota — OpenEmbedded — jest ono bardziej rozbudowane, ale dla mnie mniej wygodne. Nie udało mi się zresztą skompilować w nim działającego jądra, zdecydowałem się więc na Buildroota.

Wadą Buildroota są problemy z kompilacją tylko wybranej części systemu. W zasadzie powinniśmy zawsze kompilować wszystkie składniki, łącznie z toolchainem. Niestety, wciąż nie udało mi się wydzielić budowy systemu plików jako oddzielnego zadania; jedynie jądro z powodzeniem udawało mi się rekompilować bez budowania od nowa całości, dzięki czemu proces kompilacji trwał najwyżej kilkanaście zamiast kilkudziesięciu minut.

Po co nam dwa systemy?

Ze względu na pewne problemy w działaniu i powolne przesyłanie danych chciałem w miarę możliwości pozbyć się konieczności używania programatora SAM-BA. Poza tym SAM-BA raczej nie nadaje się do flashowania obrazów UBIFS, co wyjaśnię dalej. Zdecydowałem się zatem na następującą metodologię.

Budujemy dwa systemy: pierwszy zawiera tylko podstawowe narzędzia, nie posiada oddzielnego obrazu systemu plików, ale ma wkompilowany intramfs, dzięki czemu całość pracuje tylko w RAM-ie i może swobodnie zarządzać całym obszarem pamięci NANDFlash. Drugi to nasz właściwy system, który zawiera wszystkie narzędzia na obrazie UBIFS, a jego jądro nie posiada ani obrazu initramfs, ani initrd, dlatego może on wstać tylko z pamięci nieulotnej.

Pierwszy system będzie pobierany przez bootloader z sieci lokalnej i uruchamiany tylko po to, by wgrać ten drugi. Taka sytuacja będzie jednak miała miejsce tylko podczas rozwijania naszych projektów — podczas codziennej pracy od razu będzie uruchamiany drugi system, wstający z pamięci nieulotnej.

Budowa obu systemów

Po pobraniu i rozpakowania Buildroota uruchamiamy polecenie

$ make menuconfig

Uruchomi się konfigurator, który nas jednak w tej chwili nie interesuje — chcieliśmy tylko, by zostały utworzone dodatkowe pliki konfiguracyjne, niezbędne do dalszej pracy. Zamykamy więc program, wybierając Exit i nie zapisują zmian. Ścieżkę do Buildroota ustawiamy w zmiennej BUILDROOT w skrypcie Buildroot/build_root z mojego archiwum. Skrypt ten jest protezą, którą stworzyłem w miejsce własnej płytki, którą powinienem był dodać do środowiska Buildroota. Wygodniej mi jednak było wykorzystać pliki konfiguracyjne płytki AT91SAM9260-EK, na które skrypt nanosi pewne poprawki. Poprawki te zgromadzone są w katalogach mmnet1002 i mmnet1002-initramfs:

config

główny plik konfiguracyjny zastępujący .config Buildroota.

linux26-config

plik konfiguracyjny z wytycznymi kompilacji dla jądra.

target_skeleton

katalog z systemem plików (z wyjątkiem urządzeń w /dev).

device_table.txt

lista urządzeń, które będą dostępne w /dev.

ubifs.cfg

konfiguracja obrazu UBIFS.

dl

patche, które zostaną dodane do źródeł w katalogu dl Buildroota.

(Opracowując poprawki bazowałem między innymi na tutorialu, który opisuje, inne, być może rozsądniejsze, podejście do modyfikacji Buildroota na potrzeby MMneta).

Budowa pierwszego systemu sprowadza się do:

$ ./build_root all mmnet1002-initramfs

zaś drugiego do:

$ ./build_root all mmnet1002

Po kompilacji trwającej każdorazowo zapewne od 30 do 60 minut, powinniśmy otrzymać obrazy systemów w podkatalogach images-mmnet1002-initramfs i images-mmnet1002, które znajdą się w tym samym katalogu, w którym umieściliśmy skrypt build_root.

Za każdym razem skrypt będzie chciał usunąć podkatalog output w katalogu Buildroota — należy mu na to zezwolić po upewnieniu się, że nie usuwamy sobie np. home’a (jedna zbędna spacja w zmiennej BUILDROOT i może dojść do tragedii).

Warto też na początku zastąpić opcję all opcją source, skrypt powinien wtedy tylko pobrać niezbędne źródła, bez budowania ich. Polecam to zwłaszcza użytkownikom powolnych i niepewnych łączy.

Partycje MTD i woluminy UBIFS

Na tym etapie warto zwrócić uwagę na plik linux-2.6.32.9-mmnet1002.patch w katalogu dl. Jest to patch, który odpowiada między innymi za podział Flasha na partycje MTD. Nie są to partycje w ścisłym tego słowa znaczeniu. Urządzenia MTD, a więc surowe pamięci Flash, w przeciwieństwie do np. kart SD czy pendrive’ów nie są urządzeniami blokowymi (raczej czymś pośrednim między urządzeniem blokowym a znakowym) i nie mogą być obsługiwane przez tradycyjne systemy plików. Nie zapisujemy też na nich tablicy partycji — podział surowej pamięci Flash jest umowny i może być zapisany na stałe w jądrze lub podawany jako argument mtdparts przez bootloader. Wybrałem to pierwsze rozwiązanie, a podział zachowałem taki sam jak w fabrycznej wersji:

0x00000000-0x00040000 : "bootstrap"
0x00040000-0x00080000 : "u-boot"
0x00080000-0x00200000 : "u-boot-env"
0x00200000-0x00800000 : "kernel"
0x00800000-0x40000000 : "filesystems"

Jako system plików dla MTD wybrałem UBIFS, również tak, jak w rozwiązaniu fabrycznym, z tym, że poprzestałem na jednym woluminie UBI. Do wygenerowania obrazu UBI niezbędne są programy mkfs.ubifs i ubinize, które użytkownicy Arch Linuksa znajdą w AUR w pakiecie mtd-utils-git. Pierwszy z tych programów wymaga uprawnień roota (poza tym musimy operować na plikach urządzeń, co też wymaga uprawnień superużytkownika), dlatego też skrypt build_root pyta się o to hasło przed stworzeniem obrazu systemu plików.

Należy pamiętać, że odradza się bezpośrednie flashowanie obrazów UBI, a preferuje się wykorzystanie programu ubiformat, gdyż daje to gwarancję, że system plików poprawnie obsłuży baderaseblocki. Jest to jeden z powodów, dla których starałem się odejść od stosowania SAM-B-y.

Bootloadery

AT91Bootstrap to bootloader pierwszego stopnia, którego najważniejszym zadaniem jest wczytanie większego i znacznie bardziej funkcjonalnego U-Boota. Nie możemy wczytać od razu tego drugiego, ponieważ ROM Boot Program mikrokontrolera może udostępnić bootloaderowi pierwszego stopnia tylko 4KB wbudowanej pamięci RAM. Z tego też względu należy upewnić się, że skompilowany AT91Bootstrap ma mniej niż 4KB!

Do kompilacji obu bootloaderów niezbędny jest cross-kompilator, np. polecany przez twórców U-Boota ELDK. My jednak nie będziemy zaśmiecać sobie dysku i wykorzystamy toolchaina skompilowanego przez Buildroota. W tym celu należy ustawić odpowiednio zmienną PATH w skryptach build_at91bootstrap i build_u-boot. Przy okazji należy zmodyfikować też odpowiednio ścieżki do źródeł obu programów. Źródła z kolei trzeba przed kompilacją spatchować:

Bootstrap-v1.15-mmnet1002.patch

zawiera poprawki uwzględniające różnice między MMnetem1002 a AT91SAM9260-EK (m.in. inną pamięć nieulotną i inny pin przywracania SAM-B-y).

u-boot-2009.11.1-mmnet1002.patch

zawiera poprawki dla interfejsu sieciowego i domyślnych parametrów uruchamiania systemu.

Podobnie jak w przypadku Buildroota, skrypty możemy umieścić w zupełnie innym miejscu niż źródła. Po zbudowaniu obu aplikacji ich obrazy binarne zostaną skopiowane do katalogów, w których znajdują się odpowiednie skrypty.

SAM-BA

Mamy już wszystkie obrazy, więc możemy przystąpić do flashowania. W katalogu Flashing znajdziemy skrypt flash_now. Najpierw sprawdźmy, czy zmienna SAMBA wskazuje na plik wykonywalny SAM-B-y. Następnie skopiujmy do wspomnianego katalogu obrazy obu bootloaderów, tj. at91bootstrap.bin i u-boot.bin. Po uruchomieniu skrypt przekaże do SAM-B-y instrukcje zawarte w MMnet1002_prog.tcl i wgra do pamięci NANDFlash oba bootloadery oraz zmienne środowiskowe U-Boota. Należy przy tym zauważyć, że:

1. SAM-BA automatycznie generuje plik z ustawieniami U-Boota (u-boot-env.bin).
2. SAM-BA, a później U-Boot (dzięki u-boot-env.bin) mają rozmiar drugiego jądra ustawiony na sztywno na 2MiB (0x200000B). Wynika to z tego, iż podczas dalszej pracy nowe jądra będą wgrywane bez udziału SAM-B-y i nie będzie ona mogła aktualizować ustawień U-Boota. Wartość 2MiB dla jądra bez initrafms zawiera spory zapas (przykładowe jądro waży tylko 1,2MiB), a nie ma sensu wczytywanie 6MiB całej partycji, gdyż zauważalnie wydłuża to czas startu systemu.
3. Do U-Boota zostaje dodane polecenie upgrade, które posłuży do wgrywania nowych wersji systemu.

TFTP

Przed wgraniem systemu z sieci należy upewnić się, że mamy uruchomiony serwer DHCP i TFTP pod adresem 192.168.42.1, gdzie powinna też być brama sieciowa. U-Boot bowiem będzie szukał obrazów pod adresem bramy sieciowej, zaś skrypt /root/upgrade konkretnie pod wspomnianym IP. Jeżeli chcielibyśmy zastosować inne rozwiązanie (np. hardkodować w obu przypadkach wszystkie adresy sieciowe), należy zmodyfikować polecenie upgrade w U-Boocie i skrypt /root/upgrade w obu wersjach systemu.

W katalogu serwera TFTP na naszym PC-cie (np. /var/tftpboot) należy umieścić te pliki, które będziemy chcieli zaktualizować w systemie. Na początek wgramy wszystko na nowo, skopiujmy więc:

• z katalogu Flashing lub katalogów odpowiednich bootloaderów: at91bootstrap.bin, u-boot.bin, u-boot-env.bin,
• z katalogu images-mmnet1002: uImage i rootfs.ubi,
• z katalogu images-mmnet1002-initramfs: uImage, którego nazwy nie zapomnijmy zmienić na uImage-initramfs!

Teraz uruchamiamy MMneta. Po chwili U-Boot poskarży się nam, że nie znalazł jądra, jednak nie zważając na to wpiszmy w jego wierszu poleceń:

U-Boot> run upgrade

Teraz U-Boot uzyska niezbędne adresy IP z DHCP, pobierze pierwszą wersję systemu (uImage-initramfs), która natychmiast po wystartowaniu uruchomi skrypt /root/upgrade, pobierający i instalujący właściwą, drugą wersję systemu. Po chwili płyta zrestartuje się, a z NANDFlasha powinien wstać nowy system, który po wygenerowaniu kluczy dla Dropbeara będzie gotowy do pracy.

Teraz, gdy mamy system na NANDFlashu, jądro możemy aktualizować za pomocą polecenia:

# /root/upgrade

Nie da się jednak w ten sposób zaktualizować głównego systemu plików — należy zrestartować płytę i wywołać polecenie upgrade w U-Boocie.

Uwagi końcowe

Jak wspomniałem, powyższe rozwiązanie to raczej partyzantka. Warto byłoby wszystko dodać do Buildroota jako oddzielną płytkę. Także oba bootloadery mógłby budować Buildroot, jednak miał u mnie z tym pewne kłopoty, więc uznałem, że wygodniej będzie to robić ręcznie.

Co do SAM-B-y, to na Arch Linuksie nie chciała działać, dlatego zmuszony jestem ją uruchamiać na Xubuntu w wirtualnej maszynie.

W załączonym archiwum znajdziecie skrypty, patche, gotowe obrazy i logi z SAM-B-y oraz startu obu wersji systemu, które mogą pomóc w wyśledzeniu błędów.

Pliki

mmnet1002-buildroot-vmario.tar.bz2

archiwum z opisywanymi skryptami i dodatkami.

Sam jestem amatorem, który nieraz miał ochotę wpisać set enforce 0, by przełączyć SELinuksa w tryb pobłażliwy, albo w ogóle się tego wynalazku pozbyć. Wychodzę jednak z założenia, że SELinux służy jednak czemuś pożytecznemu i lepiej spróbować z nim po dobroci. Na szczęście na ogół wystarczy odnaleźć w /var/log/messages komunikat z kodem dla programu sealert, który podaje gotowe rozwiązania, np. jaką opcję należy przełączyć za pomocą setsebool.

Są jednak przypadki, gdy porady sealert są zbyt enigmatyczne. W takich wypadkach FAQ Fedory radzi skorzystać z programu audit2allow. Zasada jest bardzo prosta. Najpierw generujemy zestaw regułek, które pozwalają obejść ostatnio napotkane błędy:

# audit2allow -m local -l -i /var/log/messages > local.te

Jeżeli nasz system korzysta z pliku /var/log/audit/audit.log to w nim program znajdzie potrzebne mu informacje:

# audit2allow -m local -l -i /var/log/audit/audit.log > local.te

Teraz możemy przejrzeć local.te i usunąć regułki, które nas nie interesują, by nie odblokować w systemie zbyt wielu zabezpieczeń.

Następnie upewniamy się, że mamy zainstalowany pakiet checkpolicy i kompilujemy moduł z naszymi regułkami, po czym generujemy paczkę:

# checkmodule -M -m -o local.mod local.te
# semodule_package -o local.pp -m local.mod

Na koniec dodajemy ją do obowiązującej w systemie polityki bezpieczeństwa (może to chwilę potrwać):

# semodule -i local.pp

Należy przy tym pamiętać, że jeżeli w pamięci jest już moduł o nazwie local, to zostanie nadpisany przez swoją nową wersję!

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?

]]> http://blog.vmario.org/2010/03/10/edytor-heksadecymalny-na-linuksa/feed/ 3 http://blog.vmario.org/2010/03/05/minicom-jako-terminal-szeregowy/ http://blog.vmario.org/2010/03/05/minicom-jako-terminal-szeregowy/#comments Fri, 05 Mar 2010 21:21:24 +0000 vmario http://blog.vmario.org/?p=686 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!

]]> http://blog.vmario.org/2010/03/05/minicom-jako-terminal-szeregowy/feed/ 1 http://blog.vmario.org/2010/03/04/przywracanie-sam-b-y-w-mmnecie1002/ http://blog.vmario.org/2010/03/04/przywracanie-sam-b-y-w-mmnecie1002/#comments Thu, 04 Mar 2010 15:04:48 +0000 vmario http://blog.vmario.org/?p=671 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.

]]> http://blog.vmario.org/2010/03/04/przywracanie-sam-b-y-w-mmnecie1002/feed/ 1 http://blog.vmario.org/2010/01/20/jtag-do-atmegi-w-wersji-usb/ http://blog.vmario.org/2010/01/20/jtag-do-atmegi-w-wersji-usb/#comments Wed, 20 Jan 2010 18:25:52 +0000 vmario http://blog.vmario.org/?p=635 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.

]]> http://blog.vmario.org/2010/01/20/jtag-do-atmegi-w-wersji-usb/feed/ 0 http://blog.vmario.org/2009/09/24/instalacja-awstats-na-debianie-z-apachem/ http://blog.vmario.org/2009/09/24/instalacja-awstats-na-debianie-z-apachem/#comments Thu, 24 Sep 2009 17:40:24 +0000 vmario http://blog.vmario.org/?p=600 AWStats to narzędzie do analizy logów serwera WWW (a także FTP i e-mail, ale to mnie akurat nie interesowało), udostępniające bogate statystyki w całkiem przejrzystej, graficznej formie. Korzystam z Debiana w gałęzi stabilnej, który udostępnia AWStats w swoim repozytorium, liczyłem zatem, że wystarczy zainstalować paczkę i wszystko pójdzie z górki. Okazało się, że instalacja z paczki i tak kończy się ręczną konfiguracją, i to włącznie z wprowadzaniem poprawek w automatycznym (?) konfiguratorze. Dlatego w końcu postanowiłem wszystko zrobić sam. Cały proces jest trochę skomplikowany, ale warto spróbować.

Instalacja

Zaczynamy od pobrania AWStats. Rozpakowane archiwum umieszczamy w katalogu /usr/local/awstats. U mnie uprawnienia po rozpakowaniu były cokolwiek śmieszne (dziwne UID-y i GID-y), więc szybko wykonałem:

# chown root:root -R /usr/local/awstats

Dostępny jest automatyczny konfigurator awstats_configure.pl, jednak nauczony doświadczeniem, proponuję wykonać zadanie za niego.

Najważniejsze jest dodanie wpisów do konfiguracji Apache, by ten mógł serwować wyniki. Tworzymy plik /etc/apache2/awstats.conf:

Alias /awstatsclasses "/usr/local/awstats/wwwroot/classes/"
Alias /awstatscss "/usr/local/awstats/wwwroot/css/"
Alias /awstatsicons "/usr/local/awstats/wwwroot/icon/"
ScriptAlias /awstats/ "/usr/local/awstats/wwwroot/cgi-bin/"

<Directory "/usr/local/awstats/wwwroot">
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>

Plik ten dołączamy do konfiguracji serwera, dopisują w /etc/apache2/apache2.conf:

Include /etc/apache2/awstats.conf

Konfiguracja hostów

Teraz przystępujemy do konfiguracji ustawień poszczególnych witryn. Tworzymy katalog /etc/awstats i umieszczamy tam szablon:

# cp /usr/local/awstats/wwwroot/cgi-bin/awstats.model.conf /etc/awstats/awstats.conf
# chmod u+w /etc/awstats/awstats.conf

Plik /etc/awstats/awstats.conf posłuży nam za szablon dla konfiguracji poszczególnych wirtualnych serwerów. Najważniejsze, by poniższe opcje miały odpowiednią wartość:

LogFile="/var/log/apache2/access.log"
LogType=W
LogFormat=1
DirIcons="/awstatsicons"

Teraz kopiujemy konfigurację dla naszego hosta. Przyjmijmy, że strona dostępna jest w domenie example.org i example.com.

# cp /etc/awstats/awstats.conf /etc/awstats/awstats.example.org.conf

W awstats.example.org.conf ustawiamy:

SiteDomain="example.org"
HostAliases="example.com"

Na koniec odświeżamy konfigurację:

# /etc/init.d/apache2 restart
# /usr/local/awstats/wwwroot/cgi-bin/awstats.pl -config=example.com -update

Wyniki odwiedzin powinny być widoczne pod adresem example.org/awstats/awstats.pl. Oczywiście, wyświetlenie statystyk jest liczone jak każde inne wejście na stronę, dlatego warto dopisać w konfiguracji AWStats:

SkipFiles="REGEX[^\/awstats]"

Kłopoty ze wspólnym logiem

Jeżeli wszystkie wirtualne hosty logują do tego samego pliku, możliwe, że AWStats nie będzie potrafił przyporządkować ruchu do odpowiednich domen. W takim przypadku należy sprawdzić, jaki format logu stosują poszczególne hosty. U mnie było to:

CustomLog /var/log/apache2/access.log combined

W konfiguracji Apache'a (/etc/apache2/apache2.conf) należy zatem znaleźć opis tego formatu:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

i zamienić na:

LogFormat "%V %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

Teraz trzeba jeszcze zrestartować serwer i wyczyścić log /var/log/apache2/access.log (usunięcie tego pliku może skutkować wyłączeniem logowania). Jeżeli nie wyczyścimy logu, AWStats nie będzie chciał go czytać, bo nie będzie zgadzał mu się format.

W konfiguracjach hostów AWStats należy zmienić opcję LogFormat:

LogFormat="%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"

Przy okazji warto zauważyć, że pustą opcję HostAliases AWStats dopełnia m.in. wartościami localhost 127.0.0.1. Podejrzewam, że to również może fałszować wyniki, warto zatem, mając pustą opcję HostAliases, skopiować tam wartość SiteDomain.

Teraz można odświeżyć dane w AWStats. Jeżeli chcemy usunąć stare, błędne dane, wystarczy usunąć odpowiedni plik *.txt w /usr/local/awstats/wwwroot/cgi-bin/.

Automatyczne odświeżanie statystyk

Aby statystyki aktualizowały się automatycznie co np. 15 minut, dodajemy zadanie do crona:

*/15 * * * * /usr/local/awstats/wwwroot/cgi-bin/awstats.pl -config=example.org -update >/dev/null

Ponieważ podczas rotacji logów, możemy zgubić część danych, trzeba wcześniej wywoływać aktualizację. W tym celu edytujemy /etc/logrotate.d/apache2, dopisując odpowiednią opcję (tu wyróżnioną pogrubieniem):

/var/log/apache2/*.log {
        weekly
        missingok
        rotate 52
        compress
        delaycompress
        notifempty
        create 640 root adm
        sharedscripts
        prerotate
                /usr/local/awstats/wwwroot/cgi-bin/awstats.pl -update -config=example.org
        endscript
        postrotate
                if [ -f "`. /etc/apache2/envvars ; echo ${APACHE_PID_FILE:-/var/run/apache2.pid}`" ]; then
                        /etc/init.d/apache2 reload > /dev/null
                fi
        endscript
}

By żyło się lepiej

W celu uproszczenia dostępu do statystyk, możemy dodać przekierowanie, dopisując w pliku /etc/apache2/awstats.conf np.:

RedirectMatch ^/statystyki[/]?$ /awstats/awstats.pl

Z kolei w celu utrudnienia dostępu osobom niepowołanym (statystyki zawiera pokaźną ilość informacji), możemy zabezpieczyć AWStats hasłem. Najpierw tworzymy plik z loginem i hasłem:

# htpasswd -c /usr/local/awstats/wwwroot/cgi-bin/.htpasswd nasz_login

Następnie edytujemy fragment /etc/apache2/awstats.conf:

<Directory "/usr/local/awstats/wwwroot">
Options None
AllowOverride None
Order allow,deny
Allow from all
AuthName "Prosze o login i haslo :P"
AuthType Basic
AuthUserFile /usr/local/awstats/wwwroot/cgi-bin/.htpasswd
require valid-user
</Directory>

Teraz pod adresem example.org/statystyki będziemy mogli obejrzeć logi, ale dopiero po podaniu hasła.

Nierozwiązane problemy

Tak naprawdę brakuje mi w AWStats jednej funkcji. Chciałbym mieć możliwość ustawienia opcji HostAliases na wartość w stylu example.net/org/, bowiem zdarza mi się, że podkatalog jednego z wirtualnych hostów, staje się później oddzielnym wirtualnym hostem i chciałbym śledzić wszystkie odwiedziny w jednym miejscu.

]]> http://blog.vmario.org/2009/09/24/instalacja-awstats-na-debianie-z-apachem/feed/ 1 http://blog.vmario.org/2009/08/19/languagetool-dla-writera/ http://blog.vmario.org/2009/08/19/languagetool-dla-writera/#comments Wed, 19 Aug 2009 14:00:54 +0000 vmario http://blog.vmario.org/?p=590 W ramach wakacyjnego sezonu ogórkowego chcę przedstawić narzędzie, które sprawia, że mimo zafascynowania LaTeX-em, wciąż chętnie sięgam po Writera z pakietu OpenOffice.org. Narzędziem tym jest LanguageTool. Zapewne nie wszyscy wiedzą, że poza kontrolowaniem ortografii, Writer może też sprawdzać reguły gramatyczne i wyłapywać błędy językowe.

Aby cieszyć się dodatkową funkcjonalnością wystarczy tylko ściągnąć stosowne rozszerzenie i otworzyć plik za pomocą Writera lub wskazać go w Menedżerze rozszerzeń. Ponieważ LanguageTool wymaga Javy, musimy mieć ją zainstalowaną. Jeżeli podczas dodawania rozszerzenia straszy nas wielki komunikat z błędem Javy, prawdopodobnie brakuje jej obsługi w OOo. Problem ten występuje np. w standardowej instalacji Ubuntu, a jego rozwiązanie wymaga doinstalowania pakietu openoffice.org-java-common.

Po dodaniu, LanguageTool podkreśla wykryte błędy niebieskim wężykiem, a podczas ręcznego sprawdzania pisowni, podaje odpowiednie wyjaśnienia (po wskazaniu kursorem przycisku Wytłumacz) i sugestie poprawienia. Wyłapywane są m.in. błędy fonetyczne, frazeologiczne, interpunkcyjne i składniowe. LanguageTool zdaje się być czasem nieco nadgorliwy, np. jeżeli chodzi o wskazywanie nadużywanych słów, ale jego walory praktyczne i edukacyjne są niezaprzeczalne.

]]> http://blog.vmario.org/2009/08/19/languagetool-dla-writera/feed/ 1