wtorek, 4 grudnia 2012

Programowanie AVR cz. 6: Czy ATmega z ATtiny mogą się jakoś dogadać?

Mogą. I to na wiele sposobów. Doświadczeni elektronicy od razu wskażą kilka - od prostego połączenia port-w-port począwszy.
Jednym z elementów wyposażenia mikrokontrolerów AVR, a dokładniej moich dwóch modeli ATtiny2313 i ATmega48P, jest zrealizowany sprzętowo port UART, zgodny logicznie z RS232 (jeśli chodzi o całkowitą zgodność, konieczne jest użycie układu dopasowującego napięcia - można użyć tranzystorów lub MAX232). Obsługa tego portu w BASCOMie jest banalnie prosta. Posłużmy się przykładem. Niech ATmega będzie nadajnikiem, który wysyła przez łącze szeregowe, w odstępach co ok. pół sekundy, kolejne duże litery alfabetu łacińskiego (a przy okazji każdy wysłany znak sygnalizuje zapalająca się na chwilę dioda - schematu i konstrukcji układu z poprzedniego posta nie zmieniałem); wysyłanie liter uruchamiane jest przyciskiem. ATtiny zaś, wyposażony w wyświetlacz LCD, będzie odbiornikiem, który podczas oczekiwania na znak wyświetla napis "Ready...", po odbiorze znaku wyświetla jego kod ASCII i sam znak, a na koniec transmisji, po odebraniu kodu "znaku" Escape, pokazuje przez chwilę napis "End!".
Do wysyłania znaków (pojedynczych, seryjnie) przez port szeregowy służy funkcja Print lub Printbin, do odbierania - Inkey lub Waitkey (ta druga wstrzymuje program do nadejścia nowego znaku - nie polecam). Portów sprzętowych w układach, które tutaj wykorzystałem, nie trzeba konfigurować.
Programy odbiornika i nadajnika możemy sobie przejrzeć na poniższym listingu:

Pamiętajmy o poprawnym połączeniu naszych dwóch układów mikroprocesorowych, szczególnie, gdy każdy korzysta ze swojego źródła zasilania. Musimy połączyć masy obu układów oraz - na krzyż - linie TxD i RxD (w poprzednim wpisie linkowałem karty katalogowe - tam znajdziemy opis wyprowadzeń obu mikrokontrolerów). Kolejna ważna sprawa to parametry transmisji - w zasadzie konfigurowalna jest tylko prędkość; w obu układach powinna być koniecznie ustawiona taka sama wartość. Zmiany wartości możemy dokonać na poziomie środowiska (w odpowiednim okienku - przy okazji dowiemy się, jaka będzie najodpowiedniejsza dla naszego kwarcu/częstotliwości taktowania) lub wpisać w kodzie programu.

Istnieje również możliwość zdefiniowania programowego portu szeregowego - BASCOM dostarcza w tym przypadku bardzo wygodnych narzędzi. Jak zwykle zresztą :)

sobota, 1 grudnia 2012

Kolejny Program do Blogowania - można pobierać ostatnią wersję.

Kilka dni po zamknięciu projektów i usunięciu plików z GitHuba (pisałem o tym na blogu) dotarły do mnie informacje, że ktoś chciałby jeszcze użyć mojego Kolejnego Programu do Blogowania. Biorąc pod uwagę to zainteresowanie udostępniłem do pobrania ostatnią wersję programu - proszę kliknąć TUTAJ :)
Należy jednak pamiętać, że jest to wersja w bardzo mocno początkowym stadium rozwoju, jej uruchomienie wymaga kilku zabiegów (opis w pliku README). I nie została nigdy przetestowana pod Windows, co istotne.


Programowanie AVR cz. 5: ATmega przybyła...

W tym artykule nie będzie nic nowego ani odkrywczego jeżeli chodzi o software - prezentowane programy są banalnie proste. Chodzi raczej o zastąpienie - przynajmniej na chwilę - mojego ulubionego procesorka ATtiny2313 nową ATmegą 48P. Zamówiłem kilka egzemplarzy tego bardziej zaawansowanego mikrokontrolera głównie dla wypróbowania jego możliwości i ficzerów. Na początku więc zmontowałem prosty układ z trzema diodami LED, napisałem programik, który miał powodować ich miganie, następnie zaś wyposażyłem procesor w oscylator kwarcowy 4MHz z kondensatorami blokującymi i odpowiednio ustawiłem fusebity. 4MHz - częstotliwość dużo niższa, niż ta, którą się ATmegom zadaje, ale chodziło mi o zachowanie kompatybilności w kontekście uzależnień czasowych (częstość przerwań timerów itp.) z układami projektowanymi na ATtiny. Inna rzecz, że tylko takie oscylatory mam w swoich śmieciach...
A propos śmieci - wygrzebałem w nich również dwie sztuki drivera mocy ULN2803 (uwaga: linki do kart katalogowych opisywanych tu układów na końcu artykułu; oprócz ULN2803 - tutaj proszę się posłużyć wyszukiwarką), idealnie nadającego się do moich, zasilanych najczęściej z USB lub z baterii 3*1.5V, prototypowych i eksperymentalnych projektów. Postanowiłem więc, że wykorzystam ten driver do zapalania diod LED - wiadomo, że sam procesor da radę wysterować diody świecące, ale zwykle stosuje się do tego układy tranzystorowe (wyjścia mikrokontrolera mogą po prostu nie wydolić prądowo). Zastąpienie ich driverem mocy może w wielu przypadkach zdecydowanie uprościć układ.
Po kolei więc.

1. Programowanie ATmegi 48P

Niestety, avrdude nawet w najnowszej wersji nie obsługuje tego mikrokontrolera - jedynie podstawową ATmega48. Owszem, BASCOM nie ma z tym problemów, ale jak przeczytacie w dalszej części tego tekstu, chciałem też trochę pobawić się w Linuksie. Obejściem problemu w avrdude jest wymuszenie współpracy z mikrokontrolerem bez sprawdzania sygnatury. Jeśli używacie np. gnome-avrdude, można go skonfigurować jak pokazano na obrazku:


Jeśli chcemy do taktowania wykorzystać zewnętrzny oscylator ("kwarc"), powinniśmy odpowiednio ustawić fusebity. Najprościej (intuicyjnie bez mała) robi się to z poziomu BASCOMA - na obrazku moja propozycja, jednak polecam gorąco lekturę karty katalogowej ATmegi w celu dostosowania ustawień do potrzeb konkretnego projektu.


Z karty katalogowej dowiemy się również, jak podłączyć do układu programator - używam oczywiście USBASP (jak widać na obrazku powyżej).

2. Schemat układu 

Jak wspominałem na początku - nic wielkiego (oprócz ATmegi ;)). Chodzi tylko o pokazanie, jak można użyć układu ULN2803 z mikrokontrolerem. Sposób podłączenia wykoncypowałem w oparciu o kartę katalogową i propozycje dostępne na forach. Pamiętać należy - w dużym skrócie i uproszczeniu - że wysterowanie jedynką logiczną wejścia drivera powoduje wystawienie na wyjściu zera; w przeciwnym wypadku diody pozostają odłączone.


Na schemacie nie uwzględniłem podłączenia programatora, ale ponieważ odpowiednie końcówki są szczegółowo opisane, nie powinno być z tym problemu. Jeśli zasilacie układ z USB (przez programator) - pamiętajcie o biegunach :)

3. Program

W BASCOMie, w którym mam większe doświadczenie, program zastosowany do wypróbowania układu napisałem w sposób bardziej finezyjny - diody zapalane są i gaszone kolejno co sekundę, czas zaś odmierzany jest przez 16-bitowy Timer 1 (dzięki zastosowanemu kwarcowi można przyjąć, że przy preskalerze o wartości 64 przerwanie generowane jest co 1,048 sekundy).


Drugi program napisałem na próbę w C. Jest on typowo "szkolny", na opóźnieniach czasowych. Bardziej jednak chodziło mi o wypróbowanie dodatku do używanego przeze mnie w Linuksie środowiska Eclipse (The AVR Eclipse Plugin), umożliwiającego wygodne pisanie oprogramowania dla mikrokontrolerów AVR.
Listing programu:


I zrzut ekranu pokazujący piękno najlepszego linuksowego środowiska do programowania mikrokontrolerów AVR:



Co prawda jeszcze nie grzebałem w konfiguracji, więc chwilowo nie wiem, gdzie wpisać dodatkową opcję do wiersza polecenia uruchamiającego z poziomu Eclipse programator avrdude, ale zawsze można ładować wsad do procesora za pomocą wspomnianego przeze mnie gnome-avrdude.
I jeszcze jedna uwaga: w mojej konfiguracji systemu avrdude wymaga uprawnień roota, co można obejść nadając plikowi urządzenia, utworzonemu dla naszego programatora, prawa do zapisu dla wszystkich. Nie jest to aż taki problem, żeby go specjalnie punktować, jednak warto o tym pamiętać.

4. Podsumowanie

Działa. Mogę teraz co poważniejsze projekty realizować na bogatszym mikrokontrolerze. Ktoś mnie ostatnio zapytał, dlaczego właśnie ATmega48P? Po pierwsze, pisząc programy w BASCOMie, który mam w wersji demo, nie ma możliwości uzyskania kodu wynikowego większego niż 4kB. A literka P (PicoPower) - bo te ATmegi były akurat w promocji ;)

I jeszcze linki do kart katalogowych:


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.

sobota, 27 października 2012

Kalkulator CASIO fx-82ES PLUS i drażniący problem konwersji między systemami liczbowymi.

Jeśli już ktoś, kto zajmuje się informatyką i elektroniką cyfrową, decyduje się na zakup kalkulatora - często takie urządzenie bywa przydatne, a jak ktoś jest inżynierem, to posiadanie kalkulatora staje się nieodzowne (kalkulator to atrybut inżyniera) - chciałby, żeby jedną z jego podstawowych funkcjonalności była konwersja DEC->BIN->HEX->OCT->... A ponieważ tę funkcjonalność posiadają praktycznie wszystkie kalkulatory oznaczone napisem "scientific", nawet te bazarowe, zakupiłem kilka miesięcy temu wspomniany w tytule model, przejrzawszy wcześniej z grubsza jego funkcje. Właśnie - z grubsza. Okazało się, że kalkulatorek, który prowadzi obliczenia w zapisie naturalnym i jest naszpikowany wieloma funkcjami - w tym statystycznymi, potrafi obliczać wartości zadanej funkcji f(x) dla określonego przedziału x... nie ma wspomnianej konwersji!!! Miód po prostu... W pracy trzymam kalkulator za 12zł, który tę funkcjonalność posiada...
No ale trzeba sobie radzić. Oczywiście można dzielić sobie liczbę dziesiętną przez podstawę systemu docelowego, spisywać reszty z dzielenia itd. - znany algorytm. Ale do tego to w sumie kalkulatora nie trzeba - wystarczy kartka i ołówek. Odpada. Coś innego trzeba wymyślić...
I tak dziś, wykonując jakieś drobne obliczenia na tym wypas-kalkulatorze, przypomniał mi się problem konwersji i wymyśliłem sposób. Otóż jest w tym urządzonku wspomniana wcześniej funkcja obliczająca wartości f(x) dla pewnego przedziału x (x zmienia swoją wartość z zadanym krokiem). Wystarczy napisać funkcję, której wartości będą resztą z dzielenia x przez podstawę systemu liczbowego (testowałem na systemie binarnym, czyli 2), potem z uzyskanej tabelki spisać te wartości, które nas interesują (patrz: wspomniany wcześniej, popularny algorytm) i - voila! Mamy liczbę przekowertowaną!
A oto szczegóły:
  1. przełączamy kalkulator w tryb TABLE
  2. ustalamy liczbę miejsc dziesiętnych (FIX) na 0 - żeby funkcja Rnd zaokrąglała do wartości całkowitych
  3. funkcji, z której będziemy uzyskiwać wyniki, nadajemy postać f(x)=-(x-2Rnd(x/2)) - minus przed nawiasem, bo Rnd zaokrągla w górę, czyli np. 0,5 -> 1
  4. przedział dla x ustalamy od 0 do 12 (liczba, którą konwertujemy), z krokiem 1
  5. uruchamiamy proces i odczytujemy tabelkę :)
Podsumujmy więc:
  • zalety rozwiązania - bo jest to jakieś rozwiązanie problemu.
  • wady - sztuka dla sztuki, konieczność wspomagania się kartką, konwersja niewielkich liczb ze względu na ograniczoną pojemność pamięci kalkulatora...
No ale zawsze można się pobawić. Ot na przykład sprawdzić, jak kalkulator poradzi sobie z konwersją DEC->HEX :)

Inna rzecz, że gdyby się głębiej zastanowić, w konwersji DEC->BIN wystarczy tylko kartka i pisadło, nawet liczyć nie trzeba (nie wspomnę o konwersji niewielkich liczb w pamięci)...

czwartek, 25 października 2012

Programowanie AVR cz. 3: ATtiny2313, EEPROM AT24C04C i magistrala I2C. Oraz krótko o pewnej zapomnianej obietnicy.

000 wstęp

Głównym bohaterem tego posta jest magistrala I2C, zwana również interfejsem dwuprzewodowym (ang. Two-wire lub 2-wire interface). To proste łącze wykorzystywane jest w wielu ciekawych układach mogących współpracować z mikrokontrolerami i nie tylko. Można tu wspomnieć - żeby nie było, że użyłem słowa "wielu" bez pokrycia - choćby o układach pamięci, zegarach czasu rzeczywistego, przetwornikach AC/CA...
Co prawda "małe" mikrokontrolery nie mają dedykowanych linii dla I2C, ale dzięki środowiskom i bibliotekom dla programistów, zapewniającym pełną implementację m. in. protokołu I2C, mamy możliwość bezproblemowego wykorzystania dobrodziejstw tej magistrali posługując się uniwersalnymi liniami wejścia - wyjścia. Można też podjąć się samodzielnej implementacji obsługi tej magistrali - jeśli ktoś lubi takie wyzwania.

Na początek jednak warto przyjrzeć się samej idei i koncepcji magistrali I2C:
Dobrze by było też przeanalizować kartę katalogową układu AT24C04C (zakładam, że Tiny2313 już dość dobrze znamy):

Układ AT24C04C - jak sugeruje tytuł posta - to pamięć EEPROM. Nie jest to jednak kostka pamięci w klasycznym tego słowa rozumieniu, z wieloma liniami adresowymi i danych oraz liniami sterującymi - mówimy o tym układzie "pamięć szeregowa", ponieważ dostęp do jej zawartości uzyskujemy właśnie poprzez szeregową magistralę I2C. Taka konstrukcja pamięci pozwoliła przede wszystkim na zmniejszenie fizycznych rozmiarów układu do np. typowej kostki w obudowie DIP-8 (dwa rzędy po cztery wyprowadzenia), co sprzyja wykorzystaniu tego układu w małogabarytowych projektach.
Przy okazji przeglądania (analizy!) karty katalogowej AT24C04C, możemy się wiele dowiedzieć na temat samej magistrali, tym razem już konkretnie - głównie chodzi tu o protokół, sposób adresacji urządzeń itp. Ze względu zaś na prostotę operacji - bo w przypadku pamięci mamy wyłącznie zapis i odczyt bez dodatkowych czynności - AT24C04C jest rewelacyjnym środkiem dydaktycznym i znakomitym przykładem na początek przygody z naszą magistralą.

A dlaczego właśnie 24C04, a nie np. 24C08? Proste: taką kostkę akurat miałem...

No to zaczynamy!

001 przygotowanie układu

Trzeba pamiętać, że wiele układów cyfrowych przeznaczonych do współpracy z innymi układami za pomocą magistral, posiada wyjścia typu otwarty kolektor (otwarty dren). Żeby się nie rozpisywać - chodzi tutaj o "końcówkę mocy" wyjścia układu; jest ona niepełna, co daje możliwość dostosowania obciążenia układu w dużo większym zakresie, niż ma to miejsce w przypadku klasycznych wyjść cyfrowych. Dostosowanie obciążenia (to w pewnym sensie skrót myślowy - zainteresowanych odsyłam do literatury technicznej dotyczącej podstaw elektroniki) wykonuje się przy pomocy rezystorów podciągających, które stanowią uzupełnienie owego niekompletnego wyjścia układu. W przypadku I2C konieczne jest zastosowanie właśnie takich rezystorów dla obu linii (SCL i SDA); wartość tych rezystorów należy odpowiednio dobrać - w przypadku naszego układu będzie to 4,7kΩ. Oczywiście rezystor podciągający włączamy między zasilanie a linię magistrali. Dodatkowo linie I2C należy podłączyć do mikrokontrolera poprzez rezystory o wartości 300-330Ω.
Następnym krokiem w procesie przygotowania układu testowego jest ustalenie adresu sprzętowego dla kostki pamięci. Adresy urządzeń na magistrali I2C to liczby 7-bitowe. Ósmy bit (a w zasadzie pierwszy, bo na najmniej znaczącej pozycji) to znacznik kierunku transmisji - wartość "1" oznacza odczyt z urządzenia, "0" to zapis do urządzenia. Wynika z tego, że każde urządzenie ma dwa adresy 8-bitowe... Przeglądając dokumentację AT24C04 natkniemy się w którymś momencie właśnie na opis adresowania tego układu. Cztery najstarsze bity adresu 24C04 zawierają "zaszytą" sekwencję "1010", dalej brane są pod uwagę stany zadane na wyprowadzenia A2 i A1 układu (A0 jest ignorowane w przypadku 24C04), następnie mamy znacznik "banku" pamięci P0 i bit kierunku R/W. Co do znacznika banku pamięci - należy zwrócić uwagę, że układ 24C04 ma pojemność 4kb czyli 512B. Ponieważ przez magistralę I2C można przesyłać dane tylko w postaci paczek 8-bitowych, nie ma możliwości "płaskiego" adresowania całej zawartości pamięci - za pomocą liczby 8-bitowej jesteśmy w stanie zaadresować jedynie połowę zawartości tej pamięci, czyli 256B (24C04 ma organizację bajtową). Tutaj właśnie z pomocą przychodzi nam znacznik P0, który stanowi przełącznik dla owych połówek pamięci - np. dla P0=1 komórka pamięci o adresie 00h to tak naprawdę komórka o adresie 100h.
W naszym układzie testowym ustalamy wartość bitów A2 i A1 jako "0" (podłączamy do masy).
Jak się ostatecznie okazuje, nasz układ pamięci ma aż cztery adresy na magistrali I2C! Adresy te, już w postaci liczbowej dziesiętnej, znajdziecie w prezentowanym w dalszej części artykułu listingu programu.
Na koniec zerujemy wejście układu pamięci oznaczone jako WP (Write Protect), żeby zapewnić sobie możliwość swobodnego zapisu i odczytu.

Na poniższym schemacie widzimy już kompletny układ do testowania pamięci 24C04 i magistrali I2C:



Dodatkowo, w celu wizualizacji procesu poprawnego (lub nie) zapisu i odczytu pamięci, dołączyłem do układu testowego wyświetlacz LCD (na schemacie jest to wyświetlacz 16*2 - w rzeczywistości użyłem 16*1a) - klasyczny, na bazie układu kompatybilnego z HD44780 oraz dwie diody LED. Program (przedstawiony dalej) uruchamiany jest przyciskiem, który na schemacie widnieje pod postacią jumpera TEST J1 - tutaj też użyłem symbolu zastępczego (muszę uzupełnić biblioteki Eagle'a).

002 program

Żeby hardware był użyteczny, potrzebny jest software... Na listingu poniżej widnieje program testowy, którego zadaniem jest zapełnienie obu banków pamięci pewnymi wartościami (dla każdego banku jest to inna wartość), a następnie sprawdzenie, czy dane zostały prawidłowo zapisane - czyli odczytanie zawartości obu banków i porównanie liczby odczytanej z zakładaną wartością poprawną.



Polecam przeanalizowanie programu, ze szczególnym zwróceniem uwagi na to, jak elegancko zostały zaprojektowane funkcje BASCOMa operujące na magistrali I2C - odzwierciedlają one dość dokładnie "protokół" logiczny tej magistrali.

Należy zdać sobie sprawę, że sporą część kodu stanowią ozdobniki związane z wizualizacją operacji - stąd program po kompilacji zajmuje ok. 1,5kB. Same operacje komunikacji z I2C są tutaj w miarę lekkie.

Ktoś pomyśli: no ok, działa:


...ale jak sprawdzić, czy faktycznie? Bo każde następne uruchomienie spowoduje - w przypadku nieudanego zapisu - odczyt wcześniej zapisanych do pamięci danych, które są oczywiście poprawne. Sprawa jest prosta - trzeba przekompilować program z innymi wartościami Val_p0Val_p1. A jeśli ktoś chce sprawdzić, jak to jest z tymi rezystorami podciągającymi - zachęcam do wyjęcia jednego z nich (lub obu) w trakcie pracy układu. Efekty specjalne gwarantowane (spokojnie, jeśli nie zrobicie gdzieś jakiegoś zwarcia, nic się nie spali).

003 todo

Jeśli nic nie pomyliliśmy, to nasz układ do testowania I2C powinien działać bez problemów. Nie wiem, jak Wy, ale ja zwykle lubię troszkę podrążyć temat (sukces jest najlepszą zachętą) - proponuję więc przyjrzenie się układowi PCF8583P. Jest to zegar czasu rzeczywistego z kalendarzem - oczywiście obsługiwany poprzez I2C i umieszczony, podobnie jak AT24C04, w malutkiej obudowie ośmiowyprowadzeniowej. Podłączamy do niego oscylator (ok. 34kHz), kondensatorek 33pF, zapewniamy ciągły dostęp zasilania (można z baterii) i... Ale o tym być może wkrótce :) Zachęcam również do samodzielnych eksperymentów.

Postscriptum

Dawno temu obiecałem (tak, czego ja już na tym blogu nie obiecywałem...) program do przekształcenia ATtiny 2313 w układ sterowania linijką świetlną. Oto i on:



Jeżeli chodzi o elektronikę, do portu B mikrokontrolera podłączamy osiem diod LED poprzez rezystor 220Ω (podobnie jak na schemacie pokazanym wcześniej), zaś do wskazanych na listingu wyprowadzeń portu D - przyciski zwierające do masy. Do tego oczywiście oscylator 4MHz z dwoma kondensatorkami 33pF (również jak na wcześniejszym schemacie).

Po wgraniu programu można pobawić się efektami świetlnymi (proszę zwrócić uwagę, że efekt "spoczynkowy" jest generowany przez pracujący w tle timer, natomiast definicje efektów umieszczone są w wewnętrznej pamięci EEPROM mikrokontrolera).
Udanych eksperymentów zatem!

ERRATA czy też konieczny, acz zapomniany dopisek

Zagłębiając się w adresowanie układów na magistrali I2C i podłączanie ich do niej, zapomniałem o czymś, co wprawdzie łatwo można znaleźć w kodzie programu (pierwszy listing), ale co nie rzuca się specjalnie w oczy. A powinno.
Otóż jako wyjścia magistrali I2C mikrokontrolera ATtiny 2313 mogą zostać użyte dowolne dwie linie portów wejścia-wyjścia. U mnie, m. in. ze względu na konieczność podłączenia wyświetlacza, jako wyprowadzenia I2C "robią" linie (wyjścia) PORTB.1 (SCL) i PORTB.0 (SDA). Konfiguracji tych wyjść można dokonać z poziomu środowiska BASCOMa (Options -> Compiler -> I2C):


Dodatkowo zalecałbym wstawienie do kodu, przed deklaracjami zmiennych, dwóch linijek, których znaczenie jest to samo, jak powyższych ustawień środowiska dla I2C:
Config Scl = Portb.1
Config Sda = Portb.0
Dublowanie konfiguracji nie jest szkodliwe, a w tym przypadku wręcz pożądane (uniezależnimy się od konfiguracji środowiska - czasem po prostu możemy o niej zapomnieć).

środa, 12 września 2012

Programowanie mikrokontrolerów AVR cz. 2

Parę uwag na temat programowania w sensie wgrywania przygotowanego (skompilowanego) programu (wsadu) do pamięci flash mikrokontrolera ATtiny2313 (i nie tylko).
W pierwszym artykule na temat programowania AVR-ów założyłem, że dysponujemy płytką AVT3500 wraz z programatorem (kompatybilnym z STK500 v2) - płytka ta i programator wchodzą między innymi w skład zestawu do nauki programowania procesorów AVR. Nie każdy jednak ma dostęp do takiej płytki, czy też ma możliwość jej nabycia. Sam również postanowiłem uniezależnić się od tego zestawu - dotychczas używałem wypożyczonego z pracy. W związku z tym nabyłem (drogą kupna) polecany przez wielu użytkowników programator zgodny z USBASP i podłączyłem go do układu ATtiny2313 według wskazówek z artykułów:
Wszystko działa elegancko - mogę zaprogramować układ bezpośrednio ze środowiska BASCOM-AVR oraz korzystając z avrdude (zarówno w systemach Linux, jak i w moim wirtualizowanym Windows XP).

Muszę jednak, dla ścisłości, dodać kilka uwag od siebie (z krótkiego, kilkudziesięciominutowego doświadczenia programatorem USBASP).
Po pierwsze, żeby zaprogramować za pomocą tego programatora mikrokontroler ATtiny2313, należy założyć zworkę na styki opisane (na płytce programatora) jako Slow SCK (jak zwykle niezawodne forum elektroda.pl).
Po drugie, jeśli macie zamiar użyć taśmy do połączenia programatora z układem, pamiętajcie o wskazówce Łukasza z linkowanego wyżej artykułu:
"Jeżeli przewody podłączacie do taśmy, zamiast bezpośrednio do programatora, musicie “odbić” całość w pionie."
Chyba, że chcecie przetestować wytrzymałość i zabezpieczenia elektryczne łącza USB w Waszym komputerze. Ja niechcący przetestowałem - płyta główna przeżyła, programator i ATtiny też, choć, wyposażone w lampki kontrolne zasilania, urządzenia podłączone do USB nerwowo tymi lampkami mrugały... Po raz kolejny okazuje się, że płyty główne MSI tak szybko nie padają ;)

A wkrótce wrócę do konkretów, czyli napiszę o linijce świetlnej, w której zamiast specjalizowanych układów użyjemy naszego ATtiny. I oczywiście będzie też o możliwościach rozbudowy tego programu i wykorzystania go do innych rzeczy (np. wyświetlanie znaków na matrycy diodowej).

poniedziałek, 3 września 2012

Programowanie mikrokontrolerów AVR cz. 0

Zwykle w okolicach początku roku szkolnego piszę o edukacji jako takiej - co bym zmienił, co jest złe, co dobre itp. Dziś, zamiast tego co zwykle, będzie prequel poprzedniego artykułu o programowaniu AVR-ów w BASCOM-ie, a w zasadzie krótka prezentacja, jak w najprostszy sposób zmontować nieskomplikowany układ z ATtiny2313 w roli głównej.
Najpierw koncepcja. Wykorzystamy dwa wyjścia mikrokontrolera do zapalania i gaszenia (na przemian) dwóch diod świecących lub - jak w moim przypadku - kolorków jednej diody dwukolorowej ze wspólną katodą. Żeby nie przesadzać (jeszcze bardziej - wszak taki układ można zmontować z dwóch tranzystorów, dwóch kondensatorów i kilku rezystorów) z przerostem formy nad treścią, wykorzystamy wewnętrzny zegar taktujący ATtiny (co prawda 8MHz, ale mocno niestabilny - tutaj jednak nie powinno to w niczym przeszkadzać), cały układ natomiast zasilimy z trzech baterii AA (3*1,5V). Potrzebny będzie zatem ATtiny2313, dwa rezystory 220 Ohm, jedna dioda świecąca dwukolorowa ze wspólną katodą, kondensator 10 µF (choć przy tym zasilaniu nie jest on konieczny), płytka stykowa z drucikami. Podłączamy anody diody świecącej poprzez rezystory do wybranych wyprowadzeń mikrokontrolera - w moim projekcie są to odnóża 18 (bit 7 portu B) i 12 (bit 1 portu B). Pozostałe połączenia, czyli zasilanie - według dokumentacji ATtiny (napięcie zasilania przykładamy pomiędzy wyprowadzenia 20 i 10).
Kontroler trzeba zaprogramować, np. takim wsadem (tutaj będzie potrzebna nasza płytka uruchomieniowa lub programator):


przepiąć procesorek i włączyć zasilanie układu :)
Powinno ładnie mrygać - na zdjęciu tego nie widać:


ale już skręcony na szybko klip wideo pokazuje więcej:


Prawda, że proste?
Układ ten będzie jednym z pierwszych, które uczniowie zmontują i uruchomią podczas zajęć. Potem będzie już tylko ciekawiej.

sobota, 25 sierpnia 2012

RaspberryPi jako domowy serwer WWW - test wydajności (cz.2: Raspbian)

Po kilku godzinach poświęconych na doprowadzenie świeżo pobranego Raspbiana do stanu używalności - czyli po doinstalowaniu niezbędnych pakietów oprogramowania i skonfigurowaniu sobie środowiska pracy - przystąpiłem do testów serwerów WWW. Zasady testowania były podobne, jak za poprzednim razem, jednak konfiguracja platformy nginx + PHP trochę się zmieniła. Otóż jak pisałem wczoraj na twitterze i G+, repozytoria Raspbiana są bogatsze, niż Debiana Squeeze - przynajmniej o php5-fpm (FastCGI Process Manager) oraz node.js (w wersji 0.6.19 - nie najnowsza, ale w zupełności wystarczy). W poprzednim rozwiązaniu nginx współpracował z PHP poprzez FastCGI za pośrednictwem "rozpylacza" spawn_fcgi, który skonfigurowałem do odpalania maksymalnie trzech procesów php5-cgi. W nowszym rozwiązaniu mamy już możliwość zainstalowania efektywnego "rozpylacza" w postaci właśnie PHP-FPM, który - przynajmniej w założeniach - powinien działać adaptatywnie, czyli odpalać odpowiednią liczbę procesów php w zależności od potrzeb. Podczas testów uruchamiane było maksymalnie 5 procesów, więc istniała szansa, że - pomijając oczekiwane przyspieszenie ze względu na optymalizację platformy systemowej dla malinowego arma - serwer będzie działał sprawniej.
Żeby już nie męczyć Was (i siebie ;-)) wykresami, przedstawię tylko uśrednione wyniki testów. Przy okazji, podjąłem próbę wykonania testu na 3000 żądań po 300 równolegle - o ile nginx się parę razy zaksztusił, o tyle aplikacja node.js śmigała, jakby nic nigdy się nie stało. Oto więc wyniki:

Test na 1000 żądań po 100 równolegle
nginx:
Średnia liczba obsłużonych żądań na sekundę: 125,451 (maks. 152,21)
Średni czas obsługi żądania: 8,201 ms (min. 6,57 ms)
node.js:
Średnia liczba obsłużonych żądań na sekundę: 186,865 (maks. 188.71)
Średni czas obsługi żądania: 5,351 ms (min. 5,299 ms)

Test na 2000 żądań po 200 równolegle
nginx:
Średnia liczba obsłużonych żądań na sekundę: 143,411 (maks. 163.25)
Średni czas obsługi żądania: 7,05 ms (min. 6,126 ms)
node.js:
Średnia liczba obsłużonych żądań na sekundę: 187,771 (maks. 189.18)
Średni czas obsługi żądania: 5,326 ms (min. 5,286 ms)

Test na 3000 żądań po3100 równolegle
nginx: /dane z 7 ukończonych prób na 10 wykonanych/
Średnia liczba obsłużonych żądań na sekundę: 144,749 (maks. 154,15)
Średni czas obsługi żądania: 6,923 ms (min. 6,487 ms)
node.js:
Średnia liczba obsłużonych żądań na sekundę: 185,165 (maks. 187.19)
Średni czas obsługi żądania: 5,403 ms (min. 5,342 ms)

Wyniki są interesujące. Przede wszystkim moją uwagę zwróciło nierówne działanie nginksa, szczególnie podczas pierwszego testu (1000/100) - mocno zróżnicowane osiągi spowodowały dosyć słabe wartości średnie. Przy okazji wyszło, że nginx lepiej (sprawniej) działa przy większej liczbie żądań w danym czasie - byłby to bez mała serwer idealny (gdyby nie node.js ;))! Niestety, dane z trzeciego testu są w przypadku nginksa niekompletne - serwer zaczął "niewyrabiać" i trzy próby zakończyły się niepowodzeniem, ale próby udane świadczą o tym, że nginx ma możliwość utrzymania stałej wydajności nawet przy większym obciążeniu.
Node.js, jak wynika z testów, działa niczym przysłowiowy przecinak - wyniki poszczególnych serii (prób) nie różnią się specjalnie od siebie, a spadek wydajności przy dużym obciążeniu żądaniami jest nadal pomijalny. Oczywiście znów się okazuje, że node.js działa szybciej, niż nginx + PHP.
W poprzednich testach, na Debianie Squeeze, nginx osiągnął wartości średnie liczby obsłużonych żądań i czasu obsługi jednego żądania odpowiednio 152,487 i 6,56 ms dla testu "1000/100" oraz 135,739 i 7,378 ms dla testu "2000/200". Oznacza to, że w systemie Raspbian połączenie nginx i PHP działa sprawniej przy dużym obciążeniu - i to jest pozytywna informacja.
Jeśli zaś chodzi o node.js, to niestety wydajność w Raspbianie spadła w stosunku do tego, co zaobserwowałem w poprzedniej wersji systemu. W starym Squeeze node.js obsługiwał średnio 213 - 216 żądań na sekundę, a czas obsługi jednego żądania nie przekraczał 4,7 ms. Może to być winą sposobu przygotowania prekompilowanego node'a (dostępnego w repozytoriach systemu) - na Debianie dysponowałem binarkami własnoręcznie skompilowanymi, all-in-one, nie odwołującymi się do współdzielonych bibliotek (oczywiście poza niezbędnymi, systemowymi) itd.
Podsumowując - krótko - w Raspbianie, jeśli chodzi o serwery WWW, szału nie ma, choć nginx i PHP zdają się być tutaj dość stabilną rodziną. Cały czas jednak "oko Saurona" powinno być skierowane na Node.js - to na pewno jest właśnie TA platforma, która będzie rządziła na takich niewielkich komputerkach starających się być serwerami WWW.

piątek, 24 sierpnia 2012

RaspberryPi jako domowy serwer WWW - test wydajności (cz.1: Debian Squeeze)

W poprzednim wpisie na temat Raspberry Pi przedstawiłem sposób przekształcenia popularnej Maliny w domowy serwer WWW. Wykorzystałem nginksa, ponieważ jest lżejszy od apache, głównie dzięki  (ciągle jeszcze) nowatorskiej metodzie obsługi żądań, pozwalającej zaoszczędzić cenne zasoby skromnego systemu komputerowego, jakim niewątpliwie jest Raspberry Pi. Do tego oczywiście PHP5 i interfejs FastCGI, MySQL i SQLite. MySQL w wersji dostępnej w ramach dystrybucji Debian Squeeeze okazał się "odrobinę" za ciężki dla RPi, dlatego też, o ile to tylko możliwe, powinno się korzystać z SQLite lub innego, lekkiego rozwiązania - może któraś z NoSQL? Ale to już temat na osobny artykuł (NoSQL to nie moja działka) - wróćmy zatem do samego serwera webowego.
Bardzo ważna jest wydajność serwera WWW, rozumiana tutaj jako jego zdolność do sprawnego obsłużenia pewnej liczby żądań w jednostce czasu. Owszem, serwer domowy będzie obsługiwał co najwyżej kilka żądań w danym momencie, ale chodzi o sprawdzenie, jakim zapasem cierpliwości powinien dysponować użytkownik korzystający z świadczonych przez ten serwer usług.
Testy, o których mowa w tytule artykułu, polegały na sprawdzeniu za pomocą popularnego programu ab (Apache HTTP server benchmarking tool), jak serwer nginx, dostarczający prostą, napisaną w PHP aplikację zwracającą bieżącą datę i godzinę, radzi sobie z nawałem żądań.
Kod aplikacji testowej w PHP raczej nie powinien nikogo zaskoczyć:


Dla porównania przygotowałem aplikację sieciową zwracającą takie same informacje, napisaną w JavaScripcie dla Node.js:


Chodziło mi generalnie o to, żeby przeprowadzić podobne zestawienie, jak to miało miejsce w przypadku mojego - poświęconego właśnie Node.js - wystąpienia podczas 35. spotkania ŚRGM i PLSSUG w Katowicach.
W czasie testów zarówno nginx, jak i aplikacja Node.js, były uruchomione (działały "równolegle", nasłuchując na dwóch oddzielnych portach) i atakowane strumieniami żądań na przemian, za pomocą prostego skryptu (tutaj w wersji drugiej - poniżej wyjaśnienie):


Najpierw przeprowadziłem szybki test, polegający dziesięciokrotnym wysłaniu do każdego z serwerów po 1000 żądań, w porcjach po 100 żądań w tym samym czasie  (równolegle). Drugi test wyglądał podobnie z tym, że zwiększyłem liczbę żądań dwukrotnie - zarówno ogólną, jak i liczbę żądań wysyłanych równolegle. Przy większych liczbach żądań niż te, których użyłem w testach, Malina zaczynała się ksztusić; nie chciałem jednak szukać wartości progowych metodą prób i błędów, biorąc pod uwagę wiele czynników wpływających na wahania obciążenia komputera w danym momencie - i tak musiałbym przyjąć pewne wartości "bezpieczne".
Wyniki testów przedstawione zostały na wykresach, do których przejrzenia zachęcam (tutaj, żeby nie przesadzać z długością posta, tylko cztery najważniejsze wykresy, resztę można znaleźć w specjalnie przygotowanym "albumie").

Wykres 1: zestawienie liczby obsłużonych żądań na sekundę dla 10 prób (część pierwsza testu - 1000 żądań po 100 równolegle).

Wykres 2: zestawienie liczby obsłużonych żądań na sekundę dla 10 prób (część druga testu - 2000 żądań po 200 równolegle).

Wykres 3: średni czas obsługi żądania w przypadku obu serwerów - dla 10 prób (część pierwsza testu - 1000 żądań po 100 równolegle).

Wykres 4: średni czas obsługi żądania w przypadku obu serwerów - dla 10 prób (część druga testu - 2000 żądań po 200 równolegle).

Dla porównania można sprawdzić, jak wyglądały wyniki testów apache i Node.js w przypadku zwykłego, średniej klasy peceta - proszę przejść do slajdów nr 14 i 15 w prezentacji ze wspomnianego wcześniej spotkania.
Testy malinowego serwera WWW przeprowadziłem jeszcze na poprzednim, zalecanym dla RaspberryPi systemie Debian Squeeze, dlatego też wydaje mi się, biorąc pod uwagę to, co zaprezentował w swoim blogu Przemek Rumik (a co sprawdziłem osobiście na owym Debianie - wyszły wyniki słabsze, niż u Przemka), że Raspbian, zoptymalizowany dla RPi, pozwoli osiągnąć dużo lepsze rezultaty. Wkrótce powtórzę moje testy (i testy Przemka) na nowej, zoptymalizowanej dystrybucji Debiana.
Pora na kilka wniosków...
Proszę zwrócić uwagę, że nawet na tak mało wydajnym komputerze istnieje szansa, że siły i środki zainwestowane w zgłębienie wiedzy na temat tworzenia aplikacji sieciowych w Node.js mogą się zwrócić z nawiązką (spadek wydajności aplikacji Node.js przy podwojeniu intensywności testów był niewielki, prawie pomijalny). Trzeba tylko sprawdzić, czy uda się na RPi sensownie wdrożyć jakąś konkretną aplikację WWW (ciągle mamy wąskie gardło w postaci storage'u - karta SD, "coś" na USB lub poprzez moduł dla GPIO, o ile to ostatnie rozwiązanie istnieje). Próby z AjaXplorerem czy phpMyAdminem pokazały, że nie jest wesoło pod względem wydajności. No ale to był nginx (wcześniej - o zgrozo - apache; na Google+ prezentowałem screeny przedstawiające stan wolnej pamięci RPi, gdy strony serwował apacz; przejście na nginx było koniecznością i stanowiło dużą ulgę dla zasobów Maliny) i PHP5 poprzez FastCGI - może Node da radę "bardziej"?

Parę linków, które mogą się przydać:



środa, 11 lipca 2012

RaspberryPi jako domowy serwer WWW

000 pomysł

Stworzenie serwera domowych zasobów cyfrowych, czyli plików wszelkiej maści (chodzi o niewielką liczbę plików, do których chcemy mieć szybki dostęp; głównie zdjęcia i muzyka, ewentualnie jakieś dokumenty, faktury itp.) to jeden z pomysłów na wykorzystanie platformy RaspberryPi (http://www.raspberrypi.org/, dedykowane WiKi: http://elinux.org/R-Pi_Hub).

001 konfiguracja

Zaczynamy od podstawowej konfiguracji Debiana, dostępnego na stronie projektu w sekcji Downloads - wszystkie niezbędne czynności opisano np. na wskazanej wcześniej stronie WiKi.
Warto włączyć sobie obsługę karty muzycznej (nieprzydatna w serwerze, ale chcemy mieć pewność, że wszystko działa ;)) - najlepiej według opisu na stronie http://j.mp/M6oRuG. Pamiętać musimy, że w celu automatycznego uruchamiania dźwiękówki podczas startu systemu, należy uaktywnić moduł snd_bcm2835 w pliku /etc/modules.
Następny krok nie jest konieczny, ale można spróbować - chodzi o obsługę "kart" WiFi (w postaci dongla USB). Jeśli dysponujemy jednak infrastrukturą LAN, sugeruję z niej skorzystać - nie będziemy zajmować jednego z dwóch jakże cennych gniazd USB naszej maliny, tym bardziej, że karty WiFi USB nie przepadają w przypadku maliny za hubami USB, nawet tymi aktywnymi (z własnym zasilaniem). Instalacja kart WiFi przedstawiona została w artykule dostępnym pod adresem http://j.mp/M6nbl3. W nowszych dystrybucjach zalecanego dla RPi systemu raczej nie trzeba dodawać wspomnianych tam repozytoriów - po prostu sprawdźcie, czy da się pominąć krok pierwszy. Jeśli wszystko się uda, mamy bezprzewodowy dostęp do sieci lokalnej i internetu (o ile mamy oczywiście wyjście na świat). U mnie RPi bardzo sprawnie działa z popularną, szalenie tanią (~15zł) "kartą" Sagem XG-762N. Poniżej zawartość pliku /etc/network/interfaces mojego RPi:


Plik zawiera zakomentowaną część dotyczącą karty bezprzewodowej, ale konfiguracja jest jak najbardziej prawidłowa i sprawdzona. Zmieniłem sieć WiFi na LAN ze względu na słaby zasięg mojej sieci domowej w miejscu, gdzie testuję RPi (stary router ADSL jako switch i udostępnianie połączenia przez komputer stacjonarny za pomocą programu Firestarter). Bardzo ważna uwaga: nie zapominajmy o pliku /etc/resolv.conf - niezależnie od tego, jakiej karty używamy, musimy tam wpisać adresy serwerów DNS, w przeciwnym wypadku nie będziemy mogli posługiwać się nazwami domenowymi...
Oczywiście w przypadku obu kart sieciowych adres IP jest stały - konfiguracja łącza przez DHCP byłaby dla stacji klienckich utrudnieniem, zwłaszcza, że np. mój router, który przy okazji rozrzuca adresy, ma słabe możliwości konfiguracji czasu dzierżawy.

OK, teraz już nasza malina powinna odtwarzać muzykę (doinstalujcie np. mpg321) i - co najważniejsze - mieć swobodny dostęp do sieci. Ktoś może zapytać o firewall - cóż, chwilowo jest to niedostępny luksus, musimy poczekać do aktualizacji systemu.

010 klasyka - apache, mysql, php5, sqlite3

Krótko:
sudo apt-get install sqlite3
sudo apt-get install apache2
sudo apt-get install php5

Szczegóły znajdziemy oczywiście w sieci - ciekawy opis jest np. tutaj: http://www.instructables.com/id/Raspberry-Pi-Web-Server/
Niestety, szybko okazało się, że mimo wielu zabiegów i prób optymalizacji, klasyczna kombinacja LAMP powoduje jeden wielki wyciek pamięci (przypominam, że w malinie mamy do dyspozycji w klasycznej konfiguracji ok. 192MB), paraliżujący maszynkę, w niektórych przypadkach na dobre. Dlatego też, dzięki radom kolegów z G+, zmieniłem apacza na...

011 ekscentryzm - apache schodzi z boiska, za niego, z numerem 2, wchodzi nginx

Projekt Node.js (nodejs.org) przekonał mnie do serwerów działających w oparciu o pętlę zdarzeń. Zamieniłem więc apache na nginx - oczywiście należało odpowiednie pakiety zainstalować i skonfigurować. Niestety, w oficjalnych repozytoriach dla Debiana na RPi nie ma jeszcze pakietu php5-fpm, dlatego też skorzystałem z opisu przedstawionego w artykule pod adresem http://j.mp/NnRnFE. Jedyna różnica u mnie polega na tym, że uruchamiam php5-cgi po "dźwignięciu" interfejsu sieciowego, czyli poprzez umieszczony w katalogu /etc/network/if-up.d skrypt php-fastcgi:


Można oczywiście (ostrożnie) poeksperymentować z liczbą odpalanych procesów php5-cgi.

100 sprzątanie

Jeśli nic strasznego po drodze się nie wydarzyło, to mamy działający serwer WWW za ~170zł ;)
MySQL okazał się chwilowo niepotrzebny, ponieważ użyłem oprogramowania eXtplorer (http://extplorer.sourceforge.net/), nie korzystającego z serwera baz danych. W sumie mając sqlite3 możemy - o ile program, którego będziemy chcieli użyć, na to pozwala - wymusić pracę z  plikowymi bazami danych. Wyłączenie automatycznego uruchamiania MySQL uwolniło trochę RAM-u (ok. 20MB). Oczywiście należy też wyłączyć automatyczny start apacza - polecam program rcconf ;)

W obecnej konfiguracji mój RaspberryPi dysponuje po uruchomieniu ok. 128MB wolnej pamięci i podczas działania usług WWW raczej nie schodzi poniżej 30MB, przy założeniu, że jest to faktycznie domowy serwer (np. góra dwie stacje klienckie w jednym momencie).

101 pytania

Z oczywistych powodów (dublowanie zawartości internetów ;)) mój opis jest dosyć lakoniczny i przypomina raczej sprawozdanie, przeznaczone dla osób, które jednak jakiegoś linuksa debianopodobnego kiedykolwiek używały. Dlatego też zachęcam do zadawania pytań - tutaj, na twitterze i G+.

110 postscriptum

Warto się zastanowić, jakiego urządzenia użyć do przechowywania danych udostępnianych przez nasz serwer. Karta SD 8GB (jak u mnie) to niewiele i nie za szybko... Dysk twardy na USB? Mój nie zadziałał (zapewne kwestia zasilania...)...


czwartek, 26 kwietnia 2012

Programowanie mikrokontrolerów AVR cz. 1

Niniejszym rozpoczynam serię artykułów, których celem będzie zgromadzenie i udostępnienie programów ilustrujących różne aspekty programowania mikrokontrolerów AVR. Nie ukrywam, że będzie to seria przeznaczona przede wszystkim dla uczniów technikum, dla których prowadzę zajęcia z układów mikroprocesorowych i z programowania mikroprocesorów. Zaczniemy oczywiście od podstaw i od prostych mikrokontrolerów (posiadamy platformy testowo-uruchomieniowe dla ATtiny2313, w planach na "powakacje" są również ATmegi); oczywiście programy będą dotyczyły na początku elementarnej problematyki działania układów mikroprocesorowych, komunikacji ze "światem zewnętrznym" i użytkownikiem.
A dziś jeden prosty program (na zachętę), który napisaliśmy z uczniami w środę, 25 kwietnia, na sucho, na tablicy - latająca małpka ("@" przemieszcza się dookoła ekranu). Jednak na zajęciach program był przedstawiony łopatologicznie, napisany "metodą inżyniera Nachamowa". Tutaj zaś pojawiają się nowe elementy, poprawiające odrobinę m. in. stronę wizualną kodu źródłowego.
Zapraszam do śledzenia artykułów wszystkich początkujących. No i moich uczniów oczywiście, którzy za tydzień zaczynają miesięczną praktykę zawodową, więc będą mieli trochę czasu, żeby poćwiczyć programowanie.



Na koniec pytanie: dlaczego BASCOM?
Już odpowiadam: ze względu na popularność w środowiskach elektroników, dostępność materiałów, kursów, literatury (w skład zestawów kursowych, które zakupiliśmy, wchodzi świetna książka Piotra Góreckiego), dedykowanych kursom zestawów uruchomieniowych itd. Język C też wprowadzę, ale jeszcze nie teraz.

sobota, 31 marca 2012

Samsung GT-C3322, czyli powrót do zwykłego telefonu.

Krótko trwała moja przygoda ze smartfonem, chociaż po Siemensie M50 (wiosna 2003 - lato 2006) Nokia E51 jest u mnie na drugim miejscu pod względem czasu użytkowania (wiosna 2009 - wiosna 2012), a niewątpliwie na pierwszym miejscu ze względu na intensywność użytkowania. I pewnie nie zrezygnowałbym z tego urządzenia ot tak, żeby wymienić na nowe, ale - niestety - od pewnego czasu miałem wrażenie, że bardzo słabo słyszę rozmówcę (tak, używałem tego telefonu do klasycznych rozmów, nie tylko przez Skype).
Szukałem czegoś w miarę nieskomplikowanego za całkowicie niewielkie pieniądze (300 - 400 zł). Niestety, ciężko znaleźć w tym przedziale cenowym coś interesującego, mimo moich skromnych wymagań. Zdecydowałem się jednak na telefon dość nowy, wprowadzony na rynek w październiku 2011 roku (o ile wierzyć serwisom specjalistycznym) i zaskakująco tani (259 zł w Euro AGD RTV), Samsung GT-C3322. W zasadzie dwie rzeczy zadecydowały o zakupie: możliwość obsługi dwóch kart SIM (mam dwa aktywne numery, więc jak znalazł) i bardzo wygodny design - klasyczna obudowa, szeroko rozstawione klawisze (część klawiaturowa zajmuje ok. 50% przedniej ścianki) i spory jak na tego typu telefony ekran (2,2 cala przy rozdzielczości 320x240 punktów).
Chciałbym się z Wami podzielić kilkoma spostrzeżeniami, które poczyniłem po pierwszym dniu zabawy z tym urządzonkiem. Nie będę opisywał oczywiście wszystkich jego cech, parametrów itp. ponieważ te informacje można bez problemu znaleźć w sieci, wraz z recenzjami. Swoją drogą, porażająca większość recenzji wygląda tak, jakby ludzie, którzy je napisali, w ogóle nie mieli tego aparatu w ręce. Mniejsza.
Zacznijmy od niewygód. Pierwsza to brak powszechnego, zapewnianego przez system „kopiuj-wklej” - przydaje się nie tylko we wbudowanym edytorze wiadomości. Być może jest taka funkcjonalność, ale nie udało mi się do niej dotrzeć. O, i przy okazji druga niewygoda: lakoniczna instrukcja obsługi (na stronie producenta ta sama w PDF-ie) typu „szybki start”. Rozumiem, że większość ludzi nie czyta instrukcji, ale ten telefon nie jest jednak aż tak prosty, mimo wszystko ("głębokie" funkcje wymagają jednak kilku słów wyjaśnień - szczególnie ważne dla niezaawansowanych użytkowników).
Przyzwyczajenie do smartfona spowodowało, że bardzo ciężko mi jest pogodzić się z brakiem wielozadaniowości (rozumianej tutaj jako możliwość uruchamiania kilku aplikacji i przełączania się między nimi) - no, może oprócz muzyki, która może sobie „lecieć” w tle i podsystemu Bluetooth, ale to już raczej wymóg implementacyjny (wszak każdy wie, że Bluetooth jest z definicji przeznaczony do środowisk wielozadaniowych). Pamiętajmy jednak, że GT-C3322 to telefon i jako taki jest urządzeniem o ograniczonych zasobach.
Kolejna sprawa - przycisk popularnie zwany „joystickiem”. Źle zaprojektowany - opcja „do góry” wymaga precyzyjnego naciśnięcia.
Bardzo duża wada: ograniczona do około 5MB przestrzeń pamięci dla aplikacji J2ME. Należy poważnie zastanowić się nad usunięciem preinstalowanych gier, zresztą i tak w wersji demonstracyjnej. Owszem, nie jest to smartfon, jednak wydaje mi się, że powinno się dać użytkownikom więcej swobody.
Jako ostatnią wadę wymienię jeszcze dość słabego klienta email, choć łatwego w konfiguracji i obsłudze (wbudowane szablony ustawień dla najpopularniejszych serwisów pocztowych).
Teraz rzeczy fajne. O dizajnie, wygodnych klawiszach i funkcjonalnym wyświetlaczu już pisałem, czas na resztę.
Obsługa dwóch kart SIM, czyli np. dwóch osobnych sieci, jest dla mnie szalenie wygodną rzeczą (nie lubimy nosić dwóch telefonów, prawda?). Do tego dochodzi bardzo łatwe przełączanie między sieciami, z pełną personalizacją ustawień dla każdej z nich - od tapety, sygnałów i motywu począwszy. Obsługa kart pamięci (microSDHC) nie jest tu od rzeczy - telefon ma wbudowane zaledwie 45MB przestrzeni do użycia w celu przechowywania własnych plików. Nie można co prawda instalować oprogramowania na karcie, ale dzięki temu, po podłączeniu telefonu do komputera (wspólne gniazdko microUSB dla ładowarki i kabla do transmisji danych; zakryte elegancką osłonką), mamy zawsze bezproblemowy dostęp do karty i pamięci wbudowanej w trybie pamięci masowej.
Miłośnicy serwisów społecznościowych (głównie Twittera i Facebooka) znajdą w oprogramowaniu telefonu natywne aplikacje do ich obsługi, owszem, dość skromne, ale należy pamiętać, że jest to - przypomnę po raz kolejny - tylko telefon, obsługujący połączenia z internetem w trybie EDGE. Przy okazji, połączenie z internetem działa bezproblemowo.
Ciekawostką jest aplikacja ActiveSync, znana chyba głównie użytkownikom mobilnych systemów Windows. Nie sądziłem, że z niej skorzystam, jednak okazało się, że rewelacyjnie nadaje się do synchronizacji wbudowanego kalendarza telefonu z kalendarzem Google. Co prawda telefon obsługuje protokół SyncML, ale w ograniczonym stopniu, więc użycie serwisu syncme.se (dzielnie działał w mojej Nokii) odpadło po kilku nieudanych próbach.
Z rzeczy nietelefonicznych i niesieciowych, C3322 posiada bardzo fajny i funkcjonalny tzw. tryb inteligentnego ekranu głównego, znany choćby użytkownikom Nokii z Symbianem. Można wyświetlać wiele rzeczy, do najważniejszych jednak należą niewątpliwie pasek skrótów do ulubionych aplikacji (zdecydowanie pojemniejszy, niż ten w Symbianie), duży zegar, widget pokazujący pogodę na podstawie danych z serwisu AccuWeather (świetnie jest ustawić go na aktualizację np. co 6 godzin; niestety lokalizację trzeba skonfigurować ręcznie) i - oczywiście - informacje o zdarzeniach, jak np. nadejście wiadomości SMS/MMS, email, nieodebranej rozmowy, a w przypadku odtwarzania muzyki - sterowanie odtwarzaczem.
Aplikacja aparatu fotograficznego jest bardzo wygodna, podobna do tych, które były stosowane w dobrych telefonach Sony-Ericssona. O ile filmy są słabej jakości (głównie przez niską, MMS-ową rozdzielczość), o tyle zdjęcia wychodzą niezłe. Matryca tego aparatu jest optymalna dla telefonów - 2MPix. Biorąc pod uwagę rozmiar fizyczny takiej matrycy, pakowanie większe liczby punktów światłoczułych zdaje się być nieporozumieniem. Ale za to gwarantuje wyższą sprzedaż i rzesze fanów ;)
Z dodatków multimedialnych mamy oczywiście niezły odtwarzacz audio oraz bardzo dobrze odbierające radio, które nie wymaga podłączenia słuchawek czy połączenia z internetem. Nie ma natomiast RDS-a, ale nie jest to jakaś specjalna wada.
I to chyba wszystko, co zdążyłem rozpoznać i połapać, zanim nie wycieńczyłem baterii - teraz czas na karmienie telefonu :)
Jak na pierwszy dzień użytkowania Samsunga, jestem bardzo zadowolony i mam nadzieję, że będzie tak nadal. Nokii E51 się oczywiście nie pozbywam (zgodnie z zasadą „Reuse”) - świetnie działa w offline jako nawigacja, odtwarzacz multimedialny, klient usług sieciowych poprzez WiFi (YouTube, WWW, poczta, Foursquare...), inteligentny pilot do prezentacji (i sterowania czymkolwiek w PC), uniwersalny pilot do sprzętu RTV i jeszcze wielu innych rzeczy, do których nie jest mi aż tak bardzo potrzebny mocny dźwięk w słuchawce.
Jeśli ktoś jest zainteresowany Samsungiem GT-C3322, może spokojnie w ten telefon inwestować, o ile robi to z pełną świadomością, że C3322 to nie Galaxy SII.

Edycja po następnym dniu użytkowania:

  1. Do słuchania radia jednak trzeba mieć podłączone słuchawki - mimo, że możemy słuchać przez wbudowany głośnik. Kabel ze słuchawek robi po prostu za antenę.
  2. Duża wada: telefon nie obsługuje JSR 82, czyli nie dostarcza API Javy dla Bluetooth... Odpada zabawa TrekBuddy i pisanie własnej aplikacji GPS...


wtorek, 6 marca 2012

Stare źródła: Wii Remote jako miecz świetlny ;-)

Grzebiąc w katalogu z różnymi programami, których pisanie kiedyś zacząłem, ale z jakichś powodów nie dokończyłem, znalazłem programik pozwalający poczuć Moc Jedi z wykorzystaniem pilota-kontrolera do konsoli Nintendo Wii (Wii Remote), połączonego z pecetem (linux + Python) poprzez Bluetooth...
Program szalenie prosty, kaleki wręcz, w mocno początkowej fazie "rozwoju", kiedy to starałem się wyczuć i zrozumieć informacje zwracane przez akcelerometr. Pamiętam, że model zdarzeniowy, udostępniany przez cwiid dla Pythona, wyrzucał mi jakieś błędy, zastąpiłem go więc nieskończoną pętlą (tak swoją drogą, makabra).
Cała zabawa polega po prostu na włączeniu ustrojstwa i machaniu :-)

Kod źródłowy poniżej.



Oprócz odpowiednich bibliotek dla Pythona, trzeba również przygotować sobie pliki WAV z dźwiękami miecza (razem 12 - włączenie, buczenie w stanie spoczynku i dziesięć machnięć).

Niech Moc będzie z Wami!