piątek, 23 listopada 2012

Zakończenie rozwoju programów z sekcji "Po godzinach"

Od jakiegoś czasu nie rozwijałem już Kolejnego Programu do Blogowania ani Odbiornika GPS. Podeszły wiek obu projektów, jak i porzucenie przeze mnie jakichkolwiek prac nad nimi, przyczyniły się do podjęcia decyzji o usunięciu repozytoriów z GitHuba. Egzekucja ułatwiona tym bardziej, że byłem jedynym programistą pracującym nad kodem tych aplikacji i nie było żadnych forków :)
Jak już napisałem na podstronie "Po godzinach", serdecznie dziękuję każdemu użytkownikowi, który poświęcił czas na przetestowanie tych programów.
Być może kiedyś wrócę do tych aplikacji - na dzień dzisiejszy raczej nie. Ale "nigdy nie mów nigdy", jak zwykł to podsumowywać James Bond.

środa, 21 listopada 2012

RaspberryPi: wspólna klawiatura, wspólna mysz i ewentualnie wspólny monitor, czyli jak zachować spokój...

Zapewne wielu z Was używa na co dzień świetnego programu Synergy (http://synergy-foss.org/). Bo też wielu z Was spotkało się z sytuacją, kiedy to trzeba było w tym samym czasie (szachista powiedziałby: symultanicznie) obsługiwać dwa lub więcej komputerów. W moim przypadku, na szczęście, liczba fizycznych (znajdujących się w tym samym pomieszczeniu, a nawet na tym samym biurku) komputerów obsługiwanych równolegle nie przekroczyła dwóch - stacjonarny i laptop.
Żeby usprawnić sobie pracę najlepiej jest, przełączając się między komputerami, nie odrywać rąk od klawiatury i myszy - można ewentualnie spojrzeć na drugi monitor (do czego zresztą coraz częściej przychodzi nam się przyzwyczajać). Rozwiązań jest wiele - choćby różne wynalazki typu VNC, tyle, że zdalne pulpity, jak sama nazwa wskazuje, najlepiej sprawdzają się w pracy zdalnej (sieć o większym zasięgu, niż klasyczny LAN). Synergy zaś, mimo, że również wykorzystuje łącze sieciowe, służy po prostu do umożliwienia korzystania z jednej myszy i jednej klawiatury na kilku komputerach, najlepiej stojących na tym samym biurku. Moim zdaniem rozwiązanie jest rewelacyjne.
Na stronie Synergy (link podany wcześniej) znajdziemy dokładne informacje o tym programie, tutaj zaś opiszę krótko, jak użyć tego softu na RaspberryPi i komputerze stacjonarnym.
Zaczynamy od instalacji Synergy na komputerze stacjonarnym i na RaspberryPi - jeżeli stacjonarny działa pod kontrolą debianopodobnego linuksa, polecenie instalacji jest takie samo:

sudo apt-get install synergy

Polecenie to zainstaluje podstawowy pakiet oprogramowania - na RPi będzie to już wszystko, natomiast komputer stacjonarny warto wyposażyć jeszcze w GUI dla Synergy, czyli doinstalować quicksynergy (w analogiczny sposób, jak paczkę podstawową).
Zakładam oczywiście, że ponieważ nie mamy klawiatury i myszy podłączonej do RPi, obsługujemy "malinę" przez ssh.
Zaczynamy od komputera stacjonarnego - uruchamiamy quicksynergy i konfigurujemy serwer, czyli komputer udostępniający mysz i klawiaturę:


W okienku programu widzimy cztery pola, w które możemy wpisać nazwy (adresy) komputerów znajdujących się w naszej sieci (widocznych dla naszego komputera stacjonarnego). Umieszczenie adresu komputera po lewej stronie (u mnie laptop Rhaenys - nazwa zdefiniowana w pliku /etc/hosts) powoduje, że po ustanowieniu przez niego połączenia z naszym komputerem (serwerem) będziemy mogli "przełączyć się" na pulpit klienta (Rhaenys) przesuwając kursor myszy maksymalnie na lewą krawędź ekranu serwera (kto zgadnie, w jaki sposób "wracamy" do głównego komputera?). Analogicznie wygląda to z pozostałymi trzema polami. Po prawej stronie znajduje się nasz RaspberryPi (nazwa również zdefiniowana w /etc/hosts). Klikamy Execute i przechodzimy do konfiguracji Synergy po stronie "maliny". W oknie konsoli wydajemy polecenie startx - zobaczymy kilka komunikatów x-serwera i... no właśnie, musimy teraz spojrzeć na monitor podłączony do RPi (u mnie - przełączyć na panelu monitora źródło sygnału ;)). Widzimy pięknie uruchomiony i kompletnie bezużyteczny GUI RPi :) Jeżeli uzyskaliśmy taki efekt, to znaczy, że możemy teraz uruchomić klienta Synergy - najlepiej razem z pulpitem RPi, żeby od razu móc rozpocząć pracę. Z poziomu konsoli "ubijamy" x-server, przechodzimy do katalogu /etc/X11/xinit, otwieramy w dowolnym edytorze tekstowym plik xinitrc i gdzieś na początku pliku, np. zaraz w drugiej linii (pierwsza - wiadomo #!/bin/sh :)) lub pod komentarzem informującym o przeznaczeniu tego pliku, umieszczamy polecenie:

synergy 192.168.1.1

Adres IP to oczywiście adres serwera udostępniającego zasoby - w naszym przypadku komputera stacjonarnego.
Zapisujemy plik i jeszcze raz (ciągle z poziomu konsoli ssh) uruchamiamy GUI. Jeśli nic dziwnego po drodze się nie wydarzyło, możemy się cieszyć współdzieleniem naszych podstawowych urządzeń wejścia-wyjścia i pracować w GUI RPi bez konieczności przełączania klawiatury i myszy lub konieczności posiadania drugiego zestawu urządzeń.

Dlaczego piszę o Synergy, skoro dotyczy tylko środowiska graficznego?
Do zwykłej pracy w shellu wystarczy oczywiście połączyć się z RPi za pomocą ssh. Zdarzają się jednak sytuacje, w których koniecznie musimy przejść w tryb GUI na "malinie" - choćby np. w celu przetestowania oprogramowania (naszego czy też właśnie zainstalowanego). W tych sytuacjach Synergy jest praktycznie niezastąpiony (chyba, że wolimy jakieś oprogramowanie alternatywne).

poniedziałek, 19 listopada 2012

Programowanie AVR cz. 4,5: Poprawki związane z drobnym przeoczeniem.

Parę dni temu, tuż po publikacji poprzedniego wpisu (na temat zegara PCF8583P) zorientowałem się - przypadkowo, jak to zwykle bywa, ale też na skutek poczynionych obserwacji - że użyłem w układzie prototypowym egzemplarza mikrokontrolera z fusebitami ustawionymi domyślnie. Głównie chodzi tu o bity dotyczące częstotliwości taktowania i używanego generatora. Zaglądając w okienko pokazujące stan fusebitów zauważyłem, że mikrokontroler używa ciągle wewnętrznego generatora 8MHz z podziałem częstotliwości przez 8, czyli jest taktowany przebiegiem o częstotliwości efektywnej 1MHz. Do sprawdzenia stanu fusebitów skłonił mnie pomiar czasu pomiędzy kolejnymi przerwaniami timera nr 1 - skonfigurowałem go w pisanym właśnie programie jako timer, który powinien generować przerwanie co 1 sekundę. Jednak sekunda ta trwała nieco dłużej...

Na obrazku poniżej pokazane zostały prawidłowe wartości fusebitów dla układu taktowanego sygnałem z generatora stabilizowanego zewnętrznym kwarcem 4MHz, czyli takim, pod kątem którego pisałem program z poprzedniego posta.


Oczywiście ustawienia fusebitów są ściśle związane z konfiguracją, założeniami i potrzebami naszego projektu, należy jednak pamiętać o ich wstępnej konfiguracji po wyjęciu nowego procka z szuflady...

W związku ze zmianami w ustawieniach bitów, należy poeksperymentować z linią konfigurującą częstotliwość występowania przerwania timera nr 0 w programie z poprzedniego wpisu - może się okazać, że założona domyślnie częstość odczytów stanu zegara przez I2C jest zbyt duża (niestety, rozmontowałem już układ prototypowy, więc nie za szybko sam to zweryfikuję):

Config Timer0 = Timer , Prescale = 1024

Opis, w miarę dokładny, konfiguracji fusebitów pod kątem wykorzystywanego sposobu taktowania znajdziemy m. in. tutaj: Fuse Bity w mikrokontrolerach AVR. W ogóle strona ta jest godna polecenia jako ciekawe źródło informacji na temat mikrokontrolerów.

piątek, 16 listopada 2012

Programowanie AVR cz. 4: ATtiny2313 + PCF8583P + AT24C04 + I2C,czyli... zabrakło pamięci, ale jest zegar nastawiany "w locie".

Kontynuując zabawę z magistralą I2C (patrz: poprzedni artykuł o programowaniu AVR) i grzebanie w elektronicznym złomie, natknąłem się na niepozorny układ scalony PCF8583P, zamontowany wraz z - jak się domyśliłem - odpowiednim oscylatorem kwarcowym na prehistorycznej płytce uruchomieniowej, jeszcze chyba z czasów AT89C4051. Układ ten to zegar czasu rzeczywistego (RTC) wraz z kalendarzem i obsługa alarmów, zarządzany (programowanie, odczyt) poprzez magistralę I2C. Nie zastanawiając się długo postanowiłem dołączyć ten układ do systemu z poprzedniego wpisu, żeby stworzyć wypasiony zegar, kalendarz, budzik... Niestety, szybko okazało się, że mój ulubiony mikrokontroler ATtiny2313 ma zbyt mało pamięci FLASH, żeby pomieścić finezyjny kod, który zaczął mi wychodzić (żaliłem się już w moim streamie Google+). Dlatego też ograniczyłem program demonstracyjny do samego zegara - jedyny ficzer, jaki się pojawił, to nastawianie godziny i minuty "w locie" za pomocą dwóch przycisków. Oznacza to, że każda zmiana godziny czy minuty (zmiana w górę, czyli inkrementacja) powoduje natychmiastową aktualizację ustawień zegara PCF8583P. Oczywiście aktualny czas jest wyświetlany na jednowierszowym LCD.
Początkowo program działał dziwnie, udało mi się jednak - częściowo w oparciu o analizę, częściowo metodą doświadczalną - zapanować nad tą niestabilnością i teraz wszystko jest OK. Zachęcam do przejrzenia kodu źródłowego, mimo, że nie zawiera jakichś specjalnych wodotrysków, ech...


Całość uruchamiana była w układzie zawierającym na magistrali I2C również wspomnianą pamięć EEPROM, a ponieważ PCF8583 jest poniekąd modyfikacją pamięci z dołożoną ekstra funkcjonalnością (posiada np. taką samą jak AT24C04, zaszytą "preambułę" adresu), musiałem ustalić na nowo adresy sprzętowe slave'ów. Być może powodem niestabilnego działania układu (w pewnych warunkach) było zachwianie parametrów elektrycznych magistrali, nie pozwalające na poprawną transmisję danych? Nie wgłębiałem się, więc jest to sprawa do zbadania.
Poniżej schemat całego układu demonstracyjnego. Niestety, nie udało się zaprogramować i wykorzystać wszystkich jego możliwości - chyba pora przerzucić się na którąś z ATmeg...

Na koniec krótka konkluzja. Chcąc zbudować zegarek na ATtiny2313 nie musimy angażować do tego celu specjalizowanych układów, których programowa obsługa zaśmieci niepotrzebnie cenną pamięć mikrokontrolera - mamy przecież w naszym procesorku timer, który może generować przerwanie co jedną sekundę... ;-) Jednak zaletą zastosowania oddzielnego układu jest to, że zapewniając mu zasilanie (podtrzymanie) bateryjne, możemy mieć ciągły pomiar czasu nawet po wyłączeniu zasilania systemu mikroprocesorowego. Rozwiązanie takie zastosował kolega dołączając do RaspberryPi moduł zegara bazujący na bliźniaczym układzie PCF8563P - opis znajdziemy na jego blogu.

ERRATA:

Proszę koniecznie zajrzeć do wpisu: Programowanie AVR cz. 4,5: Poprawki związane z drobnym przeoczeniem.