GPS albo LCD, sudo albo venv

 Gier i zabaw z GPSem z poprzedniego wpisu ciąg dalszy. Tym razem luźniej powiązane z projektem detektora, więc nie zaliczam do serii. Miałam wczoraj pisać wpis o wyświetlaczu LCD, ale nie skończyłam wtedy z nim pracować, a wolałabym pisać o w miarę zakończonych rozdziałach. O tyle, o ile, więc dziś będzie jednak o niedokończonym.

Zacznę tę historię od strony wyświetlacza LCD, o takiego. Kiedyś coś z nim próbowałam szczęścia i trochę działało, a trochę pisało co drugą linię, zamiast w każdej. Teraz zaczynam od czata GePeTto, który daje mi przykładowy kod. Coś mi w tym kodzie od niego nie pasuje, bo w ogóle pominął jeden pin, który trzeba podłączyć, więc szukam w internecie po nazwie sterownika (Python nazywa to modułem, pewnie poprawnie byłoby nazwać to biblioteką, ale służy ona do sterowania wyświetlaczem, więc idąc za skrótem myślowym zostanę przy tym nazewnictwie). Znajduję stronę internetową wydawcy sterownika, na której jest dość treściwy tutorial. Chcę zainstalować sterownik i zaczynają się przygody.

Okazuje się, że nie mogę ściągnąć sterownika ot tak, wprost, bo system (Raspbian/Debian) nie ufa modułom nie będącym częściami oficjalnych bibliotek Pythona. Mogę albo siłowo obejść blokadę i ściągnąć na siebie w przyszłości nieprzewidywalne konsekwencję, albo pójść bezpieczną ścieżką i zainstalować bibliotekę w piaskownicy, czy raczej wirtualnym środowisku - venv. Bardzo nie chciało mi się wchodzić w zabawy z wirtualnymi środowiskami, tym bardziej, że sterownik miał zapewniać podstawową funkcjonalność, potencjalnie szeroko stosowaną. Parę razy sprawdzałam, czy na pewno nie ma sterownika RPLCD w bibliotekach Pythona, ale nie ma. Wybrałam więc ścieżkę venv.

Venv okazał się nie być taki straszny. Trzeba go uruchomić, mieć pliki do pracy w folderze nadrzędnym względem folderu venv-owego i później można wyjść z wirtualnego środowiska. Szybko przekonałam się, że położenie plików jest ważne i przekładałam je z równoległego podfolderu, ale to drobna niedogodność.

Dzień pracy skończyłam z (nie)wyświetlającym wyświetlaczem. Wyświetlał, ale nie było widać treści, bo nie miałam przy sobie potencjometru do ustawienia kontrastu wyświetlacza ciekłokrystalicznego. Po nocy nie chciało mi się go szukać, znalazłam go następnego dnia, podłączyłam i nie było wątpliwości. Na wyświetlaczu widać treść! Niesiona falą entuzjazmu postanowiłam pójść za ciosem i dać mu coś przydatnego do wyświetlania - współrzędne z GPSa.

Skopiowałam główny plik od GPSa i dodałam do niego wyświetlanie na LCD. Pierwsza próba i drobne poprawki, bo komenda wyświetlania an LCD działa trochę inaczej niż zwykły print(). Poprawione, wygląda dobrze, puszczam jeszcze raz. Brak dostępu do komunikacji seryjnej. No tak, trzeba odpalać z sudo. Brak dostępu do modułu RPLCD, nie znaleziono. No tak, bo z sudo uruchamiam jako root, który widzi ponad venv. Tylko jak mieć ciastko i zjeść ciastko?

Jakiś czas próbowałam zmienić uprawnienia używania protokołów łączności UART/SPI/I2C, żeby można było je uruchamiać bez sudo, ale robiłam to na ślepo za komendami z internetu, które jednak nie przyniosły poprawy. Nawet nie wiem czy coś się zmieniło... Tak czy inaczej błąd występuje nadal. (Po ponad godzinie walczenia z uprawnieniami wygląda na to, ze malina po prostu nie chce pozwolić na ich zmianę. Nie, bo nie...)

Jestem dość solidnie poirytowana tym, że wydawałoby się prosty projekt napotkał nieoczekiwane przeszkody nie do przebycia. Żeby osiągnąć zamierzony efekt musiałabym się silić na cyfrowe druciarstwo. Mam pomysł, ale brzydzę się go wdrażać w taki sposób. To powinno dać się zrobić czysto i elegancko, a nie wytrychami i sztuczkami. Te dopiero w ostateczności. Postaram się użyć rozpędu w pracach do przeróbki innego projektu, ale o tym w następnym odcinku.

Pozdrawiam

~N