Zaloguj
Jedynym wymaganiem, stawianym modułom Arduino, z których chcemy budować cienkiego klienta jest możliwość połączenia się z Internetem, dlatego też wybrano do prezentacji dwa moduły, wyposażone w interfejs Wi-Fi. Dodatkowo, z uwagi na ergonomię obsługi, dobrze jest wybrać moduł, który pozwala na obsługę ekranu dotykowego i wyświetlacza o relatywnie dużej rozdzielczości.
Czym jest maszyna typu thin client
Thin Client to minimalistyczny sprzęt, który zapewnia interfejs użytkownika łączący się z rzeczywistą maszyną przetwarzającą tam, gdzie użytkownik pracuje. Taki system można realizować np. używając taniego laptopa z VNC lub RDP do połączenia się do serwera Windows. Tutaj laptop jest cienkim klientem.
Cienki klient nie wymaga urządzenia o dużej mocy obliczeniowej, ponieważ wszystkie zadania są uruchomione na serwerze, dlatego nazywa się właśnie cienkim. Rozwiązanie to nie jest niczym nowym, w ubiegłym stuleciu często stosowano takie systemy w postaci terminali i komputerów klasy mainframe. Terminal to też cienki klient.
Architektura taka ma wiele zalet, jeśli może być wykonana z taniego sprzętu. Ale jak tani może on być? Sun Microsystems Sun Ray jest dobrym przykładem Thin Clienta z ubiegłego wieku, ma nawet specjalny, tani procesor o niskim poborze mocy, jednak koszt jednostkowy takiej maszyny jest nadal bardzo wysoki. Następnym przykładem może być Intel, który wprowadził tanie procesor ATOM. Wielu dostawców komputerów, w tym cienkich klientów (np. HP, Dell itp.) korzysta z CPU ATOM, dostarczając rozwiązanie typu Thin Client. Jednak nadal komputer taki wymaga podłączenia monitora, klawiatury i myszy. Po przeliczeniu kosztów tych komponentów, całkowity koszt jest niewiele niższy niż w przypadku standardowego komputera stacjonarnego.
Jak zatem uzyskać realną oszczędność? Co powiecie na użycie do zbudowania cienkiego klienta jakiegoś modułu oprogramowanego w Arduino IDE, który obsługuje Wi-Fi i jest wyposażony w ekran dotykowy? Tak niski koszt powinien być wystarczający, aby nazwać tego klienta rzeczywiście cienkim.
W pierwszej kolejności przyjrzyjmy się wymaganiom poszczególnych elementów, protokołów i interfejsów. W dalszej części artykułu zaprezentowano przykładowe realizacje tego rodzaju systemu.
Protokół komunikacyjny
Wiele firm próbowało opracować własnego Thin Clienta, więc pojawiło się wiele protokołów komunikacyjnych. Sun Ray ma własny protokół komunikacyjny SRSS umożliwiający dostęp do serwera, a następnie obsługuje protokół RDP. RDP jest powszechnym protokołem dla zdalnego łączenia się do komputera z systemem Microsoft Windows, ale serwer RDP nie jest łatwy do uruchomienia na innym systemie operacyjnym.
VNC to wspólna nazwa szeregu różnych zdalnych programów, które używają protokołu RFB do komunikacji między klientem a serwerem. Ponieważ jest to protokół open-source, strona serwera może być zaimplementowana w różnych systemach operacyjnych, takich jak Linux, MacOS i Windows. Po stronie klienta aplikacja również zaimplementowana może być w różnych środowiskach desktopowych i mobilnych. VNC ma nawet klienta w wersji Java i może działać w przeglądarce internetowej. Ponieważ protokół RFB jest open source, można go rozszerzyć na dowolne platformy. Links2004 zaimplementował klienta VNC na platformie Arduino i to jest punkt wyjścia tego projektu.
Wąskie gardła
Klient VNC stworzony przez Links2004 jest odpowiedni dla normalnego wyświetlacza Arduino z kontrolerem ILI9341. Ale ILI9341 ma rozdzielczość zaledwie 320×240. Jest ona znacznie niższa niż rozdzielczość normalnego monitora biurkowego. Najnowszy menedżer okien dla współczesnego systemu operacyjnego zakłada, że mamy znacznie większą rozdzielczość.
Niektóre większe wyświetlacze dla Arduino mogą mieć rozdzielczość 800×480, co wystarczy do prostej zdalnej obsługi GUI. Jednak większy wyświetlacz wprowadza kilka wąskich gardeł:
- Częstotliwość zegara danych interfejsu SPI w ESP32 może osiągnąć maksymalnie 80 MHz, co oznacza, że częstotliwość odświeżania pełnej klatki wynosi około 80 MHz / (800×480×16-bitowy kolor), czyli 13 klatek na sekundę;
- Prędkość transmisji danych przez sieć bezprzewodową, zarówno ESP32, jak i Pico W, może jest jedynie nieco wyższa niż 1 Mb/s. Jeśli używa się kodowania VNC Hextile, to pozwala to na osiągnięcie tylko 6...7 klatek na sekundę, jeśli oczekujemy ciągłego odświeżania przynajmniej części ekranu.
Potrzebny jest więc szybszy interfejs do wyświetlania obrazu, jak i lepszy sposób kodowania danych VNC, aby przezwyciężyć wąskie gardła, na jakie napotyka się w tego rodzaju aplikacjach.
Szybszy interfejs wyświetlania
W rzeczywistości typowe wyświetlacze o rozdzielczości 800×480 rzadko mają tylko interfejs SPI. Na ogół pracują one z takimi interfejsami jak:
- 8-bitowy interfejs równoległy – zawiera zbyt wiele operacji bitowych podczas rzeczywistego użytkowania i ma tylko połowę przepustowości 16-bitowego interfejsu równoległego, więc preferowany jest tryb 16-bitowy niż 8-bitowy;
- interfejs RGB – jest tańszy, szczególnie w przypadku większego ekranu, ale obecnie tylko ESP32-S3 obsługuje ten interfejs i zużywa sporą część czasu procesora nawet bez aktualizowania treści ekranu;
- szeregowy MIPI – nie jest otwarty i wymaga opłaty licencyjnej za korzystanie z niego, więc nie jest przeznaczony dla hobbystów.
Implementacja ZRLE
Virtual Network Computing (VNC) to graficzny system udostępniania pulpitu, który korzysta z protokołu Remote Frame Buffer (RFB) do zdalnego sterowania innym komputerem. RFB jest bardzo elastyczny, klient i serwer mogą określić kodowanie komunikacji w drodze negocjacji. Links2004 zaimplementował protokoły Raw, RRE, CorRE i Hextile w swoim kliencie VNC dla Arduino. Przez większość czasu serwer wybiera kodowanie Hextile, ponieważ nie jest dostępne lepsze kodowanie dla tej aplikacji. W RFC6143 wciąż nie zaimplementowano jednak kodowania ZRLE. Przedrostek Z w nazwie tego kodowania oznacza, że dane są skompresowane za pomocą zlib. Oznacza to, że przed dekodowaniem wymagana jest dekompresja danych zlib, więc potrzeba więcej zasobów pamięci i większej mocy obliczeniowej. Ale jak wspomniano powyżej, jednym z wąskich gardeł systemu jest przepustowość transferu danych, kompresja danych może pomóc w pokonaniu tego limitu. W przybliżeniu, kodowanie ZRLE może pomóc poprawić szybkość ciągłej częściowej aktualizacji ekranu z 6...7 fps do 15...20 fps. Klienta VNC z obsługą kodowania ZRLE można znaleźć w repozytorium forka arduinoVNC użytkownika moononournation na GitHubie (link znajduje się na końcu tego artykułu). Zastosowanie tej implementacji jest wysoce wskazane.
Serwer VNC
Na rynku są dostępne różne serwery VNC. Wybór konkretnego jest zależny od między innymi systemu operacyjnego, jaki działa na komputerze. W większości przypadków najprostsze, darmowe rozwiązanie będzie dostatecznie dobre, aby je zainstalować i korzystać. Jeśli nie mamy jeszcze serwera VNC i działamy na Linuxie, to wystarczy skorzystać z dockera, aby uruchomić w kontenerze odpowiedni serwer, wpisując w terminalu:
gdzie, jako XXX podstawiamy wybrane przez nas hasło.
Oprogramowanie
Do skompilowania aplikacji na mikrokontroler potrzebne będzie odpowiednie oprogramowanie. Oto lista zasobów, jakie trzeba pobrać i zainstalować, aby z powodzeniem skompilować firmware dla naszego cienkiego klienta:
- środowisko Arduino IDE,
- biblioteki Arduino-ESP32 (jeśli korzystamy z tego układu),
- biblioteki Arduino-Pico (jeśli korzystamy z Raspberry Pico),
- biblioteka Arduino_GFX,
- blblioteka ArduinoVNC od moononournation (zmodyfikowana wersja rozbudowana o kodowanie ZRLE).
Konfiguracja
W pierwszej kolejności wybieramy w menu File w Arduino IDE → Examples → GFX Library for Arduino → ArduinoVNC (rysunek 1).
W przykładzie tym musimy zmodyfikować kilka ustawień. Kluczowym są dane do logowania do naszej sieci Wi-Fi:
const char *SSID_PASSWORD = "HASLO";
gdzie SSID i HASLO to, odpowiednio, jak łatwo się domyślić, SSID naszej sieci Wi-Fi i hasło do zalogowania do niej.
Następnie uzupełniamy dane konfiguracyjne serwera VNC:
const uint16_t VNC_PORT = 5901;
const char *VNC_PASSWORD = "PleaseInputYourPasswordHere";
gdzie VNC_IP, VNC_PORT i VNC_PASSWORD to, odpowiednio, adres IP serwera, port, na którym należy się połączyć z usługą VNC i hasło, potrzebne do połączenia się z serwerem. W pliku keyboard.h można zmienić konfigurację klawiatury, a w pliku touch.h ustawienia ekranu dotykowego.
Wejście myszy
Cienki klient ma 2 główne urządzenia wejściowe: klawiaturę i mysz. W trybie graficznym użycie myszy jest nawet bardziej powszechne niż klawiatury. Jednak najpierw musimy znaleźć urządzenie wejściowe, kompatybilne z naszym systemem. Układy Arduino nie mogą generalnie bezpośrednio używać myszy USB, ale nadal dostępny jest rezystancyjny lub pojemnościowy ekran dotykowy, można używać również analogowego joysticka lub przycisków. Ponieważ obsługa smartfona jest znana niemalże każdemu, ekran dotykowy wydaje się być najbardziej intuicyjny.
W pliku touch.h znajdują się implementacje dla trzech różnych kontrolerów (w nawiasach podano ścieżki do pobrania biblioteki dla danego sterownika).
- FT6X36: https://github.com/strange-v/FT6X36.git
- GT911: https://github.com/TAMCTec/gt911-arduino.git
- XPT2046: https://github.com/PaulStoffregen/XPT2046_Touchscreen.git
Jednak nie jest to zamknięta lista. Nic nie stoi na przeszkodzie, aby dopisać obsługę innego sterownika panelu dotykowego. Jeśli mamy potrzebę dodać obsługę innego kontrolera, wystarczy postąpić z implementacją podobnie, jak ma to miejsce z już zaimplementowanymi sterownikami.
Wejście klawiatury
W przypadku korzystania z interfejsu graficznego, klawiatura jest tylko opcjonalna, jednak szalenie wygodna. Dla Arduino dostępne są dwie klawiatury z interfejsem I²C:
- M5Stack CardKB Mini Keyboard,
- LILYGO BBQ10 Keyboard.
Na portalach, takich jak Tindie można znaleźć większą liczbę projektów klawiatur, jeśli chcielibyśmy samodzielnie takową wykonać.
Wybór urządzenia klienckiego
Istnieją różne urządzenia deweloperskie Arduino z obsługą Wi-Fi, głównie z rodziny ESP32, a także niektóre moduły ESP8266, Raspberry Pi Pico W lub moduły bazujące na RTL8720. W przypadku tego projektu lepiej jest wybrać urządzenie deweloperskie z ekranem dotykowym. Rozmiar ekranu i jego rozdzielczość zależą od rzeczywistego przypadku użycia systemu.
Podłączenie klawiatury przez I²C wymaga portu I²C, więc wybrany układ powinien mieć tego rodzaju interfejs, najlepiej w postaci złącza Grove, z uwagi na to, że takie złącze posiada wybrana klawiatura. Jeśli układ nie posiada I²C, to na przykład w modułach z ESP32 można użyć dowolnej dwójki pinów GPIO, jako portu I²C.
Warto pamiętać jeszcze, że oprócz Wi-Fi, nadal można użyć połączenia przewodowego, ale nie ma na rynku zbyt wielu urządzeń z takim interfejsem. Teensy 4.1 z RJ45 to jakaś opcja, podobnie jak płytki z ESP32 i wejściem Ethernet RJ45. Autor projektu jednak nie testował takiego połączenia.
Raspberry Pi Pico W
Nie jest łatwo znaleźć urządzenie deweloperskie Pico W z dużym ekranem. Arduino_GFX zaimplementowało 16-bitowy interfejs równoległy w Pico W (Arduino_RPiPicoPAR16), dzięki czemu można łatwo znaleźć większy ekran (prawdopodobnie nawet i 4 cale) z modułem dotykowym.
RTL8720
RTL8720 obsługuje interfejs SPI i programowy 8-bitowy interfejs równoległy, dzięki czemu może kontrolować duży ekran, ale nie ma, co oczekiwać zbyt dużej częstotliwości odświeżania wyświetlacza.
Dodatkowo, moduł ten, to chyba jedyna płytka na rynku, dostępna obecnie i spełniająca pozostałe wymagania, która obsługuje Wi-Fi 5 GHz, więc ma pewne zalety w zakresie łączności.
Podsumowanie
Teraz można zaimplementować wszystko, co opisano powyżej, na dowolnej platformie, która oczywiście oferuje odpowiednią wydajność procesora itp. Na tym jednak nie kończą się plany autora, który zapierza wprowadzić dodatkowe funkcje, takie jak:
- zasilanie bateryjne, aby terminal był bardziej przenośny,
- lepszy kontroler klawiatury, na przykład z interfejsem I²C,
- obudowa, pozwalająca na umieszczenie urządzenia na biurku, jak i wygodne trzymanie go w dłoniach,
Ulepszenie obsługi protokołów szyfrowania, aby zwiększyć poziom bezpieczeństwa transmisji, przy łączeniu się z chmurą.
Nikodem Czechowski, EP
Bibliografia:
