Niedawno na moich social mediach zwróciłem uwagę na to, że od dłuższego czasu nie pojawił się żaden artykuł dotyczący wyświetlaczy. Zaproponowałem w ankiecie dwa modele, które mam pod ręką i zwyciężył OLED z kontrolerem umożliwiającym 16-stopniową skalę szarości. Dzisiaj zacznę temat od strony teoretycznej, może nawet od takiego lekkiego felietonu 🙂
Taki OLED ze skalą szarości możesz kupić u mnie.
Spis treści całego cyklu o OLED na SSD1327:
OLED ze skalą szarości na SSD1327 cz.1
OLED ze skalą szarości na SSD1327 cz.2
Jak przygotować obraz dla wyświetlacza LCD lub TFT?
OLED ze skalą szarości na SSD1327 cz.3
Wyświetlacze OLED
Wyświetlacze te od wielu lat cieszą się niesamowitą popularnością. Może nie aż tak dużą, jak klasyczne 16×2, ale nadal sporą. Ich ogromną zaletą jest kontrast. Czym on jest?
Kontrast to w skrócie różnica w jasności między najciemniejszym możliwym punktem a najjaśniejszym. W klasycznych wyświetlaczach z podświetleniem jak LCD, TFT, czy IPS kontrast ten nie robi takiego wrażenia. Spowodowane jest to tym, że podświetlenie w takim LCD działa na całą matrycę jednocześnie. Chcąc mieć czarny(ciemny) piksel, po prostu blokuje się przepływ światła z podświetlenia co nie zawsze jest pełnym ograniczeniem przepuszczanego światła.
OLED nie posiada podświetlenia. Każdy z jego pikseli jest osobną diodą, która emituje własne światło. Co się dzieje, gdy ma być czarny piksel? Po prostu nie świeci! Dzięki temu można uzyskać niemal doskonałą czerń i to widać dosyć wyraźnie. Widać już w szczególności mając dwa ekrany w różnych technologiach obok siebie.
Takim miejscem, gdzie możesz zauważyć tę różnicę jest na przykład każdy market z elektroniką konsumencką. Telewizory OLED stojące na wystawie wyglądają obłędnie. Pomijam już to, że mają specjalne filmy prezentacyjne, aby ten kontrast jeszcze bardziej wyciągnąć. Sprawia to, że obraz takiego telewizora OLED jest “żyletą”.
W naszych nieco bardziej hobbystyczny OLEDach jest podobnie. Może nie uzyskamy tej “żylety” bo mamy zbyt małą rozdzielczość, ale obrazy wyświetlane przez te szkraby są dostatecznie ładne.
Bardzo ważnym aspektem wyświetlaczy OLED jest tak zwane “wypalanie”. Diody organiczne mają to do siebie, że tracą swoją jasność wraz z czasem świecenia. Warto sprawdzać w dokumentacji, jaki to jest czas. Podawany jest najczęście okres do obniżenia się jasności o 50%. Różni się to w zależności od koloru. Generalnie jest to między 10, a 100 tys. godzin.
Jak temu zaradzić? Niestety nie da się. Jednak jest pewna sztuczka na oszukanie ludzkiego wzroku. Otóż nasze oczy widzą WZGLĘDNE różnice. Oznacza to tyle, że jeśli pokażesz komuś najpierw wyświetlacz o jasności 300 nits, a później 400 nits to nie będzie w stanie powiedzieć, który był jaśniejszy. Tym bardziej, jeśli mamy do czynienia z jeszcze większymi jasnościami. Jeśli pokażesz dwa takie wyświetlacze obok siebie – zadanie od razu staje się proste.
Tę wadę wzroku należy wykorzystać przy projektowaniu layoutu aplikacji. Trzeba w miarę możliwości wszystkie pixele zużywać równomiernie. Wtedy mimo spadającej jasności nie będą widoczne różnice między pikselami, a w istocie otrzymamy złudzenie braku wypalania.
Stąd w kontrolerach OLED pojawiają się różne sprzętowe wspomagacze graficzne na przykład do scrollowania 🙂 Takie przesuwanie pikseli można ustawić jako wygaszacz.
Skala szarości
No właśnie. Proste OLEDy jak na sterowniku SSD1306 mogą wyświetlić tylko 2 kolory: czarny i kolor piksela(biały, niebieski, żółty itp.). Można regulować ich jasność, ale regulacja ta jest aplikowana na całą matrycę pikseli. Przez to, aby pokazać jakieś cienie w obrazkach trzeba posługiwać się dziwnymi sztuczkami graficznymi i “kratkowaniem”.
Na wielkim białym jak piksel OLEDa koniu wjeżdża kontroler SSD1327. Warto zerknąć w jego dokumentację, którą się teraz zajmę.
Skala szarości obsługiwana przez ten kontroler to nic innego jak kontrola jasności pikseli, lecz nie dla całej matrycy, a dla każdego z punktu z osobna.
SSD1327
Opisując ten kontroler będę odwoływał się do znanego SSD1306 z najpopularniejszych OLEDów.
Już na wstępie kontroler ten może obsłużyć większe matryce. Maksymalnie 128×128 pikseli. W SSD1306 było to max 128×64 px. Wychodzi dwa razy większa matryca. Nawet testowy wyświetlacz ma nieco większą rozdzielczość bo 128×96 px.
RAM, w którym przechowuje się aktualnie wyświetlany obraz ma 128x128x4 bity. Ohoho czym są te magiczne 4 bity?
Jest to nic innego jak kolor piksela. Jest on 4-bitowy, więc mamy od razu informację, że tych kolorów każdy piksel może przyjąć 16. Te kolory to nic innego jak właśnie skala szarości.
Co ciekawe 4 bity w informatycznym języku mają swoją nazwę! Zrobiłem ostatnio taką zagadkę na Facebooku i Instagramie. Okazuje się, że znacie tę nazwę. Te 4 bity to fachowo po angielsku nibble. W języku polskim jest to tetrada. Jednak myślę, że “półbajt” jak niektóre osoby sugerowały będzie również odpowiednim słowem. Brawo dla wszystkich poprawnie odpowiadających 🙂
No dobra, skoro jeden piksel = 4 bity to czy RAM jest poszatkowany na dostęp 4-bitowy? NIE! Jest to klasyczny RAM z 8-bitowym(bajtowym) dostępem. Po prostu w jednej komórce trzymana jest informacja o dwóch sąsiednich pikselach. Można to zauważyć na rysunku RAMu.
Brzmi nieźle, bo dane są upakowane, co oznacza nieco mniej transmisji dla każdego z pikseli. Jest tylko jedna pułapka! Jak zmienić kolor jednego piksela, jednocześnie nie ruszając tego drugiego w bajcie? Trzeba najpierw odczytać wybrany bajt z pamięci RAM wyświetlacza, podmienić właściwy piksel i odesłać cały bajt. Dokłada do sporo roboty, jeśli nie buforujemy całej ramki w pamięci mikrokontrolera.
Jak szybko można policzyć, aby zbuforować wyświetlacz 128×96 pikseli potrzebujesz 128*96*4 bity = 4096 bajty RAM. Nie jest to jakoś sporo dla STM32. Powinno się dać coś z tym zrobić.
Jeśli chciałbyś jednak nie korzystać z buforowania, to potrzebujesz czytać dane z RAM wyświetlacza. Kontroler SSD1327 może współpracować z kilkoma interfejsami. Najczęściej w obiegu możemy spotkać gotowe moduły na PCB z wyprowadzonym I²C. Jednak kiedyś pracowałem na tym kontrolerze z SPI i tutaj jest mała pułapka. Przy SPI nie ma możliwości czytania danych z kontrolera OLED. Wtedy w grę wchodzi tylko buforowanie w RAM MCU lub korzystanie z wyświetlacza w taki sposób, aby nie zapisywać pojedynczych pikseli.
Z innych różnic względem SSD1306 można zauważyć, że SSD1327 wymaga zewnętrznego zasilania dla matrycy. Nie posiada on wewnętrznej pompy ładunkowej, więc trzeba mu podać 8÷18 V na odpowiednie piny. Co ciekawe zasilanie to ma wpływ na jasność, więc jednocześnie również ma wpływ na wypalanie się pikseli. Zasilanie zewnętrzne jest załatwione na PCB OLEDa poprzez prostą przetwornicę.
Prędkości interfejsów
Konkretne już wartości prędkości i czasów oraz klatki na sekundę sprawdzę w kolejnych wpisach jak już będę miał bibliotekę. Jednak mogę spróbować policzyć jak to będzie wyglądało w teorii.
Wyświetlacz z mojego sklepu wyprowadzony ma jedynie interfejs I²C. Z dokumentacji wynika, że zegar na nim może mieć maksymalnie 400 kHz. Bez szału, ale lepsze to niż 100 kHz. Założę się, że spokojnie da się to podkręcić.
Pomijając czasy na przygotowanie danych i ustawienia wskaźnika w RAM wyświetlacza, używając DMA do wysłania jest 4096 bajtów. Przy taktowaniu zegara 400 kHz, jeden bajt wysyłany jest w czasie 20 µs. Czyli cała ramka przejdzie w około 82 ms. Trochę długo, co?
Wysyłając w kółko bez opamiętania całe ramki wyjdzie lekko ponad 12 Hz. Trochę mało dla płynnego odtwarzania animacji. I²C słabo się do tego nada.
Co by było na SPI? Zegar pozwala na komunikację 10 MHz. Jest to zdecydowanie fajniejsza częstotliwość. 100 ns na bit, 800 ns na bajt, więc na ramkę wychodzi 3,2 ms. Da to około 312 Hz, więc zapas do płynnej animacji przy 25÷30 Hz jest ogromny.
Lepiej byłoby mieć dostępne SPI do szybkich zmian, ale na I²C też się da wiele pokazać. Pokażę Ci to w następnym artykule!
Podsumowanie
Trochę poteoretyzowałem nad naszym bohaterem. W następnych wpisach pokażę już kod i działanie tego wyświetlacza. Chwilę po napisaniu tego posta już uruchomiłem pierwszą wersję działającej biblioteki.
Jeśli artykuł Ci się spodobał, możesz mnie wesprzeć kupując coś u mnie 🙂 https://sklep.msalamon.pl/
Jeśli zauważyłeś jakiś błąd, nie zgadzasz się z czymś, chciałbyś coś dodać istotnego lub po prostu uważasz, że chciałbyś podyskutować na ten temat, napisz komentarz. Pamiętaj, że dyskusja ma być kulturalna i zgodna z zasadami języka polskiego.
Spis treści całego cyklu o OLED na SSD1327:
OLED ze skalą szarości na SSD1327 cz.1
OLED ze skalą szarości na SSD1327 cz.2
Jak przygotować obraz dla wyświetlacza LCD lub TFT?
OLED ze skalą szarości na SSD1327 cz.3
Wyniki konkursu
Czas na wyczekiwane wyniki konkursu! Jeeeny wybór jak zwykle jest trudny i mam wrażenie, że krzywdzę pozostałych, którzy nie wygrali 🙁 Podobają mi się wszystkie pomysły i z pewnością będę realizował je!
Jednak ktoś musi wygrać. Oto trzy zwycięskie komentarze:
1. Radee
Szyfrowanie komunikacji AES128
Super temat! Zapomniałem o tym, że STMy mają sprzętowy moduły RNG. Dodatkowo jest biblitoteka crypto od ST to można ją potestować.
2. Micro
Bardzo chciałbym zobaczyć jakiś artykuł o wykorzystywaniu pamięci zewnętrznej np. FLASH / RAM , z pomocą np. quad / dual SPI , może to być ciekawy temat bo czasami może brakować miejsca na program i dane w pamięci podręcznej, a poza tym może coś o wbudowanych interfejsach szeregowych do wyświetlaczy np. LCD parallel interface, 8080/6800 modes, chyba większość mikrokontrolerów, a przynajmniej wiem że F4 i H7 takie posiadają i ciekawą możliwością jest wykorzystanie sprzętowej komunikacji w samym mikrokontrolerze, bo skoro jest to dlaczego by nie skorzystać. Takie moje pomysły może coś się przyjmie ? . Sam jestem początkujących i za dużo o nich nie wiem dlatego uważam że może inni też byliby ciekawi coś o tym się dowiedzieć.
Może już trochę za późno, ale mógłbyś zrobić o interfejsie (8- to 14-bit parallel camera interface), który można znaleźć w stm32f4 (w moim przypadku stm32f446re) i stm32H7 (w moim przypadku stm32H745zi) z użyciem np kamery OV7670 (8-bit ), wiem że jest kilka przykładów z jej użyciem na arudino programowo, ale nie wiem czy są na stm32 z wykorzystaniem tego interfejsu.
Sprzętowa obsługa TFT czy kamery to świetna sprawa. To jest coś, czego w Arduino nie ma, a warto poznać! Przydałoby się przy okazji jakieś Discovery w sklepie 🙂
3. Marcin Wk
Mareusz! IoT coraz śmielej wchodzi do życia codziennego. Dlatego to jest poważny argument żeby zrobić wpis a nawet serie wpisów o Ethernecie i STM32 ? co prawda IoT raczej kojarzy się z WiFi, dlatego mam drugi argument: widziałem wiele płytek Nucleo-144 z portem Ethernet, także w Twoim sklepie, a informacji na temat tego interfesu w internecie jest niewiele, czas to zmienić ? obecnie buduje/programuje automatykę do mojego przyszłego domu do którego mam nadzieje się wprowadzić do końca roku. Sterownik oparty o STM32F4 a łączność ze światem z użyciem dobrze znanego enc28j60. W nucleo 64 zaczyna mi juz brakować gpio, więc myśle o nucleo144 i wykorzystanie wbudowanego ethernetu ?
Jestem ciekaw czemu tak mało osób opisuje swoje boje z Ethernetem na STM32. Będę musiał to sprawdzić! Zarówno te zewnętrzne jak W5500 jak i wbudowane w Nucleo-144.
Gratuluję wszystkim świetnych pomysłów!
Zwycięzców proszę o zgłoszenie się do mnie, najlepiej mailowo: mateusz@msalamon.pl w celu ustalenia wysyłki nagród.
Za rok mam nadzieję, że uda mi się przygotować naprawdę solidne nagrody 😉
2 komentarze
Mruczek · 22/07/2020 o 21:58
Masz błąd w linku w pierwszym banerze (do wyświetlacza w sklepie). Brak dwukropka po HTTPS i przeglądarka miesza link.
http://https//sklep.%5B…].pl/[…]
Mateusz Salamon · 22/07/2020 o 22:05
Dzięki! Poprawione – nie wiem jak to http:// się wcisnęło przed prawidłowy link 😀