Ogólnie rzecz biorąc niezbyt da się użyć tabletu tylko jako wyświetlacza do jakiejkolwiek płytki Arduino opartej o Atmela.
Powodem są zbyt mała ilość pamięci RAM i Flash oraz prawdopodobnie zbyt niska przepustowość transmisji poprzez Bluetooth.
Analizując bardzo pobieżnie:
Monochromatyczny wyświetlacz full HD 16:9 ma 2 073 600 pikseli (2 Mega piksele), dla każdego piksela potrzeba jeden bit pamięci (rezygnujemy ze sterowania jasnością) co oznacza że potrzebujemy 2Mb, czyli 259 200 bajtów czyli w zaokrągleniu przyjmijmy 260kB pamięci. Ani RAM tyle nie ma aby to generować dynamicznie, ani flash aby odczytywać z pamięci bitmapę i nakładać na nią w locie coś innego.
Kolejnym problemem jest prędkość transmisji, zapewne komunikacja z modułem BT odbywa się poprzez USART. Jak już wiemy, traktując tablet tylko jako wyświetlacz musimy przesłać 260kB danych aby zapełnić cały ekran o rozdzielczości full HD. Aby zrobić to w sekundę, potrzebujemy prędkości 260kB/s, tymczasem Atmega oferuje max ok. 1Mb/s czyli jakieś 120kB/s - ponad połowę mniej więc przesłanie całego obrazu zajmie ponad 2s.
Aby obraz na wyświetlaczu był płynny należałoby przesyłać co najmniej 25 obrazów na sekundę, tymczasem my przesyłamy 1 obraz na 2 sekundy.
Mowa póki co o rozdzielczości FHD 16:9 czyli 1920x1080 i obrazie monochromatycznym bez sterowania głębią "koloru" czyli w tym przypadku szarości, a Kolega na filmiku obiecuje 8k (ok. 33 Mpix) i jeszcze pracę z dotykiem.
Do FHD trzeba byłoby użyć SPI a nie USART do przesyłania danych ale to i tak nie ma sensu bo Atmega nie ma wystarczającej ilości pamięci zarówno RAM jak i Flash, a mówimy tylko o pamięci potrzebnej do wyświetlenia monochromatycznego obrazu, a przecież pamięć potrzebna jest jeszcze do normalnej pracy, akwizycji i obróbki danych.
Dlatego nie da się traktować tabletu tylko jako wyświetlacza dla modułu Arduino opartego o Atmegę.
W ogóle używanie wyświetlaczy o dużych rozdzielczościach z takimi procesorami nie jest możliwe bez względu na to czy to będzie tablet czy sam wyświetlacz.
Takie rozwiązanie jest możliwe tylko gdy to np. tablet czy inny komputer o wystarczającej mocy obliczeniowej i zasobach sprzętowych będzie sercem systemu, a Arduino tylko prostym interfejsem wykonującym pomiary i wysyłającym je dalej do obróbki i wyświetlenia. Tyle tylko że wówczas tablet nie jest wyświetlaczem do Arduino, tylko Arduino jest modułem pomiarowym do tabletu.
Dodatkowo aby pomiary miały sens, trzeba je wykonywać zgodnie ze sztuką, czyli zachować stałe interwały czasowe pomiędzy pomiarami, a następnie wyniki uśrednić i dopiero w takiej postaci wysłać do dalszej obróbki i wyświetlenia.
Dlaczego tak? Załóżmy że chcemy mierzyć napięcie sieci 230V i odświeżać wynik co 10s, wpadamy na światły pomysł - mierzymy co 10s, wysyłamy i z głowy - przez 10s Arduino odpoczywa. Nic bardziej mylnego - jeśli w chwili pomiaru napięcie w sieci wynosi 230V, następnie przez 9s nie ma napięcia i potem znów się pojawi to co zobaczymy na wykresie? Linię prostą, a przecież przez 9s nie było napięcia!
Dokładnie taki sam błąd wystąpi gdy będziemy prezentowali wyniki tylko w postaci suchych liczb.
Gdy pomiary będziemy wykonywali zgodnie ze sztuką, czyli mierzyli np. co 1s, uśredniali 10 pomiarów, a następnie wyświetlali, to fakt zaniku napięcia 230V będzie widoczny na wykresie ponieważ pierwsza próbka będzie miała 230V, a 9 następnych 0V więc średnia wyjdzie 23V i taką wartość odczytamy z wykresu albo zobaczymy w postaci liczbowej.
Wprawdzie to nie 0V, ale i tak widać że coś się wydarzyło.
Takie rzeczy niestety musi wiedzieć konstruktor/programista zanim w ogóle weźmie się za tworzenie czegokolwiek i pisanie programu. Sztuczna inteligencja jak widać jest w tym przypadku bezużyteczna. Ona nie wie, że programista tworzy program który nie ma sensu. Programista chciał kod, to go dostał i tyle.
Kolega podszedł to tematu od końca - zaczął tworzyć program do rozwiązania które w ogóle nie ma racji bytu w tej formie i jeszcze uzyskał "obiecujące" wyniki.
Dlatego jestem spokojny zarówno o swoją pracę, jak i Kolegów programistów.
