Banana Pi i ekran LCD podłączony po i2c

Dawno temu NAS został wyłączony, ale zmierzam do jego reaktywacji. Po głowie chodziło mi zamknięcie wszystkiego (zasilacz, dysk, Banana Pi) w zgrabnej, tym razem dedykowanej do elektroniki, obudowie.

Trochę z myślą o programie do przełączania łącza internetowego, a trochę o pomiarze temperatury przy pomocy komputera, przyszedł mi pomysł, by sygnalizować stan różnych rzeczy w sposób nie wymagający łączności sieciowej, czyli najdoskonalszy, analogowy: migając diodą. Oczywiście szybko doszedłem do wniosku, że jedna dioda nie wystarczy, wbudowane diody to trochę mało, ale przecież w Raspbery Pi i analogach mamy GPIO, możemy tych LEDów podłączyć kilka…

Nie wiem jak dokładnie doszło do tego, ale podczas poszukiwań szybko wpadłem na ekrany LCD z serii 1602, które również można podłączyć przez GPIO. Skoro tak, to pomyślałem, że nie ma się co ograniczać. Zamiast prostej sygnalizacji stanu i konieczności pamiętania która kombinacja co oznacza można po prostu wyświetlać dowolny tekst. Niezbyt długi, ale nadal jest to znacznie większa ilość informacji, niż z kilku czy nawet kilkunastu LEDów. W dodatku cena takiego jest bardzo przystępna, czego o różnych ekranach dotykowych czy e-ink powiedzieć nie można.

Pierwotnie chciałem podłączyć LCD do Orange Pi zero, ale niestety, nie ma on pinów GPIO – są wyprowadzenia, ale trzeba by lutować, co pewnie docelowo zrobię, ale bardziej chodziło mi o sprawdzenie sterowania, a mam pod ręką Banana Pi. Gdy szukałem schematu jak podłączyć ekran do Banana Pi, natknąłem się na coś znacznie ciekawszego – wersję ekranu LCD ze sterownikiem podłączanym przez interfejs i2c. Dzięki podłączenie temu jest bardzo proste – raptem cztery przewody, nawet nie trzeba lutować, o ile używa się gotowych przewodów z końcówkami. Dodatkowo – i to najlepsza część –  całością daje się w elegancki sposób sterować za pomocą Pythona.

Efekt końcowy wygląda tak:

LCD 1602
LCD 1602 Źródło: fot. własna

Zdjęcie zrobione telefonem, po ciemku. Z tyłu płytki jest potencjometr pozwalający na regulację kontrastu. Poziom podświetlenia jest stały, można tylko włączyć i wyłączyć LED, zarówno hardware’owo (zworka), jak i programowo. Ekran LCD bierze bardzo mało prądu – przy pomocy watomierza nie udało mi się zarejestrować różnicy, czyli całość zużywa poniżej 0,1 W.

Jak to zrobić? Powtórzę instrukcje, z których korzystałem. Instalujemy dodatkowe pakiety:

apt-get install i2c-tool python-smbus

Następnie podłączamy ekran i sprawdzamy adres przy pomocy polecenia:

i2cdetect -y 1

Otrzymaną wartość należy wpisać w skrypcie (stała ADDRESS, linia 29 w przytoczonym przykładzie).

Następnie możemy sterować ekranem z poziomu języka Python. Na przykład wywołanie efektu widocznego na ekranie można zrobić przy pomocy polecenia:

python test_lcd.py "Pomiedzy bitami" "https://zakr.es/"

Gdzie test_lcd.py ma zawartość:

import sys

from i2c_lcd import *

display = lcd()
display.lcd_display_string(sys.argv[1], 1)
display.lcd_display_string(sys.argv[2], 2)

Biblioteka pozwala na dużo więcej, między innymi na własne znaki, ale tym się póki co nie bawiłem. Wyświetlony tekst pozostaje na ekranie po zakończeniu programu do momentu wpisania nowego lub skasowania poprzedniego. Jeśli do ekranu będzie dostarczone napięcie, to wyłączenie Banana Pi nie wpływa na wyświetlany tekst. Dlatego jeśli chcemy monitorować, czy nasz komputer się nie zawiesił, musimy zmieniać okresowo tekst – w innym wypadku zawartość LCD nie świadczy o niezawieszeniu się komputera.

Sterowanie włączaniem i wyłączaniem podświetlania to:

display.backlight_on(False)
display.backlight_on(True)

Wyświetlać można cokolwiek – temperaturę, zajętość dysku, opóźnienia/straty na sieci, kurs BTC (pozdro dla L.!), adres IP (po starcie!), informacje o nowych mailach…

Pozostało mi wymyślenie, w jaki sposób zrobić sensowne sterowanie. Po głowie chodzi mi demon, który będzie pobierał informacje do wyświetlenia z jakiejś kolejki, w zależności od ich priorytetu, czasu ostatniego wyświetlenia i pory dnia sterował oświetleniem i wyświetlał informacje. A może już jest coś takiego?

I garść linków pomocnych przy tworzeniu ww. rozwiązania AKA źródła:

  1. pinout Banana Pi
  2. LCD i2c dla Raspberry Pi
  3. Banana Pi i urządzenia i2c
  4. Skrypt w Pythonie
  5. Biblioteka Python do obsługi ekranów LCD po i2c

UPDATE Dla zainteresowanych kupnem – ekran z modułem do komunikacji i2c kosztuje ok. 12 zł na Allegro. Na zdjęciu jest wersja zielona, ale istnieją też wersje niebieskie, gdzie tło jest ciemne, a napisy jasne.

Migracja z Aero2 na a2mobile

The world’s changing. Music’s changing. Even internet is changing.

Tak to się jakoś pomału kręci z tymi zmianami i mam pomysł na notkę z obserwacjami nt. zmian szybkości komputerów i (bardziej) łącz, ale to innym razem. Internet u rodziców miał się dobrze (via modem GSM i Raspberry Pi robiące za router), tylko pakiety Aero2 schodziły ciut szybciej, niż przewidywałem. Znaczy chyba raz zdarzyło się, by zeszły więcej niż dwa w miesiącu, ale dwa na miesiąc IIRC schodziły regularnie.

Do tego doszedł średni panel (klikasz „dodaj do koszyka” i jak nie pamiętasz, że dodawanie trwa, to możesz dodać kolejny raz, nim pierwszy „zaskoczy”), zaliczyli wyciek danych klientów no i – last but not least – pojawiły się inne oferty na rynku. W szczególności ciekawie wyglądała oferta a2mobile, gdzie za 10 zł na miesiąc mamy internet bez limitu transferu. Tj. innego niż prędkość łącza, a ta spada wraz ze zużyciem transferu, czyli klasyczny lejek. Do 5 GB transferu jest bez limitu prędkości, do 10 GB jest limit 3 Mbps (modem bez LTE, w praktyce właśnie w tych okolicach łącze działa), do 15 GB jest limit 1 Mbps, a potem 512 kbps. Zakładam, że poniżej 10 GB nie spadnie. 😉

Głównym wyzwaniem okazało się… zdobycie startera. Nie chciałem zamawiać kurierem, w FAQ pisali, że startery są do kupienia w sklepach Żabka. Właściwsze byłoby sformułowanie bywają, bo kupić udało mi się jakoś przy czwartym podejściu. Po czym musiałem zaliczyć wizytę na poczcie w celu rejestracji, więc chyba lepiej wziąć tego kuriera, zakładam, że umie on potwierdzić dane kupującego.

Konfiguracja wvdial jest w zasadzie analogiczna do tej od Aero2, zmienia się jedynie APN oraz wypadają user i hasło, czyli finalnie sekcja w wvdial.conf wygląda tak:

[Dialer a2mobile]
Modem = /dev/ttyUSB0
Init1 = AT+CGDCONT=1,"IP","a2mobile.pl"
Phone = *99#
Stupid mode = yes
Username = "blank"
Password = "blank"
Dial Attempts = 0
Auto DNS = "off"

Wrzucam, bo podobne wpisy były, nie znalazłem gotowca w sieci dla a2mobile, ale tak naprawdę wszystko jest do siebie podobne i łatwo zmienić konfigurację, jeśli ma się skonfigurowany APN na telefonie z Androidem… Kiedyś jeszcze była konfiguracja wvdial dla Orange.

Majówka

Dziwna to majówka i dziwny urlop. Jedno i drugie poszatkowane i pracowite. Pierwszą i najważniejszą rzeczą do załatwienia była – jak zwykle spóźniona – zmiana opon na letnie. Spojrzałem na felgi od zimówek i stwierdziłem, że warto je odświeżyć, bo trochę ruda zaczyna wychodzić. A skoro zakładam letnie, to najpierw letnie. Poszedłem na łatwiznę – spray czarny matowy, wyklejenie boku opony taśmą malarską, przetarcie drucianą szczotką i papierem ściernym. Jest powiedzenie, że gdy masz młotek, wszystko wygląda jak gwóźdź. Zmieniłbym na gdy masz spray, wszystko wygląda jak wymagające malowania. Faktem jest, że sprayem maluje się bardzo fajnie – łatwo i szybko. Niestety, przygotowanie felg zajmuje dłuższą chwilę. I oczywiście na jedną stronę z kół letnich zabrakło mi spray, a jak pojechałem dokupić w niedzielę, to okazało się, że sklep już zamknięty, więc w sumie zeszło znacznie dłużej, niż planowałem, więc odświeżone zostały tylko letnie. Zimówki i zapas muszą dłuższą chwilę poczekać.

Potem musiałem wrócić – tym razem pociągiem – do Poznania. Jedna sprawa do załatwienia, ale głównym powodem było złożenie PITa. Również tradycyjnie w ostatni dzień. Powody składania na papierze są różne – coś mi świta, że pod Linuksem nie szło to łatwo, trzeba mieć jakieś dodatkowe dane z poprzednich lat, a jakieś dziwne dodatki ostatnio jeszcze musiałem rozliczać. Głównie jednak chodzi o to, że papierowe mam przećwiczone, a nie chce mi się kombinować w ostatni dzień z nowym sposobem.

Oczywiście mogłem wysłać PIT pocztą, ale była jeszcze sprawa na miejscu, a stwierdziłem, że w pociągu sobie poczytam. Faktyczni, nadrobiłem lekturę i mam nadzieję, że wciągnę się z powrotem do czytania książek bo – wstyd się przyznać – to pierwsza przeczytana „moja” książka w tym roku. Nieco zasługa tego, że łapię się za cegły, niektóre nie podpasowują, a nie lubię brać się za kolejną książkę mając nieprzeczytaną inną.

Załatwiwszy temat opon, stwierdziłem, że zrobię lepszą składankę z muzą do auta. Do tej pory używałem uszkodzonej karty pochodzącej z Raspberry Pi (całkiem dobrze sobie radziła, ale w sumie nic dziwnego, to tylko odczyt, a uszkodzony jest IIRC konkretny fragment). Niestety, okazało się, że nowe utwory nie wejdą. Nie wiem czy to zaleta mtp[1], czy łapały się w uszkodzony obszar. Może kiedyś pobawię się w diagnostykę (ciekawe czy radio poradzi sobie z dwiema partycjami?), teraz po prostu pojechałem do sklepu i kupiłem nową. Oraz żarówkę do świateł pozycyjnych, w końcu. TBH wymieniłbym już dawno oryginalne W5W na stosowne LEDy, ale podobnoż się czepiają na przeglądach. Nie wiem czemu, w końcu i tak to praktycznie nie świeci, więc wolałbym, żeby przynajmniej prądu nie brało, przy zbliżonej jasności.

Tak naprawdę kupiłem dwie karty. Druga wylądowała w Raspberry Pi robiącym za router GSM. Tu słowo o stabilności Linuksa i rozwiązań chałupniczych (rpi + modem USB + hub USB), bo miałem niedawno okazję na ten temat rozmawiać. Albo raczej jeden uptime:

08:32:00 up 287 days, 18:42, 1 user, load average: 0.06, 0.08, 0.08

Głównym zasłużonym jest tu… prąd, bo router działa bez UPSa…

Kartę wymieniłem, bo chciałem zrobić upgrade Raspbiana – lada moment Debian Jessie przestanie być wspierany, a używany Raspbian właśnie na nim bazował. Poszedłem na łatwiznę i po prostu wrzuciłem najnowszy image,  bazujący na Stretch, dograłem brakujące pakiety i wrzuciłem kluczowe pliki z konfiguracją. Jestem nieco zaniepokojony, że taka rzeźba na szybko zaczyna mi wychodzić. Chyba muszę to na Githuba wrzucić. I może jakieś ansible do kompletu? W sumie rozjechała się tylko jedna rzecz – wyciąganie IP z interfejsu w jednym skrypcie. I tylko dlatego, że ifconfig zmienił format, więc automatyzacja i tak nic by tu nie pomogła…

Poza tym, sporo działki. Trochę pomogłem rodzicom na działce, trochę odpocząłem. Generalnie raczej pracowicie, choć i tak wielu rzeczy nie udało się zrobić, jak np. porządków z przekierowaniem ruchu ze starego bloga. Ale to może jeszcze w weekend ogarnę.

[1] Korzystałem z telefonu, bo okazało się, że nie bardzo mam czytnik kart micro SD – muszę kupić jakiś tani badziew i niech leży na takie okazje, bo wyciąganie modemu USB to nie jest to, co tygrysy lubią najbardziej.

Internet bez kabla

Raspberry Pi radzi sobie w połączeniu z modemem Huawei 3131 (stara wersja) zaskakująco dobrze jako router do Aero2 (wariant płatny). Przesiadka z Banana Pi nie była całkiem bezproblemowa – internet w domu co prawda działał, ale straciłem zdalny dostęp przy pomocy autossh. Diagnostyka była prosta – okazało się, że nie wystarczy skopiować skrypty i crony, warto jeszcze sprawdzić, czy autossh jest w ogóle zainstalowane…

Prawdopodobnie przez brak nawiązanego połączenia SSH zmienia się IP i przesyłanych (a w zasadzie zliczanych) jest więcej danych podczas okresowego (co 5 minut) wywoływania wget w ramach namiastki dyndns. Znaczy zamiast jednego pakietu 3GB po 5 zł sztuka miesięcznie schodzą dwa. Można kupić więcej od razu, więc żaden problem, zresztą i tak raczej się zdziwiłem, że na początku mieścili się w jednym.

Internet z GSM działa przyzwoicie. Nie zauważyłem ani specjalnych lagów, ani spowolnienia. Co prawda może to być kwestia porównywania ze starym pakietem, ale póki co skłaniam się ku teorii, że jestem w stanie przesiąść się w domu całkowicie na internet bezprzewodowy, po GSM. Przynajmniej technologicznie, bo ceny wyższych pakietów jeszcze nie zachwycają. Poza tym, LTE działa podobno jeszcze lepiej…

Pozostało dołożenie drugiego modemu z internetem od innego operatora, uruchomienie abcc do wybierania aktualnie lepszego (i działającego) łącza i… tyle. No, muszę przerobić jeszcze wywoływanie autossh, bo zrobiłem proste @reboot w cronie, co słabo się sprawdza w przypadku zerwania sesji – raz się jednak pakiet Aero2 skończył i trzeba było doładować, a jak się nie zrobi tego od razu, to się zapomina.

Oczywiście można kombinować jeszcze z wyniesieniem modemów GSM w lepsze miejsce, podpięciem anten itp. ale… po co komplikować, skoro działa? Z drugiej strony byłby pretekst do zabawy z antenami i potestowania wpływu siły sygnału GSM na prędkość działania internetu.

Przerwa majowa

Uważni czytelnicy dostrzegli, że w zeszłym tygodniu nie pojawił się żaden wpis. Regulamin DSP2017 dopuszcza przerwy w prowadzeniu projektów i… zeszły tydzień należy potraktować jako przerwę. Zresztą ponad tydzień, bo w zasadzie majówka cała nieprojektowa, z małym wyjątkiem, o którym zaraz. W każdym razie z konkursu się nie wycofałem i mam nadzieję, że tygodni roboczych będzie wystarczająco dużo. Nie liczyłem ile jest dokładnie, a zarejestrowałem się z opóźnieniem. Tak czy inaczej, nie chodzi o to by złowić króliczka…

Przerwy są dobre, czy to w pracy jako urlop, czy przy projekcie. Można spojrzeć z boku, wyskoczyć z utartych torów i nabrać energii. W każdym razie zeszły tydzień był mocno pracowity, a wypełnianie PITów, to nie jest coś, co warto odkładać na ostatnią chwilę, powiadam wam. Zresztą warto wcześniej sprawdzić, czy ma się komplet papierów, jak się okazuje. W każdym razie zdobyłem kolejny skill w zakresie obsługi podatków. Ale ostatecznie wszystko w miarę wyprostowane.

Potem był czas dobrych imprez i intensywnego chodzenia po sklepach celem urządzenia oświetlenia – powiedzmy, że 20% zrobione. A w międzyczasie doglądanie zewnętrznych rzeczy – a to serwer się zaczął restartować bez przyczyny (odpowiedź ISP rozwaliła, ale restarty ustały, hm…), a to ktoś zepsuł format danych, z których korzystam… Chwilę trwało, zanim przyswoili, że błąd zgłasza osoba z zewnątrz, a nie pracownik. Fun, fun, fun. Tylko czasu szkoda.

Udało mi się zrobić dwie związane z projektem rzeczy: przetestować uruchomienie programu na czystym systemie z ARM (działa, czemu miałby nie działać?) oraz wstawić Raspberry Pi zamiast Banana Pi jako router, czyli odzyskać właściwą sondę. Co prawda to ostatnie nie udało się w 100%, bo robiłem na szybko, trochę czasu zeszło na ustalenie, że NAT lepiej działa, jak się włączy forwarding, a po wszystkim okazało się, że logowanie przy pomocy autossh coś nie działa, ale powiedzmy, że wariant minimum jest zrobiony. Z powodu małej ilości czasu nie zaryzykowałem też wpięcia drugiego modemu.

Przerwa i programowanie w pracy skłoniło ku refleksji, że może jednak lepiej będzie docelowo przepisać to obiektowo. Głównie chodzi o łatwość wykorzystania kodu w innych projektach – dokładnie to przerabiam w pracy. W cele projektu oficjalnie tego nie wpisuję póki co, ale jeśli tylko starczy czasu, to będzie próba refaktoringu kodu.

Raspbian i uruchomienie modemu GSM Huawei E3131

Uruchomienie modemu Huawei E3131 (hilink) pod Debianem opisałem wcześniej, ostatnio pisałem o perypetiach związanych z tym, że na Debianie działa, na Raspbianie nie działa. Dziś zagadka została rozwiązana.

Udałem się na kanał IRC Raspbiana, w nadziei, że dostanę wskazówki w czasie kiedy będę przeprowadzać debug. Czasami nie ma się co męczyć, bo po prostu można o czymś nie wiedzieć, jak miało to miejsce w przypadku uruchomienia SSH na Raspbianie. Poza tym, takie pytanie o pomoc i dostarczenie pełnych danych o problemie działa trochę jak gumowa kaczuszka.

Nim dobrze skończyłem pisać, dostałem namiar na ten wpis. Wygląda paskudnie? Ano wygląda. Ale działa – po wydaniu podanego polecenia pojawił się interfejs eth1 w systemie. Ale być może wystarczy doinstalować sg3-utils? Niestety nie – opisany sposób działa tylko do rebootu Raspberry Pi czy też do wyjęcia i włożenia modemu (nie pamiętam, oba mało akceptowalne…). Od biedy mógłbym z tym żyć, bo prosty skrypt do crona załatwi sprawę, ale… na Debianie jest bardziej elegancko, więc drążyłem temat.

Skoro przyszło do pakietów, to zauważyłem, że na desktopie mam zainstalowany pakiet:

ii  modemmanager                              1.6.4-1                                                 amd64        D-Bus service for managing modems

Brzmi obiecująco, tym bardziej, że dotyka D-Bus. Na Raspbianie tego pakietu nie było… Doinstalowałem pakiet, reboot Raspberry Pi i… Działa. Nie jest identycznie jak w Debianie, bo nadal interfejs to eth1 i IP pobiera automatycznie z DHCP, ale to detale – najważniejsze jest działające wyjście na świat.

Podsumowując: aby działały modemy typu dongle USB w Raspbian, należy doinstalować pakiet modemmanager.

Wpis pojawia się w kategorii DSP2017 z racji tego, że płytka z ARM będzie robiła za stację testową. Jeśli wszystko pójdzie dobrze, jeszcze dziś…

Prawie jak stacja testowa

Były święta i wolne. W planach miałem uruchomienie stacji testowej w domu, na Raspberry Pi, ale po namyśle stwierdziłem, że jednak wolę zamienić Banana Pi, robiące aktualnie za router u rodziców z moim Raspberry Pi i testować na BPi. Przy okazji miałem nadzieję wyjaśnić zagadkę niedziałającego z BPi zasilacza domowej produkcji, który świetnie działa z RPi. Podejrzewam kabel USB, ale o tym innym razem.

W każdym razie spakowałem RPi z zainstalowanym podstawowym systemem i dostępem po SSH, wziąłem też sporo kabli USB, zasilacze, mirniki napięcia. Ot, wszystkie okoliczne graty. Wziąłem też testowy modem Huawei E3131, na wypadek gdyby przyszło mi do głowy zastąpienie istniejącego, również Huawei E3131 tyle, że starszej generacji, bez hilink.

Na miejscu dokonałem szybkiego kopiowania skryptów i… przyszedł mi do głowy szatański plan. Przecież mogę uruchomić oba modemy w RPi i testować w warunkach produkcyjnych. Tyle, że zdalnie. Niestety, szybko okazało się, że mimo starannego choć szybkiego skopiowania skryptów RPI nie nawiązuje łączności ze światem. Wielkiej filozofii w skryptach nie ma, prawa identyczne. Stary Huawei nie chce działać. Wetknąłem więc nowy modem, z hilink i stwierdziłem, że w sumie najwyżej zostanie RPi z nowym modemem robiące za router, a BPi przetestuję po powrocie do domu i od razu zrobię z niego stację roboczą. Tyle, że okazało się, że modem z hilink niby nawiązuje połączenie (jest ustawiony, by robił to automagicznie), przynajmniej wskazuje na to kolor diody ale… w systemie nie powstaje interfejs. Czyli żaden z dwóch modemów na USB nie zadziałał na RPi!

Lekko tylko klnąc pod nosem szybko wróciłem do działającej konfiguracji z Banana Pi robiącym za router GSM, czyli zupełnie do punktu wyjścia, bez jakichkolwiek postępów – ani nie mam uruchomionej stacji testowej, ani nie zluzowałem BPi w celu przetestowania zasilacza.

Jednak są pewne… zmiany, bo ciężko to nazwać postępem:

  • Mam zagadkę pt. „na Raspbianie nie działają modemy USB”. Jak patrzę we wcześniejszy wpis o SSH, to jakiś Raspbian Lite. Może to jest przyczyną? Może customowy kernel Raspbiana? Przetestuję w chwili wolnej.
  • Jakimś cudem zadziałało zapięcie Banana Pi zarówno jako źródła danych, jak i „klienta” w hubie USB. Jak ostatnio sprawdzałem, to w tej konfiguracji się nie uruchamiał, a RPi działało bez problemu. Zastanawiam się, czy znowu nie chodzi o kabel.
  • Kolejnym zaskoczeniem jest to, że Raspberry Pi nie musi być wpięte w ww. sposób do huba USB, by działało. Okazało się, że wystarczy je zapiąć jako źródło danych i… dostaje zasilanie. Jest to dla mnie totalną zagadką, bo do tej pory nie przyszło mi do głowy, ale działa. W sumie fajne, bo mam jeden port w hubie USB więcej wolny.

Czyli w DSP2017 zastój, ale czegoś nowego się dowiedziałem i jest co robić. Następny wpis raczej również będzie metatematyczny, prawdopodobnie znowu o ciekawych projektach w DSP2017. Z rzeczy związanych bardziej bezpośrednio – prawdopodobnie w przyszłym tygodniu jakąś stację testową jednak uruchomię. Mam nadzieję, że będzie to RPi z rozwiązaną zagadką modemów USB…

Allegro Tech Talks Poznań #4 – wrażenia

W projekcie abcc panuje chwilowy zastój, spowodowany czynnikami różnymi – od osobistych (bardziej, znacznie bardziej), przez zawodowe (mniej, znacznie mniej), ale faktem jest, że spocząłem na laurach nieco i nic się od ostatniego wpisu nie zmieniło w temacie. Plan jest taki, żeby uruchomić sobie stację testową opartą o Raspbbery Pi, która będzie działać na dwóch lub trzech łączach (kabel, modem GSM i być może, jeśli RPi wyrobi prądowo, karta WiFi) i zrzucać pomiary, w celu lepszego dobrania parametrów. Ale to plany…

Tymczasem w ramach pożeraczy czasu byłem w zeszłym tygodniu na spotkaniu Allegro Tech Talks Poznań #4. Staram się bywać, jeśli akurat mam czas. Jeśli dobrze zrozumiałem, po raz pierwszy można było wysłuchać przez net na żywo, ale jakoś nie przepadam za taką formą – lepiej mi się obiera na żywo, nie mam nawyku słuchania przez net. No i zawsze można spotkać znajomych i poplotkować.

Prezentacje były dwie, obie dotyczyły Apache Solr, więc zupełnie nie moja działka, i przyznaję, że wahłem się, czy w ogóle iść, ale obie były IMO bardzo dobrze i interesująco poprowadzone, więc części merytorycznej też nie żałuję.

Pierwsza prezentacja dotyczyła uruchamiania Solra w kontenerach dockerowych, poczynając od tego jak to skonfigurować i uruchomić, przez przedstawienie wyników benchmarków pomiędzy sprzętem fizycznym (bare metal), przez pełną wirtualizację, po kontenery. Różnice były duże, przedstawione dane przekonują do kontenerów, ale… Zawsze jest jakieś ale, w tym przypadku testy były robione na ustawieniach domyślnych. Z jednej strony rozumiem, bo jakiś wspólny mianownik trzeba mieć, z drugiej produkcję konfiguruje się pod konkretny przypadek. Niemniej, różnice były na tyle istotne, że konfiguracja raczej nie będzie w stanie ich zniwelować. W sumie można było traktować tę prezentację mniej jako o Solr, bardziej jako o dockerze.

Druga prezentacja dotyczyła optymalizacji Solra w Allegro. Jak pisałem, nie moja działka, więc momentami była to trochę chińszczyzna (na zasadzie: nie wiem co to dokładnie jest), ale opowiedziane przystępnie, ciekawie i z przykładami. Mocno nieoczywiste przypadki i wyniki, efekty dobre. Stawiam, że dla osób zajmujących się Solrem perełka. Jest dostępna w wersji online.

Spotkałem też starych znajomych i poplotkowaliśmy, więc ogólnie bardzo udane wydarzenie – 10/10.

Jak włączyć SSH w Raspbian?

Sytuacja zmusiła mnie do odkopania RPi. Szybko potrzebowałem przetestować jedną rzecz, więc wybrałem Raspbian Jessie Lite. Główna zaleta to niewielki rozmiar i kernel w wersji 4.4. Po włączeniu i pobraniu IP przez RPi okazało się jednak, że nie sposób się zalogować – nic nie słuchało na porcie.

Instrukcje, które znalazłem, są dobre, jeśli ktoś ma monitor i klawiaturę. Ja nic takiego pod ręką nie miałem, więc zacząłem przyglądać się skryptom startowym, ale w międzyczasie zapytałem na IRCu i dostałem linka, który podaje prosty przepis na włączenie SSH – wystarczy utworzyć plik ssh o dowolnej zawartości w katalogu /boot na karcie SD z Rasbianem:

touch /boot/ssh

Oczywiście powyższe zadziałałoby, gdyby było wykonywane bezpośrednio z Raspberry Pi, trzeba wziąć poprawkę na punkt montowania, ale wiadomo o co chodzi. 😉

Po tym zabiegu SSH jest dostępne po uruchomieniu systemu, zalogować się można tradycyjnie przy pomocy użytkownika pi i hasła raspberry.

Wyłączenie SSH w domyślnej wersji podyktowane było względami bezpieczeństwa (tu link).

Z kronikarskiego obowiązku: w Raspbianie bazujązym na Jessie wiele się nie zmieniło. Swap nadal domyślnie włączony i zarządzany w dziwny sposób (nie /etc/fstab), journal na FS obecny, sterowanie LED i odczyt temperatury bez zmian.

3 powody dla których nie kupię Raspberry Pi 3

Blisko trzy lata temu (ależ ten czas leci) pisałem, dlaczego nie kupię Raspberry Pi. Parę dni temu opublikowana została specyfikacja Raspberry Pi 3. I też widzę, że nie kupię, choć cieszę się na płytkę z 64 bit ARM. Powody są trzy:

  1. Brak portu SATA. Najmniej istotny, bo można podłączyć dysk po USB (i raczej tak zrobię), ale nadal trochę boli.
  2. Tylko 1 GB RAM. Mało. Na desktop – przeraźliwie mało. IMO minimum dla desktopa na dzień dzisiejszy to 2 GB RAM. Zresztą skoro mocniejszy procesor, to i serwer można by bardziej obciążyć, a tu RAM też się przydaje.
  3. 100 Mbps ethernet. Dla rozwiązań typu NAS 100 Mbps to zdecydowanie za mało.

Co zamiast Raspberry Pi 3? Czaję się na najwyższy model Pine 64 czyli PINE64+ 2GB. Co prawda też nie ma SATA, ale ma 1Gbps kartę sieciową oraz 2 GB pamięci RAM. I ma kosztować przy tym 29 dolarów + 12 dolarów za wysyłkę do Polski.

Wady Pine64? Wspomniany brak SATA, jeśli ktoś potrzebuje USB i bluetooth, to musi dołożyć kolejnych 10 dolarów, albo kupić wersje na USB (2,5 w Chinach) i zająć oba porty. No i trzeba poczekać do maja.

UPDATE To wszystko oczywiście z mojego punktu widzenia, który można streścić „małe, tanie, mocne i Linux działa”. Z punktu widzenia kogoś, kogo bardziej interesuje zabawa elektroniką będzie to wyglądało zupełnie inaczej, bo w grę wchodzi choćby łatwość supportu czy dostępność rozszerzeń.

Warto też przeczytać komentarz Piotra (pierwszy) – Odroid wygląda nieźle (jak zwykle zresztą), choć jest nieco droższy (jak zwykle zresztą). Patrz porównanie. Czyli ciekawych alternatyw dla Raspberry Pi 3 jest więcej.

Dowiedziałem się też o istnieniu dystrybucji Armbian. Autorzy nie piszą niestety zbyt wiele, ale wygląda interesująco i wspiera wiele płytek. Oferuje świeży kernel i wspiera Debiana (Wheezy, Jessie) oraz Ubuntu Trusty.

O grach

Kilka dni temu dotarła do mnie informacja o wydaniu nowej wersji gry NetHack, po 12 latach przerwy. Wzięło mnie na wspominki, więc z tej okazji wpis o grach. Po pierwsze Nethack czyli gra typu roguelike. Pamiętam zakład z M., który z nas pierwszy przekroczy barierę miliona punktów. Mam save z wizardem, który ma ponad milion punktów (sprawdziliśmy komisyjnie wychodząc z gry). Pewnie już nie włączę, bo wyszedłem z wprawy, więc zapewne zginąłby po kilku-kilkunastu ruchach. Tak czy inaczej „rogaliki” były fajne. Oczywiście bez save scummingu! A najważniejszy był właśnie NetHack.

Kolejna ważna gra, to CounterStrike. W wersji 1.5. I garażowe (i nie tylko) LAN party. W przeciwieństwie do innych FPS był dość „wolny” i dość taktyczny. Bardziej drużynowy, mniej oparty na refleksie. Trochę mi zamiłowanie do tego typu rozrywki zostało, o czym dalej. No i efektem ubocznym gry w CSa była nauka Perla – mieliśmy autorski system generowania statystyk, który momentami wyprzedzał to, co oferowały dostępne gotowce (ale tylko momentami, poza tym, był dostosowany do naszych „klanów”). Dziś pewnie przestraszyłbym się, gdybym zajrzał w kod, ale było to pierwsze praktyczne użycie Perla. I działało całkiem fajnie. IIRC z braku „prawdziwego” serwera WWW dystrybucja HTMLi odbywała się mailowo w plikach zip.

A dziś? Pogrywam czasami, choć coraz rzadziej, w drobiazgi z Humble Bundle. Godny odnotowania tytuł: Faster Than Light, który jest określany jako rougelike-like (IMO niezupełnie słusznie, choć jakieś echa w klimacie są). Poza sympatią do roguelikeów zostały mi nadal związki gier z programowaniem, np. bardzo spodobał mi się pomysł CodeCombat, czyli gry i jednoczesnej nauki programowania.

Numer jeden i chyba jedyna gra, w którą obecnie gram aktywnie, to World of Tanks. Trochę rozwinięcie CSa – jest pod wieloma względami podobny – i „wolny”, i taktyczny, i drużynowy. Choć niezupełnie FPS. Jest też parę trybów rozgrywki. Ostatnio odkryłem nowe warstwy: po pierwsze gra w klanie (amatorski, for fun, średnia wieku pewnie 30+), po drugie gra z ludźmi, którzy grają… nieźle. Nie jest to poziom ESL, ale jak się zobaczy w praktyce dobre rozstawienie, taktykę i wykonanie, to gra nabiera zupełnie nowego wymiaru. Polecam.

Ostatnią ciekawą grą, o której się dowiedziałem jest Minecraft Pi, czyli serwer Minecrafta przygotowany do uruchomienia na Raspberry Pi (i zapewne podobnych komputerach z ARM). Kolejny związek z programowaniem – ma uczyć programowania w języku Python. Niezupełnie tylko rozumiem, jak jest z licencjonowaniem i klientem – odwiedziłem sklep z grami i jest tam klient Minecrafta, ale czy jest on wymagany, żeby grać w klony typu Minecraft Pi? Trochę dziwi mnie brak alternatywnych, otwartych klientów, szczególnie na Linuksa. Chyba, że źle szukałem (przyznaję, pobieżnie)? W każdym razie jest plan, żeby także tą grą się pobawić, tylko to raczej przy jakimś dłuższym urlopie…

Tyle o grach komputerowych. O niekomputerowych innym razem.

Raspberry Pi Zero

Pojawił się na rynku nowy mini komputer z procesorem ARM. Raspberry Pi Zero, bo o nim mowa, posiada:

  • CPU BCM2835 1GHz (1 rdzeń)
  • 512 MB RAM
  • slot micro-SD
  • 1 micro USB
  • 1 mini HDMI
  • GPIO zgodne z poprzednimi modelami (wymagana przejściówka z pinami)

Największe zalety to jednak minimalne wymiary i równie minimalna cena. Ma ona wynosić $5 (zobaczymy ile w praktyce w Polsce).

Raspberry Pi Zero

Źródło: https://www.raspberrypi.org/

Choć uważam, że od Raspberry Pi ogólnie ciekawsze są Banana Pi czy Orange Pi, to ten produkt mi się nawet podoba. Świetna cena, możliwości porównywalne z pierwszymi Raspberry (OK, trzeba dołożyć kartę sieciową na USB, ale sensowne zasilanie to i tak aktywny hub USB, a rpi z tego co pamiętam i tak miało ethernet over USB).

Sprzęt trochę słaby, patrząc z punktu widzenia bardziej linuksowego/serwerowego, (słaby procesor, mało RAM), ale Cena Czyni Cuda. Poza tym, z tego co widzę, celowany bardziej w mniejsze projekty, wręcz wearables, więc niezupełnie fair byłoby oceniać go z perspektywy linuksowo/serwerowej. Co ciekawe, nowy produkt będzie dołączony do grudniowego wydania MagPi.

Największa wada to oczywiście nadal architektura procesora. Jest to dokładnie ten sam model, co w pierwszych modelach rpi, tylko wyżej taktowany, co oznacza, że albo korzystamy z wynalazków typu Raspbian, albo z architektury armel w np. Debianie (i wydajność cierpi), bo niestety armhf nie zadziała.

Orange Pi – nowe modele

Przegapiłem premierę, ale warto wiedzieć, że pojawiły się dwa ciekawe nowe modele w rodzinie Orange Pi.

Pierwszy z nich, Orange Pi Plus, to odpowiedź na wyższe modele konkurencji. Ma… w zasadzie wszystko. Jest port SATA, jest mocny procesor (cztery rdzenie 1,6 GHz), jest Wi-Fi, są 4 porty USB 2.0, odbiornik podczerwieni i wbudowany mikrofon. W końcu jest wbudowana pamięć flash (8GB). Jedyna słabość to ilość wbudowanego RAM – nadal 1 GB, więc na desktop trochę mało, tj. można zrobić, ale trzeba będzie oszczędzać. Cena: około 50 USD z wysyłką. Zdjęcie Orange Pi Plus z opisem poniżej:

 Orange Pi plus

 Źródło: http://www.orangepi.org/orangepiplus/H3shuoming.jpg

Drugi model to Orange Pi PC. Dość okrojony, wygląda na alternatywę dla Raspberry Pi 2. Pierwsze co rzuca się w oczy to mocny procesor, ten sam co w ww. modelu. Pozostały wbudowany mikrofon oraz czujnik IR, ale zniknął port SATA, nie ma wbudowanego Wi-Fi, ani pamięci flash, a ethernet to – podobnie jak w Raspberry Pi – 100 Mbps. Standardowy 1GB RAM. Główny atut? Oczywiście cena. Ok. 23 USD z wysyłką, lub 15 USD + ok. 3 USD wysyłka. Zdjęcie Orange Pi PC wraz z opisem poniżej:

Orange Pi PC

Źródło: http://www.orangepi.org/orangepipc/images/orangepipc_info.jpg

W obu przypadkach można uruchomić Linuksa, w przypadku Orange Pi Plus dostępny jest Debian. Chipset ten sam, więc przypuszczam, że pojawienie się Debiana na model PC jest jedynie kwestią czasu.

Przyznaję, że rozważam zakup Orange Pi Plus i wymianę Dockstara – działa dobrze, ale 128 MB RAM zaczyna trochę boleć.

Rodzina Orange Pi

Jakiś czas temu zachwalałem Banana Pi. Twórcy w międzyczasie wypuścili Banana Pro, z m.in. dodaną kartą wifi. Nie pisałem, bo cena była mało atrakcyjna (obecnie wygląda lepiej ok. 50 USD), a zmiany tak naprawdę kosmetyczne.

Dziś dowiedziałem się o Orange Pi. Kolejny chiński produkt, który można określić mianem klona klonu Raspberry Pi. 😉

Poniżej zdjęcie jednej z wersji Orange Pi (wersja Mini):

Orange Pi Mini - front

Źródło: http://www.orangepi.org/orangepimini/minijieshao1.jpg

Tak naprawdę są to trzy produkty: Orange Pi zwykłe, mini i plus.

  • Zwykłe Orange Pi jest dłuższe od Banana Pi o 20 mm, za to dodatkowo ma kartę wifi oraz wyjście VGA. Cena: ok. 50 USD.
  • Orange Pi Plus ma ten sam rozmiar co zwykła wersja, nie ma wyjścia VGA, ale za to wyposażona jest w czterordzeniowy procesor A31S ARM. Brak portu SATA. Cena: ok. 70 USD.
  • Orange Pi Mini jest najbardziej zbliżone do Banana Pi – jedynie o 2 mm dłuższe i o 1 mm węższe. Od Banana Pi różni się głównie posiadaniem karty wifi. Cena: ok. 40 USD, czyli praktycznie tyle samo, co Banana Pi.

Wszystkie wersje posiadają port SATA, wszystkie mają 1 GB RAM. Producent twierdzi, że działa Android, Debian, Ubuntu itp. Ceny z AliExpress dla wersji z free shipping.

Wygląda ciekawie, choć dość niechlujnie (choćby widoczne literówki na opisach na zdjęciach). Sam pewnie nie kupię, a przynajmniej nie w najbliższym czasie, ale jakby komuś wpadło w ręce, to poproszę test i podzielenie się linkiem do testu.

UPDATE: Na portalu LinuxGizmos.com pojawiło się ciekawe zestawienie przyjaznych Linuksowi SoC na rok 2015. Polecam lekturę.

UPDATE 2: Wbrew temu, co napisałem, Orange Pi Plus nie posiada portu SATA.