RaspberryPi: pierwsze (moje) próby z zasilaniem bateryjnym.

Jedna z pierwszych myśli, jakie pojawiają się zaraz po zakupie RaspberryPi, to: jak efektywnie zasilić nasze urządzenie z baterii lub akumulatorów? Można wypróbować kilka sposobów – zwykle zaczynamy od regulatora liniowego (scalonego stabilizatora napięcia) 7805 z zestawem czterech kondensatorów (diody nie trzeba) i sześciu paluszków AA (R6 – 1,5V). Jednak to rozwiązanie nie jest zbyt efektywne, a efektywność, rozumiana tutaj jako jak najdłuższy czas pracy bez konieczności wymiany baterii (o stratach energii, zamienionej przez stabilizator na ciepło, nie wspomnę), to zagadnienie dla nas kluczowe.
Można więc, a w zasadzie należy, spróbować techniki impulsowej.
Inspiracją dla moich eksperymentów był artykuł w serwisie – a jakże – majsterkowo.pl, poświęcony akumulatorowej ładowarce do smartfona. Dla własnych potrzeb, a poniekąd też z powodu braku kilku części (mój ulubiony sklep nie był w stanie sprowadzić mi paru ważnych elementów, a ładowarkę potrzebuję na już – z powodu urlopu i wyjazdu ;-)), zmodyfikowałem trochę cały układ.
Najpierw kilka słów o budowie ładowarki/zasilacza. Lista części jest dosyć krótka – potrzebujemy:

• przetwornicę DC/DC 5V o odpowiedniej wydajności prądowej – ja zastosowałem elegancki układzik Pololu S7V8F5, który w trybie step down daje radę wycisnąć do 1A przy sprawności ok. 80%;
• kondensator np. 47μF, wlutowany między wyprowadzenia VIN a GND przetwornicy;
• rezystor podciągający 100kΩ, wlutowany pomiędzy wyprowadzenia VIN a ~SHDN przetwornicy;
• kawałek przedłużacza USB (gniazdo);
• wyłącznik;
• dwa koszyczki na trzy baterie AA (potrzebujemy sześć baterii – napięcie początkowe ok. 9V);
• jakaś obudowa ;-)

Łączymy wszystko zgodnie ze specyfikacją i... już możemy podładowywać sobie telefon...

...oraz podłączyć malinę :-)

Przygotowałem sobie prościutki układ pomiarowy – czyli podłączyłem woltomierz, który podawał mi aktualny odczyt napięcia na bateriach. Baterie co prawda nie były pierwszej świeżości (już raz, dla testów, ładowałem z nich telefon), ale po włączeniu przetwornicy, jeszcze bez obciążenia w postaci maliny, dały 9,12V:

Po włączeniu Raspberry'ego napięcie oczywiście siadło. Na zdjęciu poniżej wynik pomiaru po 21 minutach pracy (czas pracy widoczny na ekranie w tle):

Testowałem malinę przez około pół godziny, lekko ją tylko obciążając aktualizacją oprogramowania i przyznam, że efekt jest umiarkowanie zadowalający. Pod koniec testów napięcie na bateriach spadło do około 7,66V. "Martwić się" powinniśmy dopiero gdzieś w okolicy 6V, czyli za około następne pół godziny, jeśli spadek napięcia postępowałby liniowo.

Czy jest to koniec problemu zasilania bateryjnego maliny? Nie wiem. Zastosowanie baterii alkalicznych zdaje się być rozwiązaniem dosyć drogim. Można ewentualnie pomyśleć o "beczkach" R20, które powinny zapewnić większą wydajność lub wykonać testy na akumulatorach. Idąc dalej, można by przekształcić układ w rodzaj zasilacza bezprzerwowego (UPS) i dodać do systemu maliny kontrolę poziomu napięcia – któryś z blogujących kolegów coś takiego już robił z wykorzystaniem dodatkowych układów i szyny GPIO mailny.

Oczywiście kolejny krok to podłączenie do przetwornicy ogniw słonecznych – mam dwa, kiepskiej jakości, wydłubane ze zużytych lampek ogrodowych, dające w sumie, w maksymalnym słońcu, 4,2V, ale to trochę za mało... Kolega parę dni temu doradził mi, żeby zakupić kilka-kilkanaście lampek solarnych w markecie i wykonać sobie matrycę ogniw – pomyślę, ale już nie w tym sezonie.

Android i zewnętrzny moduł GPS

Od kilku dni jestem w posiadaniu smyrfona z Androidem 4.1.1 na pokładzie. Kwestie związane z wyborem systemu roztrząsałem już na G+, a ten artykuł tutaj ma konkretny temat, więc nie będę wyjaśniał po raz n-ty. Po prostu zwyciężyły popularność i ekosystem oraz przywiązanie do produktów sieciowych Google. Mniejsza.

Zbliża się sezon urlopowy :-) Moi podopieczni już mają wakacje, a ja wyjeżdżam wkrótce. W każdym bądź razie wakacje to podróże - samochodem, rowerem, na piechotę, żaglówką, motorówką, samolotem... Zaawansowane urządzenia mobilne przyzwyczaiły nas już do usług lokalizacyjnych, z których najważniejszą jest GPS (na dalszym planie mamy A-GPS, lokalizacje w oparciu o sieci WiFi itp.). Często korzystamy z programów, które w coraz ciekawszy sposób wiążą naszą lokalizację, pobraną z np. GPS-a, z przeróżnymi danymi, nieraz ocierając się o AR.
Każdy współczesny smartfon, a przynajmniej znakomita ich większość, wyposażona jest we wbudowany odbiornik sygnału lokalizacyjnego (GPS, GLONASS). Czasem jednak korzystanie z wbudowanego odbiornika bywa kłopotliwe, na przykład:

• długo łapie tzw. fix, czyli ustala pozycję; bywa, że trwa to kilka-kilkanaście minut i się nie udaje (mam tak np. w aparacie fotograficznym);
• trzymamy telefon w kieszeni, pod wieloma warstwami ubrań itp. - wszystko to osłabia siłę sygnału GPS;
• każdy wbudowany w telefon dodatkowy ficzer bardzo egoistycznie podchodzi do baterii; odbiornik GPS również ostro drenuje zasoby energii naszego smartfona.

Być może są to wady nieco naciągane - wielu z Was ma całkiem niezłe doświadczenia z wbudowanymi odbiornikami GPS - ale jednak czasem występują. Szczególnie w obszarze zabudowanym ;-)

O ile w pierwszym przypadku wszystko zależy od jakości modułu (i poniekąd od oprogramowania, jak się domyślam), o tyle w drugim jako alternatywa świetnie się może sprawdzić zewnętrzny moduł GPS, z którym nasz telefon może się komunikować przez Bluetooth. Możemy wtedy trzymać telefon w dowolnym, najwygodniejszym dla nas miejscu, a odbiornik GPS tam, gdzie będzie najlepiej łapał sygnał.

W jaki sposób przekonać urządzenie z Androidem do współpracy z zewnętrznym modułem GPS?

Rzecz nie wydaje się być trudną.

Najpierw sparujmy odbiornik GPS z naszym smartfonem czy tabletem - czynność, której chyba nie trzeba szerzej wyjaśniać. Ja posłużę się moim starym, dobrym, wielokrotnie już wspominanym na tym blogu modułem Nokia LD-3W.

Po sparowaniu znajdujemy w menu ustawień Androida Opcje programistyczne. Włączamy je, zgadzamy się na ryzyko (bo system się upewnia) i zaznaczamy opcję Pozorowanie lokalizacji:

Następnie pobieramy i instalujemy aplikację Bluetooth GPS (ze sklepu Google Play). Uruchamiamy, wybieramy nasz moduł GPS (wcześniej sparowany), włączamy go (czasem trzeba najpierw uruchomić aplikację, a potem moduł GPS) i klikamy Połącz (Connect). Czekamy chwilę (dosłownie chwilę - u mnie np. rzecz działa się w budynku, przy zamkniętym oknie - moduł leżał na parapecie) i mamy rezultat:

Teraz rzecz najważniejsza: zaznaczamy Enable Mock GPS Provider. Jeśli wybraliśmy wcześniej pozorowaną lokalizację (w Opcjach programistycznych), to możemy teraz ukryć aplikację i uruchomić cokolwiek, co potrzebuje usług lokalizacyjnych - sprawdzałem z Foursquare, Star Chart i kilku innymi programami. Ważne jest, żeby wyłączyć wszystkie wbudowane usługi lokalizacyjne.

Sam program Bluetooth GPS ma jeszcze kilka ekranów, które mogą zaciekawić bardziej dociekliwych, ot choćby "mapkę" satelitów:

czy pokazywanie naszego położenia na mapie:

a nawet śledzenie logu kolejno przesyłanych linii NMEA ;-)

Okazuje się, że wszystko ładnie działa (no dobra, będę szczery - raz tylko tak namieszałem, że musiałem zrobić reboota ;-))! 

Udanej zabawy zatem i pełnych przygód podróży (z nawigacją w kieszeni ;-)).

Programowanie AVR cz. ostatnia: Wyświetlacz 3D (LED Cube) 4x4x4 - ciekawy wizualnie, modny gadżet z ogromnymi możliwościami.

Pora kończyć cykl wpisów dydaktyczno-eksperymentalnych na temat programowania AVR-ów. Koniec jednak powinien być mocny. No to będzie.

Przed Wami oto:
Wyświetlacz 3D, czyli LED Cube, o rozmiarach 4 x 4 x 4.

000. Pomysł

Kostką diod LED, sterowaną dowolnym mikrokontrolerem, zainteresował mnie parę lat temu jeden z absolwentów. Było to jeszcze w czasie, gdy mój powrót do lutownicy nie był praktycznie brany pod uwagę - zajmowałem się wyłącznie softwarem, a programowania mikrokontrolerów uczyłem z wykorzystaniem gotowych, zamkniętych zestawów (DSM-51 - fajnie pomyślana i zrobiona rzecz, niestety bazująca na lekko przestarzałej i przez wielu krytykowanej technologii). Gdy w zeszłym roku zająłem się AVR-ami pomyślałem sobie - czemu nie? Przejrzałem kilka rozwiązań, przyglądnąłem się możliwościom różnych mikrokontrolerów i... znalazłem coś odpowiedniego dla siebie.
Czym właściwie jest popularny LED Cube, lub też wyświetlacz LED 3D? Otóż jest to eleganckie i efekciarskie urządzonko pozwalające na prezentację kształtów geometrycznych oraz - co najważniejsze - animacji w rzeczywistym 3D. Taką kostkę możemy obejść dookoła i za każdym razem zobaczymy obraz z innej perspektywy. Gdyby zbudować taką kostkę z 8*10^9 diod LED RGB, to mielibyśmy wtedy dopiero prawdziwy obraz trójwymiarowy - i to w dodatku w HD! Problem w tym, że gabaryty byłyby nieco większe, niż w przypadku klasycznego telewizora LCD/OLED/Plasma z czterdziestocalową przekątną ekranu. Ale za to obraz byłby prawdziwie trójwymiarowy, a nie prezentowany w rzucie, jak to ma miejsce w przypadku gier komputerowych czy filmów. W grach, owszem, grafika tworzona jest tak, jakby miała być prezentowana za pomocą prawdziwego ekranu 3D, ale potem wykonywany jest szereg operacji przygotowujących obraz do pokazania na... płaskim ekranie...
Do czego może taki LED-owy wyświetlacz 3D służyć, czy też gdzie znajdzie zastosowanie? Pomijając jego gadżetowość, póki co - choćby ze względu na koszta i gabaryty tych dużych wyświetlaczy (prezentowany tutaj to zabawka w porównaniu z niektórymi super-projektami) - w reklamie, rozrywce, nowoczesnej dekoracji...
Dla mnie osobiście jest to wyłącznie zabawka - ot na przykład do wymyślania kolejnych ciekawych (?) animacji.

Programowanie AVR cz. 10: Modyfikacja mikroprocesorowego sterownika wyświetlacza alfanumerycznego LCD (układ HD44780 lub odpowiednik) z dostępem przez łącze szeregowe (i błędy!)

Błędy zdarzają się nawet w najprostszym kodzie, niestety. Program sterownika do wyświetlacza szeregowego, o którym pisałem jakiś czas temu, też się błędów nie ustrzegł. Przy okazji zmodyfikowałem ten program w celu poprawnej obsługi wyświetlacza 16*2. Dotychczas wykorzystywałem dwa odzyskane ze złomu wyświetlacze jednowierszowe o fizycznej organizacji 16*1, ale logicznie każdy z nich składał się z dwóch wierszy po osiem znaków - stąd konieczność wprowadzenia udziwnionego polecenia mapowanego na bascomowskiego Locate'a i stąd błędy, które się przemknęły podczas testów. Być może wzięło się to z rzadko wykorzystywanego w jednowierszowym wyświetlaczu pozycjonowania tekstu.
W każdym razie, po zmianie wyświetlacza na model o bardziej popularnym formacie prezentacji tekstu, program wymagał kilku przeróbek, dlatego też i błędy zostały wyłapane i poprawione.

Oto poprawiony i zmodyfikowany program (BASCOM):

Warto przetestować ten zmodyfikowany wyświetlacz - szczególnie funkcjonalność, która dotychczas sprawiała problemy, czyli Locate. Poniżej prezentuję listing "latającej małpy" w implementacji na Arduino Leonardo (opis podłączeń w komentarzach). Warto zwrócić uwagę na prostą funkcję locate_xy, która ukrywa przed nami wyliczanie formatu odpowiedniej komendy wysyłanej do sterownika wyświetlacza (opis formatu w prezentowanym wcześniej listingu).

Myślę, że nie od rzeczy będzie, gdy napiszę jakąś prostą bibliotekę (dla Arduino i BASCOM-a) do obsługi wyświetlacza, żeby nie zmuszać użytkownika do niskopoziomowych operacji na łączu szeregowym. Najpierw zadbam o Arduino :-)

(nalepka pochodzi z zestawu dostarczonego w oryginalnym pudełku razem z moim Arduino, nie została tu umieszczona w żadnym konkretnym celu oprócz ozdobnego - zresztą jest to mój prywatny elektroniczny klocek, nie na sprzedaż ;-))

---------------------

Szczegóły na temat projektu szeregowego sterownika wyświetlacza alfanumerycznego dostępne w artykule:

Programowanie AVR cz. 7: Mikroprocesorowy sterownik wyświetlacza alfanumerycznego LCD (układ HD44780 lub odpowiednik) z dostępem przez łącze szeregowe. 

Pilot do lustrzanek Nikona - przeróbka projektu z serwisu Majsterkowo.pl

Jeden z moich ulubionych serwisów (dla którego wyłączam AdBlocka ;-)), czyli majsterkowo.pl, zamieścił na swoich wirtualnych łamach jakiś czas temu artykuł prezentujący projekt pilota do lustrzanek Nikona, wykonany w oparciu o Arduino (http://majsterkowo.pl/elektronika-dla-artystow-czyli-pilot-ir-do-nikona/). Autor tego projektu wykorzystał zapewne opis sekwencji zwalniającej migawkę, umieszczony pod tym adresem: http://www.sbprojects.com/projects/nikon/index.php (reverse engineering rządzi, nie ma co).
W każdym razie artykuł i opis projektu jest świetny i rzeczywiście program bardzo dobrze działa na moim Leonardo. Idąc jednak w kierunku wskazanym przez autora, postanowiłem zaimplementować jego rozwiązanie na czymś prostszym i tańszym. I możliwie mobilnym. Ze względu na szalenie nieskomplikowany charakter programu i małą jego zasobożerność, wybrałem do implementacji malutki mikrokontroler, jeden z moich ulubionych, ATtiny 2313.
Początkowe próby napisania odpowiedniego wsadu w BASCOM-ie, zarówno przy taktowaniu zegarem wewnętrznym 8MHz, jak i z zastosowaniu oscylatora zewnętrznego 16MHz, niewiele dały. Z jednej strony wywołania funkcji (procedur, podprogramów) w BASCOM-ie wprowadziły potężny narzut czasowy, z drugiej strony - po uproszczeniu programu - okazało się, że i tak procesor nie jest w stanie wygenerować odpowiedniej nośnej (czyli o odpowiedniej częstotliwości; nie chodzi bynajmniej o to, że układ nie wyrabia). Jedyną - na pocieszenie - zaletą użycia BASCOM-a było uzyskanie niewielkiego kodu wynikowego w porównaniu do tego, który wygenerował kompilator C...
Właśnie... Postanowiłem wyjątkowo zamienić BASCOM-a na C, przynajmniej dla tego projektu. Szybko się okazało, że elegancki program, w którym w szkolny wręcz sposób powtarzające się fragmenty kodu zostały ubrane w funkcje (prawie jak w oryginale), dał w wyniku kompilacji monstrualnych rozmiarów kod wynikowy. Nawet przy odpowiednio skonfigurowanej optymalizacji. Zminimalizowałem więc liczbę zdefiniowanych funkcji do jednej, resztę kodu umieszczając w funkcji main() - nagle kod wynikowy stał się bez mała dziesięciokrotnie mniejszy... W takiej postaci program oczywiście działa i można nawet pomyśleć o jego rozbudowie, mając jednak na uwadze ciągle skromne zasoby wybranego przeze mnie mikrokontrolera.
Oto więc kod źródłowy programu:



Zamiast schematu, krótki opis połączeń. Otóż zasilamy układ i podłączamy kwarc z kondensatorami według wskazań dokumentacji, dalej do pinu 0 portu B podłączamy przez rezystor ok. 220Ω diodę IR (nadawczą), do pinu 1 tego samego portu dołączamy mikrostyk zwierający do masy i na koniec do pinu 2 - diodę LED, oczywiście przez rezystor również ok. 220Ω.
Wgrywamy program i możemy robić zdjęcia na odległość :)

Ciągle jednak nie daje mi spokoju BASCOM. Muszę znaleźć istotę problemu częstotliwości sygnału nośnego - co prawda funkcje realizujące opóźnienia nie są najszczęśliwszym rozwiązaniem, a jednak avr-gcc daje radę. Ciekawe, w czym tkwi problem? Tym bardziej, że nie przeoczyłem żadnego ważnego elementu związanego z konfiguracją. Być może trzeba będzie odmierzać czas w tym programie za pomocą sprzętowego timera?

A na koniec uwaga: konstruowanie pilota do Nikona z funkcjonalnością li i tylko robienia zdjęcia, pomijając trening umysłu i aspekt ciekawostki, nie ma większego sensu. Zgrabny pilot do lustrzanek Nikona, zasilany bateryjką CR2025, można nabyć za około 15zł (wraz z kosztem wysyłki). Warto więc dodać kilka ekstra ficzerów - do czego zresztą zachęcał autor oryginalnego artykułu.

Arduino i wyświetlacz LCD sterowany przez UART

Być może niektórzy z Was pamiętają mój moduł wyświetlacza sterowany przez port szeregowy. Fajna rzecz - jeśli wolno mi się w ten sposób pochwalić - pozwalająca ocalić cenne wyprowadzenia mikrokontrolera od "zajęcia" przez sterownik wyświetlacza zgodny z HD44780 i wysyłać dane do prezentacji na ekraniku LCD przez zaledwie dwie linie (w tym tylko jedno wyprowadzenie mikrokontrolera - TxD; druga linia to masa).
Odchodząc na chwilę od Noduino (choć właściwie można by pokombinować z wyświetlaczem i w tym kierunku - o ile Noduino na to pozwoli) postanowiłem sprawdzić, jak Leonardo poradzi sobie z moim wyświetlaczem. W tym celu pozwoliłem sobie zmodyfikować jeden z załączonych do IDE Arduino programów przykładowych i przygotować małe demko, którego kod źródłowy prezentuję poniżej:


Zadaniem programu jest wyświetlanie kolejnych znaków ze zbioru podstawowego ASCII oraz ich kodów w systemie dziesiętnym, szesnastkowym i binarnym. Kod odrobinę udziwniony, ponieważ musiałem go dostosować do posiadanego wyświetlacza alfanumerycznego - jeden wiersz, szesnaście znaków, ale w logicznym podziale na dwa wiersze po osiem...

Projekcik oczywiście elegancko zadziałał, z czego wnioskuję, że mój moduł wyświetlacza z łączem UART jest zgodny z platformą Arduino :-)

Arduino ready ;D

Arduino Leonardo i Noduino - kilka poprawek w kodzie i wszystko pięknie działa.

Tak, wbrew deklaracjom zaopatrzyłem się jednak w płytkę prototypową Arduino - wybór padł na wersję Leonardo z ATmegą 32u4 na pokładzie i wysokim profilem (czyli z wlutowanymi złączami).
Pierwszą rzeczą, jaką zrobiłem, było oczywiście podłączenie urządzonka do peceta i sprawdzenie, czy działa - program testowy, domyślnie wgrany do Leonarda, zaczął elegancko zaśmiecać bufor portu szeregowego. Czyli wszystko OK. Potem odbyła się próba migania dostępną na płytce diodą LED - również bez problemów. Można więc zaczynać zabawę.
Mimo zakupu Arduino nadal twierdzę - żeby nie było nieporozumień - że umiejętność wykorzystywania w projektach "czystych" mikrokontrolerów daje dużo więcej możliwości, wspartych i ograniczonych jedynie naszą kreatywnością. Problem może wystąpić tylko w przypadku, gdy brakuje gotowych bibliotek (dla C czy BASCOMa) do obsługi konkretnych układów (np. wyświetlaczy) lub dostarczających określonych, "wysokopoziomowych" funkcjonalności. Pod tym względem właśnie Arduino jest lepiej wyposażoną i ciągle prężnie rozwijaną platformą.
Jedną z ciekawostek, którą miałem zamiar wypróbować, jak tylko któreś Arduino (lub jego klon) wpadnie mi w ręce (początkowo chciałem zmontować samodzielnie takiego klona, ale średnio by się to opłaciło - zarówno czasowo, jak i finansowo), jest projekt Noduino, pozwalający na sterowanie płytką prototypową, podłączoną do komputera przez łącze USB, za pomocą przeglądarki WWW i protokołu HTTP. No, może nie tak patetycznie - po prostu jest to interaktywny interfejs webowy dla Arduino.
Jeśli chodzi o instalację Noduino, postępujemy zgodnie z opisem na stronie http://semu.github.io/noduino/ (czasem nie działa, więc zajrzyjmy do pliku https://github.com/semu/noduino/blob/master/examples.snippet).
Z instalacją nie ma problemu (pamiętajmy o załadowaniu wsadu do Arduino - znajdziemy go w pliku https://github.com/semu/duino/blob/master/src/du.ino, oczywiście jeśli wszystko zainstalujemy zgodnie ze wskazówkami na stronie, to plik mamy dostępny lokalnie), jednak w przypadku mojego komputera (płytki Arduino?) i posiadanej wersji Node.js musiałem do kodu Noduino wrzucić kilka poprawek.
Przede wszystkim mój egzemplarz Arduino widoczny jest w systemie jako urządzenie

/dev/ttyACM0

dlatego też w pliku https://github.com/semu/duino/blob/master/lib/board.js (lokalnie: /[katalog_nadrzędny]/noduino/duino/lib/board.js) musiałem zmienić linijkę 80:

child.exec('ls /dev | grep usb', function(err, stdout, stderr){

na

child.exec('ls /dev | grep ttyACM', function(err, stdout, stderr){

oraz w pliku https://github.com/semu/noduino/blob/master/srv.web.js (lokalnie: srv.web.js w katalogu głównym Noduino) linijkę 17:

console.log("Listening on http://%s:%d", kickstart.conf().name, router.address().port);

na

console.log("Listening on http://localhost:8080");

Ostatnia zmiana dotyczyła błędu, z którym wyskakiwał Node.js przy próbie wykonania tego kodu - nie wnikałem w szczegóły ze względu na czysto kosmetyczne znaczenie tej linijki (może jej w ogóle nie być).

Po tych zmianach Leonardo elegancko zaczął współpracować z przeglądarką, będzie więc trochę inna zabawa, niż w przypadku moich elektronicznych, AVR-owskich kocków wspieranych BASCOMem.

A czy warto inwestować siły i środki w Noduino? Nie wiem, przekonam się. I coś oczywiście o tym napiszę.

Midnight hacking, czyli jak z powrotem udźwiękowić pewne rozszerzenie do Chromium.

Zapewne wielu użytkowników Google+ i przeglądarki Chrome/Chromium ma zainstalowany dodatek Replies and more for Google+.
Jedną z ciekawszych moim zdaniem funkcjonalności jest wizualne i dźwiękowe powiadamianie o hm... powiadomieniu G+:

Okazało się, że gdy zmigrowałem z Chrome do Chromium (ponieważ Chrome już mi wyświetla komunikat o zakończeniu publikowania aktualizacji dla mojej wersji ubunciaka - owszem, muszę zaktualizować system do kolejnego LTS-a, ale chwilowo nie dysponuję wolnym czasem, a tego typu komunikaty mnie denerwują) wspomniany plugin przestał dźwięczeć...
Wystarczyła jednak poprawka w pliku:
~/.config/chromium/Default/Extensions/<identyfikator rozszerzenia Replies and more for Google+>/<numer wersji>/background.js
gdzie wiersz:
        audio.src = chrome.extension.getURL("chime.mp3");
zamieniłem na:
        audio.src = chrome.extension.getURL("chime.ogg");
i wszystko wróciło do normy, czyli powiadomienia wyskakiwały z dźwiękiem.
Autor rozszerzenia oczywiście dostarczył zarówno plik mp3, jak i ogg.
Być może (nie sprawdzałem) podmianka potrzebna tylko wtedy, gdy mamy zainstalowany pakiet chromium-codecs-ffmpeg (tzw. wolne kodeki dla znaczników <audio> i <video> HTML5). Jeśli tak, to w celu uniknięcia grzebania w kodzie rozszerzenia wystarczy zainstalować pakiet chromium-codecs-ffmpeg-extra, który dostarcza komponenty wspierające "zamknięte" formaty.

Programowanie AVR cz. 9: Mierzymy temperaturę.

Co prawda w zamierzeniu miał to być obszerny artykuł na temat pomiaru temperatury przez układ mikroprocesorowy na bazie ATmegi 48P, ale po dłuższych przemyśleniach doszedłem do wniosku, że o wiele lepiej będzie po prostu pokazać schemat układu i listingi programów, z niewielkim, niezbędnym komentarzem.

Mając do dyspozycji mikrokontroler ATmega 48P możemy zbudować prostu termometr na co najmniej dwa sposoby. Pierwszy z nich może się opierać na odczytywaniu temperatury z wewnętrznego sensora, jednak aby uzyskać w miarę zadowalające wyniki, należy przeprowadzić kalibrację - szczegóły znajdziecie w specjalnie tej tematyce poświęconym dokumencie, dostępnym na stronach firmy Atmel.
Poniższy listing pokazuje, jak możemy wykorzystać wewnętrzny sensor (wyniki wyświetlane są na "szeregowym" LCD mojej produkcji):

Kalibracji dokonałem z grubsza, nie dysponując ani możliwością uzyskania znacznej różnicy temperatur, ani też dobrym termometrem wzorcowym. Zauważmy, że z wbudowanym czujnikiem temperatury komunikujemy się w taki sam sposób, jak z przetwornikiem analogowo-cyfrowym; jest to jakby dodatkowy kanał ADC.

Drugi sposób, o wiele ciekawszy, polega na wykorzystaniu zewnętrznego, scalonego czujnika temperatury. Na rynku znajdziemy wiele tego typu układów - najciekawsze z nich to układy, z którymi mikrokontrolery komunikują się za pomocą magistral I2C czy 1Wire, jednak w moim termometrze zastosowałem układ scalony analogowy LM35DZ. Ta wersja pozwala na pomiar temperatur w zakresie od 0 do 100 st. C, czyli nadaje się doskonale do zastosowań typu indoor. Wartość napięcia, na którą układ konwertuje temperaturę otoczenia (właściwie jest to temperatura jego obudowy), przetwarzana jest przez przetwornik analogowo-cyfrowy mikrokontrolera i prezentowana przez szesnaście diod LED, przy czym dla zbyt niskich i zbyt wysokich temperatur przewidziana jest specjalna sygnalizacja - osobne, pulsujące LED-y (PWM). Dodatkowo wyniki pomiarów można śledzić na opcjonalnym LCD.
Diody LED są sterowane za pomocą dwóch ekspanderów magistrali I2C (PCF8574P), dzięki czemu obsługa wyświetlania wyników realizowana jest przez dwa wyprowadzenia mikrokontrolera (stały problem: jak rozszerzyć liczbę wejść/wyjść mikrokontrolerów).
Oto schemat układu:

i listing programu:

Schemat, dla poprawy czytelności, nie zawiera wartości zastosowanych elementów biernych, oto więc spis:

• C1, C2: 22pF - 33pF
• C3, C4, C5: 100nF
• C6: 10μF
• L1: 10μH
• R1 - R18: 220Ω
• R19: 10kΩ
• R20, R21: 330Ω
• R22, R23: 4,7kΩ
• LED1 - LED18: zestaw dowolnych diod elektroluminescencyjnych

Przedstawione rozwiązanie z wielu względów nie jest optymalne - jakoś szczególnie go nie dopracowywałem - weźmy choćby pobór prądu przez szesnaście święcących diod...
Jednak efekt ciekawy, szczególnie, gdy dobierzemy różnokolorowe diody dla poszczególnych przedziałów temperatur.

RaspberryPi: kwestia zasilacza.

Przypuszczam, zresztą chyba dość trafnie, że znakomita większość z nas, użytkowników RaspberryPi, zasila swoje urządzonka z prostych zasilaczy impulsowych (przetwornic, jak kto woli), dostępnych za kilkanaście do kilkudziesięciu złotych w marketach czy serwisach aukcyjnych. Albo kupionych wcześniej, jako element wyposażenia innych urządzeń - tak jest np. w moim przypadku, kiedy zauważyłem, że do zasilania RPi doskonale się nada ładowarka do czytnika.
Urządzenia te spełniają najczęściej podstawowe założenia dotyczące wydajności pożądanej przez RPi (napięcie 5V, pobór prądu około 750mA) - tabliczki znamionowe jak jeden mąż mówią, że będzie na wyjściu 5V z maksymalną wydajnością prądową do 1A. I zwykle dają radę. Ja jednak dawno, dawno temu straszyłem, że sam sobie zrobię zasilacz do maliny. I owszem, zrobiłem, ale z wyżej wymienionego powodu zmienił się target - układ został zaadaptowany do zasilania moich prototypów i eksperymentów mikroprocesorowych. Oprócz 5V daje też 3,3V (bo miałem kiedyś zamiar pobawić się wyświetlaczami graficznymi wydłubanymi ze starych komórek :)), ma wydajność do 1A (dla wyjścia 3.3V jest to 800mA przy założeniu, że nie korzystamy jednocześnie ze źródła napięcia 5V), można go zasilać z dowolnego zasilacza zewnętrznego dającego napięcie do 12V (choć wytrzymał też 14V; szybko natomiast można się przekonać, że tzw. zasilacze uniwersalne typu bazarowego, z regulowaną wartością napięcia wyjściowego, mają dość ostre przekłamania w tabliczkach znamionowych...), posiada zabezpieczenie przed zmianą polaryzacji zasilacza zewnętrznego i gustowną lampkę sygnalizującą działanie. Całość, zgodnie z wytycznymi geekowskiego stylu, przymocowana do stabilnej podstawki, ale bez obudowy.
Jednej rzeczy wszak zapomniałem - otóż scalone stabilizatory napięcia (tzw. regulatory napięcia) bardzo łatwo i szybko się pocą, szczególnie, gdy dużo od nich wymagamy... Nie popełniłem radiatora! Gdy podłączyłem do tego zasilacza malinę, myślałem, że 7805 po prostu spłynie z płytki...
Dziś nadrobiłem zaległości - stabilizator 7805 otrzymał elegancko wymodelowany radiator wielowarstwowy z puszki po piwie (bezalkoholowym, serio!), a cały układ znalazł się w zasięgu wiatraczka odzyskanego ze starego komputera (znalazłem w szafce radiator z coolerem - po rozmiarach wnioskuję, że z 486 :)). Innymi słowy mam teraz full-wypas zasilacz laboratoryjny, któremu nie straszne jest wpuszczanie w maliny ;)
Przy okazji znalazłem całkiem wydajny zasilacz 9V/1A ze starego routera - sprawdza się świetnie, nie "siada" przy obciążeniu np. maliną.
Dlaczego piszę o zasilaczu ciągłym własnej produkcji, podczas gdy impulsowe, dostępne w markecie, są tanie i jakby co, to można zrobić sobie zapas? Otóż dużo większe zaufanie mam do własnej produkcji zasilacza, nawet jeśli nie jest to lekki układ impulsowy. Miałem okazję spalić kiedyś takiego impulsaka - to, co zobaczyłem w środku, daje do myślenia :) Czasem po prostu szkoda nawet maliny.

Gwoli ścisłości - nie mam nic przeciwko technice impulsowej. Po prostu zasilacze marketowe są podłej jakości.

RaspberryPi: serwer wydruku.

I to by było na tyle - więcej pisać nie trzeba, bo też i filozofii specjalnie w tym nie ma... Ale jakby ktoś potrzebował, służę uprzejmie.

Od jakiegoś czasu zastanawiam się nad zakupem serwera wydruku, nawet mógłby pracować z drukarką wyposażoną w łącze równoległe (moja akurat ma i USB i Centronicsa), niestety ciągle blokuje mnie cena - jak na niewielki stopień komplikacji i niezbyt zaawansowaną technologię ciągle za wysoka, nawet w przypadku printserverów LAN-owskich. Wczoraj, grzebiąc bezmyślnie w internetach, natknąłem się na artykuł poświęcony malinie i gdzieś na początku przeczytałem, że ludzie robią z RaspberryPi przeróżne ustrojstwa, w tym centra multimedialne, serwery wydruku... I tu dostałem nagłej eureki... Przecież malina u mnie się ostatnio nudzi, a drukarkę udostępniam laptopowi żony przez komputer stacjonarny, który musi być włączony itd., a jest to - jak na porządną stacjonarkę przystało - kobyła i bomba energetyczna... A RaspberryPi, zasilany z zasilacza impulsowego, żrącego niewiele energii, sprawdziłby się w roli serwera wydruku wręcz doskonale.
Oto, co zrobiłem.
Na początku zaktualizowałem Raspbiana:

sudo apt-get update 
sudo apt-get upgrade

następnie zainstalowałem pakiet oprogramowania CUPS:

sudo apt-get install cups

Razem z pakietem zasadniczym pociągnęło się oczywiście wiele innych, potrzebnych i szalenie ważnych. CUPS to oprogramowanie dostarczające systemom uniksowym funkcjonalność drukowania, współdzielenia i udostępniania drukarek w sieci. Dodatkowo mamy możliwość administrowania drukarkami czy kolejką wydruku przez przeglądarkę WWW. Aż dziw bierze, że takie cudo tworzy głównie firma ogrodnicza...

Po zainstalowaniu pakietu trzeba jeszcze, dla wygody, dodać swojego usera do grupy administratorów wydruku:

sudo usermod -a -G lpadmin nazwa_użytkownika

i - żeby dać sobie możliwość zarządzania drukarkami z innych komputerów w sieci (przez przeglądarkę właśnie), należy nieco zmienić plik konfiguracyjny /etc/cups/cupsd.conf. Mój plik konfiguracyjny na malinie wygląda tak (pogrubiłem linie dopisane lub zmienione przeze mnie):

#
# "$Id: cupsd.conf.in 9407 2010-12-09 21:24:51Z mike $"
#
# Sample configuration file for the CUPS scheduler.  See "man cupsd.conf" for a
# complete description of this file.
#

# Log general information in error_log - change "warn" to "debug"
# for troubleshooting...
LogLevel warn

# Deactivate CUPS' internal logrotating, as we provide a better one, especially
# LogLevel debug2 gets usable now
MaxLogSize 0

# Only listen for connections from the local machine.
Port 631
#Listen localhost:631
Listen /var/run/cups/cups.sock

# Show shared printers on the local network.
Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseLocalProtocols CUPS dnssd

# Default authentication type, when authentication is required...
DefaultAuthType Basic

# Web interface setting...
WebInterface Yes

# Restrict access to the server...

  Order allow,deny
  Allow all

# Restrict access to the admin pages...

  Order allow,deny
  Allow all

# Restrict access to configuration files...

  AuthType Default
  Require user @SYSTEM
  Order allow,deny
  Allow all

# Set the default printer/job policies...

  # Job/subscription privacy...
  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default

  # Job-related operations must be done by the owner or an administrator...
 
    Order deny,allow

    Require user @OWNER @SYSTEM
    Order deny,allow

  # All administration operations require an administrator to authenticate...
 
    AuthType Default
    Require user @SYSTEM
    Order deny,allow

  # All printer operations require a printer operator to authenticate...
 
    AuthType Default
    Require user @SYSTEM
    Order deny,allow

  # Only the owner or an administrator can cancel or authenticate a job...
 
    Require user @OWNER @SYSTEM
    Order deny,allow
 
    Order deny,allow

# Set the authenticated printer/job policies...

  # Job/subscription privacy...
  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default

  # Job-related operations must be done by the owner or an administrator...
 
    AuthType Default
    Order deny,allow
 
    AuthType Default
    Require user @OWNER @SYSTEM
    Order deny,allow

  # All administration operations require an administrator to authenticate...
 
    AuthType Default
    Require user @SYSTEM
    Order deny,allow

  # All printer operations require a printer operator to authenticate...
 
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
 
  # Only the owner or an administrator can cancel or authenticate a job...
 
    AuthType Default
    Require user @OWNER @SYSTEM
    Order deny,allow
 
    Order deny,allow
 
#
# End of "$Id: cupsd.conf.in 9407 2010-12-09 21:24:51Z mike $".
#

W repozytoriach Raspbiana znajduje się wersja 1.5.3 pakietu CUPS (to dla jasności, gdyby były jakieś niezgodności co do zawartości pliku konfiguracyjnego). Załączyłem plik w całości, żeby można było go sobie po prostu skopiować i wkleić, bez grzebania i dopisywania.

Po zmianie pliku konfiguracyjnego przestrzeliwujemy usługę:

sudo service cups restart

i z poziomu przeglądarki wchodzimy na adres:

http://adres_ip_mailny:631

Interfejs jest szalenie prosty i intuicyjny, więc zakładam, że każdy poradzi sobie ze skonfigurowaniem swojej drukarki - jednak przed tą czynnością należy drukarkę podłączyć do RPi i włączyć jej zasilanie :). CUPS znajdzie zapewne kilka różnych drukarek (to ze względu na zainstalowane sterowniki), jednak wybrać musimy tę fizyczną, przez nas posiadaną - to oczywiste.
Po skonfigurowaniu drukarki jako współdzielonej i udostępnianej, możemy na dowolnej platformie systemowej (Linux, Windows, MacOS itp.) wybrać/dodać sobie serwowaną przez malinę drukarkę sieciową, używając adresu:

http://adres_ip_maliny:631/printers/nazwa_drukarki

np. w moim przypadku wygląda to tak:

http://192.168.1.2:631/printers/Samsung_ML-2010

I to wszystko! Sprawdźmy jeszcze - choćby za pomocą rcconf - czy CUPS jest uruchamiany automatycznie z systemem i serwer wydruku gotowy.
Rozwiązanie działa niezależnie od tego, czy używamy sieci LAN, czy WiFi.

RaspberryPi: odbiór informacji lokalizacyjnych oraz aktualnego czasu z modułu bezprzewodowego GPS (Bluetooth).

Kolega na swoim blogu wspomniał parę dni temu o synchronizacji zegara RaspberryPi z sygnałem czasu przekazywanym przez satelity systemu GPS (http://guzik.net.pl/blog/2013/03/mobilne-raspberry-pi/). Wystarczyło :-)
Bawiąc się "Mailną" zapomniałem (no jak mogłem???) właśnie przekształcić ją w komputerek-nawigację, choć może to zbyt mocne określenie. Chodzi o to, żeby RaspberryPi przekonać do współpracy z bezprzewodowym modułem GPS Nokia LD-3W. Z takiej współpracy mogą wyniknąć dwie korzyści (co najmniej):

• ciągle aktualizowany odczyt informacji o lokalizacji;
• synchronizacja zegara "Maliny" z czasem satelitarnym (poprzez ntp; RaspberryPi nie ma RTC z podtrzymaniem bateryjnym - jeśli ktoś chce, to kolega, będący autorem linkowanego wyżej bloga, opisał pokrótce, jak dodać taki sprzętowy zegar).

Mając współrzędne i masę innych, ciekawych informacji dotyczących położenia, puszczając wodze fantazji i dodając odrobinę kreatywności, można wręcz stworzyć sobie całkiem niezły komputer nawigacyjny (tym razem już nie przesadzam!). Kto wie, być może spróbuję podziałać w tym kierunku?

W każdym razie musimy zacząć od zgrania ze sobą RaspberryPi i LD-3W. Przede wszystkim musimy - oprócz modułu GPS - zaopatrzyć się w jakiś w miarę dobry "dongiel" Bluetooth na USB. Dlaczego ważna jest jakość i jak ją ocenić... Może po prostu zasugerujmy się źródłem (miejscem zakupu) i ceną. Problem jest właśnie w tym, że wiele modułów Bluetooth niezbyt jest elastycznych jeśli chodzi o pracę w dosyć skomplikowanych warunkach (bo będziemy czytać dane o lokalizacji i informacje o czasie, a to dla jednego z moich dongli, aukcyjnego, za parę złotych nabytego, okazało się ponad jego siły).

Dongla podłączamy do uruchomionej wcześniej "Mailny", mając na pokładzie jak najświeższą wersję Raspbiana. Najpierw sprawdzamy jednak, czy został zauważony przez system. Powinniśmy zobaczyć na liście nasze urządzenie - oczywiście rozpoznamy je po nazwie i z ogromną przyjemnością zauważymy informacje o trybie HCI:

Teraz musimy Raspbiana zaopatrzyć w oprogramowanie, które będzie nam niezbędnie potrzebne. O ile pakiet ntp jest najprawdopodobniej zainstalowany, to o resztę musimy zadbać sami. Doinstalujmy więc bluez (i pewnie od razu otrzymamy informację, że cała reszta narzędzi do obsługi Bluetooth zostanie dołożona; jeśli nie, to oczywiście wyszukujemy w np. aptitude wszystkie niezbędne składniki i doinstalowujemy), gpsd, gpsd-clients i python-gps (reszta pójdzie z automatu).

Mając wszystkie komponenty programowe w gotowości, zaczynamy właściwą zabawę. W sumie nie ma się co tutaj rozwodzić, ot po prostu:

1. Sprawdzamy adres MAC naszego urządzenia:
   
   hcitool dev
   
   
2. Wyszukujemy moduł GPS (musimy go włączyć i umieścić w zasięgu "Maliny", czyli maksymalnie do 10 metrów):
   
   hcitool scan
   
   
3. Komenda z punktu 2. poda nam też nazwę urządzenia, więc bez problemu rozpoznamy nasz moduł GPS spośród wielu pozostających w zasięgu urządzeń. Mając adres MAC modułu GPS możemy sprawdzić, jakie usługi udostępnia, przede wszystkim zaś sprawdzić port BT, na którym moduł udostępnia łącze szeregowe (klasyczny RS):
   
   sdptool browse 11:22:33:44:55:66
   
   gdzie 11:22:itd. to adres MAC GPS-a.
   Niestety, w przypadku mojego modułu LD-3W komenda ta nie zwróciła żadnej informacji, dlatego też przyjąłem, że łącze szeregowe jest dostępne na porcie 1 (ok, wziąłem to z doświadczenia, które zdobyłem bawiąc się pisaniem programu pokazującego moje położenie na mapie...).
4. Numer portu, jak również adres MAC i nazwa modułu przydadzą się nam podczas edycji pliku
   
   /etc/bluetooth/rfcomm.conf
   
   - musimy też zdecydować, czy port szeregowy dla urządzenia BT będzie tworzony manualnie, czy też automatycznie przy starcie systemu.
   Nie podaję tutaj przykładu konfiguracji - plik ten zawiera domyślne wartości z obszernymi wyjaśnieniami; wystarczy dosłownie wpisać w odpowiednie miejsca trzy wspomniane rzeczy, żeby wszystko elegancko hulało.
5. Teraz rzecz chyba najważniejsza, czyli sparowanie ze sobą "Maliny" i modułu GPS. Po wpisaniu tych komend (tutaj trzeba sobie podwyższyć uprawnienia jeśli nie pracujemy na koncie roota):
   
   bluez-test-adapter discoverable on
   bluez-simple-agent hci0 11:22:33:44:55:66
   
   najpierw uczynimy naszą "Malinę" widoczną w przestrzeni Bluetooth, a następnie zostaniemy poproszeni o podanie PIN-u w celu uzyskania dostępu do modułu GPS. W przypadku mojej Nokii są to cztery zera, ale bywa różnie (RTFM!!!).
   11:22:itd. - to adres MAC modułu.
   Pamiętać należy, że po zmianie dongla Bluetooth, parowanie trzeba powtórzyć.
6. Tworzymy port szeregowy do komunikacji z modułem:
   
   rfcomm bind rfcomm0
   
   
7. ...i jeśli nic dziwnego się nam nie przytrafiło, to za pomocą klasycznej komendy testującej:
   
   cat /dev/rfcomm0
   
   możemy już pobierać dane z GPS w formacie NMEA (czyli średnio dla nas czytelne).
8. Za pomocą polecenia:
   
   dpkg-reconfigure gpsd
   
   konfigurujemy demona gpsd, podając mu wspomniany w pkt. 7. port szeregowy jako źródło danych GPS oraz - dla potrzeb ntp - ekstra parametr "-n"; reszta propozycji konfiguracyjnych kreatora zostaje bez zmian.
9. Zaglądając w manuala gpsd:
   
   man gpsd
   
   dowiadujemy się, jaki linie dopisać do pliku:
   
   /etc/ntp.conf
   
   
10. Po tych zmianach przestrzeliwujemy demona gpsd, a następnie ntp. 

Wszystko powinno zacząć pięknie działać - czyli odczyty czasu:

oraz współrzędnych (i wielu innych, ciekawych informacji) - tutaj efekt komendy cgps -s:

Podsumowując zatem...

Okazuje się, że pogodzenie ze sobą RaspberryPi i bezprzewodowego modułu GPS nie jest specjalnie ciężkim wyzwaniem. Jak wspomniałem na wstępie, warto zainwestować w dobrej jakości dongla GPS.
Niestety, jest jeszcze jedna strona medalu... Otóż wszystko pięknie działa, jednak próba rebootowania "Maliny", czy wyłączenia, kończy się efektem "kernel panic" powodowanym przez podsystem Bluetooth (trzeba restartować wyłączając zasilanie - może da się z klawiatury, ale ja pracuję via ssh). Zresztą podobny efekt uzyskać można wyciągając dongla BT z gniazdka USB. Być może jest to problem używanych przeze mnie dongli (trzy różne egzemplarze, tylko przy jednym - tym dziadowskim - kilka razy mi się system nie sypnął), a być może kwestia zasilania urządzeń USB przez "Malinę", albo problem jądra systemu. W każdym razie da się to obejść ubijając ręcznie, przed restartem lub zatrzymaniem systemu, po kolei ntp, gpsd i bluetooth.

Zachęcam do eksperymentów i dzielenia się doświadczeniami :)

A, i jeszcze jedno: proszę pamiętać, że Bluetooth to "blutuf", nie "blutacz" ;D

[Rozwiązanie] Samsung GT-C3322: "błąd logowania" i "błąd sieci" podczas próby skorzystania z wbudowanego klienta Twittera (i zapewne też Facebooka).

Parę miesięcy po zakupie telefonu Samsung GT-C3322 (czytaj o moich spostrzeżeniach z pierwszego dnia użytkowania), świetnie działająca dotychczas natywna (wbudowana) aplikacja kliencka Twittera nagle zaczęła - podczas próby zalogowania się w serwisie - wyrzucać komunikaty "Błąd logowania" i "Błąd sieci"... Po kilku godzinach prób z różnymi konfiguracjami, mieszaniem w koncie na Twitterze, zrobieniu sobie przerwy i zalogowaniu się (nieudanym oczywiście) po kilku dniach, w końcu dałem sobie spokój - i tak bez większych problemów używałem Twittera przez przeglądarkę (Opera Mini). Jednak co jakiś czas, łudząc się nadzieją, że coś się naprawiło, próbowałem się zalogować... Tiaaa...
Przedwczoraj jednak stwierdziłem, że nie może tak być, że telefon ma jakąś funkcjonalność, którą z przyjemnością bym wykorzystał, a ona jak na złość nie działa. Kombinowałem nawet, czy przypadkiem ekipa Twittera nie namieszała znowu w API, albo czy nie pomogłaby aktualizacja oprogramowania telefonu. Z tej ostatniej opcji nic nie wyszło, bo Samsung nie przygotował (jeszcze?) aktualizacji softu.
Koniec końców napisałem maila do supportu i konsultant doradził mi... zrobić twardy reset telefonu polecaniem/kodem:

*2767*3855#

Cóż, okazało się, że jest to właściwe rozwiązanie :)
Zanim jednak ktoś z Was spróbuje zadziałać w ten sposób, proponuję wykonać kopię bezpieczeństwa danych zapisanych w pamięci wewnętrznej telefonu (kontakty przede wszystkim!!!) - wystarczy użyć opcji Backup dostępnej w ustawieniach telefonu, a potem, przed resetem, usunąć z telefonu kartę pamięci. Wiem, że niby nic się nie powinno przydarzyć, ale czasem warto dmuchać na zimne.
Po resecie przywracamy sobie wszystko, synchronizujemy kalendarz (chyba, że używamy tylko lokalnego - to wtedy odtwarzamy z backupu), doinstalowujemy usunięte apki, konfigurujemy telefon - i już!

Z tego, co wiem, podobny problem mają użytkownicy Facebooka. Zdaje się, że "moje" rozwiązanie powinno pomóc i w tym przypadku.

Programowanie AVR cz.8: Przetwornik analogowo-cyfrowy oraz modulacja szerokości impulsu.

Dziś kolejny wgląd w wyposażenie mikrokontrolera ATmega48P - tym razem przyglądamy się wbudowanemu w układ przetwornikowi analogowo-cyfrowemu oraz - dostępnej również w modelach ATtiny - modulacji szerokości impulsu realizowanej przez timery.

Artykuł ten jest w pewnym sensie wstępem do następnego, który pojawi się już wkrótce, a którego tematykę zdradziłem na końcu.

Przetwornik A-C (skrót spotykany w anglojęzycznej literaturze to ADC od Analog to Digital Converter) to układ pozwalający na zamianę wartości napięcia (elektrycznego sygnału analogowego ;-)) na liczbę. W przypadku mojej ATmegi przetwornik ma rozdzielczość 10-bitową, co oznacza, że wartość napięcia podawanego na wejście przetwornika może być po konwersji zapisana jako liczba z przedziału od 0 do 1023 (musimy użyć zmiennej word do zapamiętania tej liczby). Jeśli jesteśmy w posiadaniu mikrokontrolera w obudowie PDIP 28-wyprowadzeniowej, to mamy do dyspozycji sześć kanałów (niezależnych wejść) przetwornika A-C, przyporządkowanych wyprowadzeniom od 23 do 28. W sumie wszystkich kanałów jest osiem plus jeden dodatkowy, o którego przeznaczeniu napiszę w następnym artykule. Kwestie zasilania układu podczas korzystania z ADC przedstawiłem krótko na końcu posta.

Obsługa przetwornika analogowo-cyfrowego w BASCOMie wymaga wstępnej konfiguracji, podczas której ustawiamy m. in. tryb działania przetwornika (ciągły lub "na żądanie") oraz wartość napięcia odniesienia (najczęściej wartość doprowadzona do wyprowadzenia AVCC układu lub wewnętrzna wartość domyślna 1,1V). Szczegóły znajdziecie na stronie pomocy BASCOMa. Przykład konfiguracji (patrz: listing):

' Konfiguracja przetwornika analogowo-cyfrowego; napięcie odniesienia ustalone na 5V 
' (patrz: wyprowadzenie AVCC mikrokontrolera), czyli przedział od 0 do około 5V będzie 
' "rzutowany" na 10-bitową liczbę (od 0 do 1023). 
Config Adc = Single , Prescaler = Auto , Reference = Avcc 

Pojedyncze odczyty wykonywane są (w trybie "single") za pomocą funkcji getadc, która jako parametr przyjmuje numer kanału (w przypadku kanałów dostępnych fizycznie jest to liczba z przedziału od 0 do 5). Musimy pamiętać, że konwersja sygnału analogowego na cyfrowy wymaga czasu, dlatego też żeby otrzymać wiarygodne odczyty, należy unikać "lawinowego" wywoływania funkcji getadc. Wywołanie funkcji getadc w znakomitej większości przypadków sprowadza się do podania jako parametru numeru kanału przetwornika i zapamiętania wyniku w zmiennej typu word:

Dim Odczyt_0 As Word 
... 
Odczyt_0 = Getadc(0) 

Zawartość zmiennej Odczyt_0 możemy teraz swobodnie interpretować.

Kolejny opisywany dziś element wyposażenia ATmegi to generator PWM (ang. Pulse Width Modulation). Modulacja szerokości impulsu realizowana jest przez każdy z trzech timerów, jednak trzeba pamiętać, że tylko jeden z nich (timer1) jest 16-bitowy - pozostałe dwa to liczniki/timery 8-bitowe.
Jeśli chodzi o istotę zjawiska, modulacja szerokości impulsu to nic innego jak zmiana współczynnika wypełnienia dla fali prostokątnej o określonej częstotliwości.

Konfigurując timer jako generator PWM musimy ustalić, z jaką częstotliwością mają być generowane impulsy, jaki ma być zakres licznika (8, 9 czy 10 bitów; dotyczy tylko timera 16-bitowego - w przypadku liczników 8-bitowych nie ma możliwości zmiany zakresu) i czy rejestr porównania (przedstawiony w dalszym ciągu artykułu) ma decydować o szerokości (czasie trwania) logicznego zera bądź jedynki logicznej.

Przykład konfiguracji ośmiobitowego timera jako generatora PWM (szczegóły znajdziecie w dokumentacji BASCOMa - Timer0 i Timer1):

' Timer0 pracujący z największą szybkością w trybie PWM; porównywanie wartości timera 
' w systemie "clear up" spowoduje zwiększanie szerokości impulsu wraz ze wzrostem wartości zmiennych 
' PWM0A i PWM0B (patrz dalej). 
Config Timer0 = Pwm , Prescale = 1 , Compare A Pwm = Clear Up , Compare B Pwm = Clear Up 

W dalszej części artykułu skupimy się właśnie na 8-bitowym timerze 0.

Każdy timer pracujący w trybie PWM posiada dwa wyjścia (stąd wniosek, że mamy do dyspozycji 6 kanałów PWM) - dla timera 0 są to OC0A i OC0B, przypisane odpowiednio wyprowadzeniom 11 i 12 układu. Każde z tych wyjść może być osobno konfigurowane ze względu na współczynnik wypełnienia przebiegu, czyli na dobrą sprawę mogą one pracować niezależnie (przynajmniej z punktu widzenia programu).

Za zmianę szerokości impulsu odpowiadają tzw. rejestry porównania, które w BASCOMie dostępne są poprzez zmienne (a raczej identyfikatory, symbole) Pwm0a i Pwm0b (dla timera 0; w przypadku pozostałych timerów używamy identyfikatorów z odpowiednio podmienioną cyfrą, zresztą podobnie rzecz ma się ze wspomnianymi wcześniej wyjściami). Wartości tych zmiennych, których rozmiar jest uzależniony od konfiguracji timera (w przypadku timera 0 są to zmienne 8-bitowe), mogą być ustalane programowo. Są one cyklicznie porównywane ze stanem licznika i w oparciu o wynik tego porównania (i konfigurację generatora) ustalany jest - że użyję szalenie skompresowanego skrótu - czas trwania jedynki logicznej lub zera logicznego na wyjściu generatora PWM.

Wyczerpujący opis działania timerów jako generatorów PWM w mikrokontrolerach AVR przedstawił Piotr Górecki w swojej książce Mikrokontrolery dla początkujących (Wydawnictwo BTC, Warszawa 2006) - polecam.

Ilustracją do tego artykułu jest prosty układ, przedstawiony na poniższym schemacie:

Za pomocą potencjometrów, które pełnią tutaj rolę regulowanych dzielników napięcia, podajemy na kanały 0 i 1 przetwornika analogowo-cyfrowego napięcie o wartościach między 0 a 5V (uwaga: program zakłada, że pracujemy z napięciem zasilania równym 5V; można obniżyć napięcie, ale wyniki wyświetlane na LCD będą przekłamane, chyba, że zmienimy w programie przelicznik). Wartość odczytanego z ADC napięcia, przetworzona na postać liczbową, a następnie na wolty według zaszytego w programie przelicznika, jest wizualizowana na opcjonalnie dołączonym do układu wyświetlaczu LCD (opisywany przeze mnie moduł wyświetlacza sterowany przez port szeregowy UART), natomiast za jasność świecenia diod LED odpowiada właśnie współczynnik wypełnienia przebiegu prostokątnego pozyskanego z generatora PWM. Współczynnik ten zależy w sposób pośredni od wartości napięcia odczytanej przez ADC, więc za pomocą potencjometrów regulujemy jasność świecenia diod.

Program z przedstawionego niżej listingu nie powinien zawierać żadnego zaskakującego elementu - kod sam dla siebie stanowi komentarz, choć parę rzeczy dorzuciłem.

Na koniec uwaga dotycząca zasilania mikrokontrolera podczas korzystania z przetwornika analogowo-cyfrowego. Zapewne zauważyliście, że lewa strona schematu zawiera mnóstwo kondensatorów o wartości 100nF oraz cewkę 10μH. Jest to po prostu standardowe podłączenie zasilania, zgodne z kartą katalogową ATmegi, szalenie ważne ze względu na prawidłową filtrację napięcia, pozwalającą uniknąć niestabilnego działania układu, a w niektórych przypadkach nawet umożliwić w ogóle działania.

W następnym poście przedstawię schemat układu szalenie prądożernego termometru mikroprocesorowego - oczywiście wykorzystującego m. in. opisane tutaj ficzery.

Czego zazdroszczę amerykańskim kolegom?

Dlaczego akurat amerykańskim? Nie wiem, ale jakoś tak większość książek informatycznych, jakie przewinęły mi się przez ręce, była napisana przez właśnie autorów ze Stanów.

Bo znów bloguję o pisaniu książek. Informatycznych oczywiście.

Zatem obiektem mojej zazdrości jest czas, który niejednokrotnie autorzy zza oceanu dostają od swoich wydawnictw na napisanie bądź dokończenie książki. Ileż to razy czytałem w jakże charakterystycznych dla autorów z Nowego Świata podziękowaniach dla żon, ojców, matek, mężów, przyjaciół itp. że są szalenie wdzięczni za cierpliwość, jaką wspomniane osoby miały dla nich przez cały rok, kiedy to ich myśli były skierowane wyłącznie na książkę, nad którą pracowali... Rok! Marzenie. Ja najwięcej czasu to chyba ze trzy miesiące miałem - nie pamiętam dokładnie, musiałbym rzucić okiem na umowy. Krótki czas jest z jednej strony uzasadniony - we współczesnej informatyce zmiany zachodzą tak szybko, że jeżeli wyda się książkę o danej technologii, oprogramowaniu, języku czy środowisku z lekkim opóźnieniem, może się po prostu nie sprzedawać. Więcej czasu można poświęcić na stworzenie książki o bardziej ogólnym, choć ściśle ukierunkowanym znaczeniu, jednak ponadproduktowym, nie ograniczającym się do jakiejś konkretnej wersji programu czy technologii. Ale tego typu książki raczej nie mają aż takiego "brania" (chyba, że są wyjątkowo dobre) - wszak "Tworzenie aplikacji dla systemu /.../ w środowisku /.../ wersja 2014" sprzeda się lepiej, niż "Tworzenie aplikacji dla systemu /.../ w języku /.../". A będzie jeszcze gorzej w tym drugim przypadku, gdy autor nieopatrznie przemyci w środku informację, że tak naprawdę, to chodzi o jakieś dziwne narzecze jakiegoś cudacznego języka...
Inaczej jest oczywiście, gdy autor już ma jakiś opracowany tekst i szuka wydawcy (szczęścia życzę, choć dziś wydanie czegokolwiek nie jest aż takim problemem - o czym za moment), jednak ja większość tekstów pisałem na zamówienie, ponieważ moje propozycje okazywały się mieć niekorzystne trendy w kontekście oczekiwań potencjalnych czytelników.

Skąd te rozważania? Otóż ostatnio wpadłem na pomysł przygotowania kolejnej książeczki, tym razem jednak postanowiłem wziąć całość w swoje ręce, czyli wydać się sam. No, może nie do końca sam, ale z pomocą wydawnictwa, które pomogłoby w dystrybucji ebooka. Właśnie o to chodzi - dziś, gdy książki elektroniczne niewątpliwie dorównują - przynajmniej w pewnych kręgach - popularnością książkom klasycznym, wytworzyła się dla autorów świetna okazja do uniezależnienia się od trendów, wymagań, niekorzystnego wpływu wydawcy na kształt dzieła czy na tytuł itp. No i terminy nie ścigają - możesz pisać, jak długo chcesz; twój problem, gdy książka się nie sprzeda. Chyba, że napiszesz coś naprawdę dobrego, że się powtórzę.

Kiedyś popełniłem artykuł typu "rachunek sumienia" - teraz wracam do niego i postaram się solidnie przyłożyć do mojego nowego projektu książkowego.

Chwilowo nie zdradzę jednak, o czym rzecz będzie traktować.

Niesamowicie prosty czujnik zmierzchowy.

Tym razem zero programowania, będzie natomiast nostalgiczno-wspomnieniowy układzik, lekko zmodyfikowany.
Otóż kilka dni temu rozmawialiśmy w gronie znajomych o różnego rodzaju czujnikach zmierzchowych i czujnikach ruchu. Ponieważ należę do tych wariatów, co to hołdują jeszcze owej przestarzałej i kompletnie odrealnionej dziś zasadzie: "po co kupować, gdy można zrobić", stwierdziłem, że poskładam takie coś (czujnik zmierzchowy; sensor ruchu faktycznie lepiej nabyć, choćby ze względu na rozmiary ;)) i być może podłączę do jakiegoś mikrokontrolera. Przypomniało mi się też przy okazji, że znalazłem ostatnio w elektronicznych śmieciach stary fotorezystor (dla niewtajemniczonych: element zmieniający rezystancję, czyli opór elektryczny, pod wpływem działania strumienia światła) RPP130, jeden z kilku pozostałych po montowanych wieki temu układach tranzystorowych do zdalnego sterowania pracą urządzeń za pomocą latarki... No OK, nie było to specjalnie rozbudowane zdalne sterowanie ;)
Skompletowałem części, przypomniawszy sobie wcześniej schemat takiego detektora-czujnika, i zmontowałem na płytce stykowej dwa jego warianty. Pierwszy - to układ, który powoduje zapalenie diody LED1 pod wpływem strumienia światła skierowanego na fotorezystor, drugi zachowuje się jak "rasowy" czujnik zmierzchowy, czyli zapala diodę LED1 gdy wokół zaczyna być ciemno. Jak widać na schematach, oba rozwiązania są trywialne i bazują w zasadzie na pracy tranzystora w skrajnych położeniach charakterystyki wyjściowej (nasycenie - odcięcie). Wartości rezystorów są dobrane tak, żeby po stronie wejściowej (obwód bazy tranzystora) zapewnić odpowiednie wysterowanie (lub jego brak) tranzystora, a po stronie wyjściowej - świecenie diody i zapobieganie uszkodzeniu tranzystora w momencie, gdy przez kolektor i emiter płynie prąd (aż do wartości odpowiadającej stanowi nasycenia).
Oto schematy kolejno czujnika oświetlenia i czujnika zmierzchowego:

Jasność świecenia diody zmienia się w zależności od natężenia strumienia światła, czyli w zależności od rezystancji fotorezystora - czyli od wartości napięcia pomiędzy bazą a emiterem. Innymi słowy fotorezystor działa tutaj jak potencjometr, tyle, że mechanizm regulacji zastąpiony został strumieniem światła. Jak już zapewne wszyscy zauważyli, różnica pomiędzy oboma układami polega na zamianie miejscami rezystorów R2 i R3.
Ważna rzecz: dobierając fotorezystor - bo przecież nie musimy stosować takiego eksponatu, jak ten u mnie - musimy sprawdzić jego podstawowe parametry, czyli tzw. rezystancję jasną (dla RPP130 to wartości od 1kΩ do 10kΩ), dotyczącą oświetlonego fotorezystora, i rezystancję ciemną (dla RPP130 ok. 10MΩ) dla elementu nieoświetlonego. Znajomość tych parametrów może pomóc w prawidłowym wyborze wartości rezystora R2 (R3).

A jak ten układ podłączyć do mikrokontrolera, np. ATmegi wyposażonej w przetwornik analogowo-cyfrowy? Sprawa jest prosta - można np. usunąć diodę LED1, zewrzeć emiter do masy, dobrać nową wartość R1 i podłączyć do wyjścia (między kolektor a emiter/masę) równolegle rezystor. Spadek napięcia na rezystorze wyjściowym będzie analizowany przez przetwornik.

I jeszcze kwestia kalibracji - tutaj też nie powinno być problemów, czułość urządzenia można ustawić odpowiednim doborem rezystorów albo po prostu poprzez bardziej finezyjnie rozbudowany układ.

Być może wkrótce zmajstruję jakiś mikroprocesorowy czujnik zmierzchowy, połączony z czujnikiem ruchu, jednak najpierw postaram się opublikować schemat i program dla niesamowicie prądożernego termometru z ATmegą i szesnastoma LED-ami w roli głównej :)

Programowanie AVR cz. 7: Mikroprocesorowy sterownik wyświetlacza alfanumerycznego LCD (układ HD44780 lub odpowiednik) z dostępem przez łącze szeregowe.

Podłączenie wyświetlacza alfanumerycznego na układzie HD44780 (lub podobnym) do mikrokontrolera wymaga użycia w najlepszym przypadku sześciu wyprowadzeń. Jeżeli musimy wykorzystać mały mikrokontroler, np. ATtiny2313, stracimy sporo linii, które mogłyby służyć do realizacji innych funkcjonalności. Zasygnalizował mi to swego czasu znajomy, który właśnie m. in. z tego powodu nie przepada za LCD.
Można jednak wykonać małe obejście, które pozwoli na wykorzystanie do połączenia wyświetlacza z mikrokontrolerem dwie linie (czyli dwa wyprowadzenia), przy założeniu istnienia wspólnego obwodu zasilania. Z pomocą przychodzi nam sprzętowy port szeregowy UART, będący na wyposażeniu większości mikrokontrolerów AVR. Ma on ponadto kompletne wsparcie w BASCOMie, a podejrzewam, że jego wykorzystanie w języku C również nie nastręcza problemów.
Założenie projektu, który przedstawiam w tym artykule, jest proste: zrealizować mikroprocesorowy sterownik wyświetlacza, który znaki do wyświetlania oraz zbiór podstawowych komend będzie odbierał od układu "nadrzędnego" (nadającego) przez port szeregowy. W ten sposób zminimalizujemy liczbę linii koniecznych do podłączenia wyświetlacza do układu i przy okazji uprościmy kod programu.
Proszę rzucić okiem na schemat:

Sterownikiem głównym naszego modułu wyświetlacza jest mikrokontroler ATtiny2313. W układzie można wykorzystać dowolny wyświetlacz alfanumeryczny z HD44780 lub jego odpowiednikiem. Na schemacie widzimy wyświetlacz typu 16*2, ale mój program dostosowany jest do wyświetlacza 16*1a (niby jeden wiersz z szesnastoma znakami, ale programuje się go jak dwa wiersze po osiem znaków; tylko takie wyświetlacze posiadam). Oczywiście użycie innego wyświetlacza spowoduje konieczność dostosowania programu. Można też pokusić się o napisanie uniwersalnego programu, dostosowującego się do konkretnego modelu wyświetlacza. Ponieważ odpytywanie sterownika wyświetlacza mogłoby nie dać oczekiwanego rezultatu (szczerze mówiąc nie sprawdzałem, czy istnieje w ogóle taka możliwość), wybór rodzaju wyświetlacza mógłby być dokonywany sprzętowo - np. poprzez użycie wolnych portów mikrokontrolera, tak, jak to ma miejsce przy ustalaniu adresu sprzętowego urządzenia na magistrali I2C. Mielibyśmy wtedy na płytce dodatkową listwę z mikroprzełącznikami.
A oto i program oraz tzw. plik nagłówkowy (nazewnictwo z C - dla wygody i oddania istoty tego pliku):

Plik nagłówkowy należy dołączyć lub przepisać jego zawartość do każdego programu dla mikrokontrolera, który ma docelowo korzystać z naszego modułu wyświetlacza.
Jeżeli do komunikacji z wyświetlaczem będziemy używać domyślnego sprzętowego UART-a (tzw. "pierwszego"), wystarczy do wysłania jakiejkolwiek informacji użyć komendy Print lub Printbin języka BASCOM - dotyczy to zarówno znaków ASCII, jak i komend zdefiniowanych w pliku nagłówkowym (mam nadzieję, że analizując prosty kod programu każdy szybko zauważy, jakie to są komendy). W zasadzie oprócz okienka konfigurującego port szeregowy z poziomu środowiska BASCOMa nie ma potrzeby ustawiania czegokolwiek (związanego z LCD i portem szeregowym) w programie!
Sterownik, jeszcze w fazie prototypowej (na płytce stykowej), testowałem z wykorzystaniem prostego układu z ATmegą (plus ekspander I2C, przycisk i kilka diod LED) jako nadajnikiem (program podobny do prezentowanego w tym blogu wcześniej) - współpraca przebiegała bez zarzutu, jednak konieczne było zastosowanie buforowania transmisji (zwróćcie uwagę na rozmiar pamięci RAM Waszego mikrokontrolera). W razie konieczności, można buforowanie zastosować również w układzie nadajnika, ale nie powinno w tym względzie być większych problemów.
Konfiguracja portu szeregowego wykonana została z poziomu środowiska BASCOMa, jednak parametry transmisji umieściłem w komentarzu do programu (patrz: listing). Myślę, że nie trzeba nikomu tłumaczyć konieczności uzgodnienia w obu układach (nadawczym i odbiorczym) identycznych parametrów transmisji?
Podłączenie wyświetlacza do ATtiny'ego narzucone zostało przez wymogi zastosowanej biblioteki LCD4.LIB (szczegóły), której zadaniem jest m. in. zmniejszenie rozmiaru kodu wynikowego programu i jego optymalizacja.
Dwie rzeczy, o których musimy jeszcze pamiętać, to odpowiednie ustawienie fusebitów w ATtiny - w zależności od sposobu zasilania sterownika i użytego rezonatora kwarcowego (tutaj pomóc może dokumentacja mikrokontrolera), oraz zapewnienie skutecznej filtracji zasilania. Ten ostatni aspekt w przedstawianych dotychczas układach pomijałem, ale jest to rzecz szalenie ważna. Polecam lekturę tych dwóch ciekawych artykułów:

• Mikrokontroler - PRAWIDŁOWE ZASILANIE
• Zasilanie mikrokontrolera.

Układ zmontowałem "na gotowo" na płytce uniwersalnej, dostosowując projekt do możliwości zmiany wyświetlacza (wyświetlacz podłączany na "grzebień"). Zdjęcia niżej przedstawiają prawie zmontowany układ i zestaw testowy po wykonaniu próby:

Zalecam stosowanie wspólnego zasilania (mimo wszystko) - już zresztą o tym wspominałem. Zwróćmy również uwagę, że linie portu szeregowego, a w zasadzie przewody, musimy podłączyć pomiędzy odbiornikiem (nasz sterownik) a nadajnikiem (dowolny układ mikroprocesorowy) na krzyż, czyli TxD z RxD. Jeśli chcemy podłączyć moduł wyświetlacza do portu szeregowego w pececie czy innym urządzeniu komputerowym, musimy zadbać o dopasowanie napięć i logiki (układ na tranzystorach lub coś jak MAX232). Pobór prądu przez moduł nie przekraczał 20mA z podłączonym podświetlaniem wyświetlacza (przy zasilaniu z baterii 4,5V).
Po przetestowaniu płytkę z kompletnym już modułem umieściłem na deseczce z filcowymi podkładkami - całość tworzy "klocek elektroniczny" do łatwego testowania i wykorzystania z przeróżnymi układami, które od teraz będę dostosowywał do właśnie szeregowej komunikacji z wyświetlaczem.
Póki co moduł sprawuje się dobrze :)
Jeżeli uważacie, że pomysł i projekt warte są uwagi, zachęcam do montowania i zabawy (wszystko jest free - tylko części musicie nabyć sami ;-)), zadawania pytań i zgłaszania uwag.