LCD HD44870 - WARSTWY - EFEKTY

Witam,

chciałbym zaprezentować dzisiaj wstępną prezentację mojego podejścia do obsługi standardowych i dobrze znanych wszystkim wyświetlaczy alfanumerycznych LCD opartych o sterownik HD44780. Każdy chyba zna te wyświetlacze, każdy wie już chyba o nich wszystko, jednak bywa, że często mamy wiele problemów z ich użytkowaniem we własnych programach w mikrokontrolerach. Oczywiście nie mówię tu o aplikacjach, które po prostu wyświetlają non stop na ekranie to samo np datę, godzinę i temperaturę, bo realizacja takiego celu jest tak banalna, że aż szkoda byłoby poświęcać czas na jej opisywanie. Za to często na forach internetowych ale także w mailach do mnie spotykam się z pytaniami typu: "Jak zrobić proste MENU" na wyświetlaczu alfanumerczynym LCD. Moim zdaniem...



.... w zdecydowanej większości ludzie, którzy zadają takie pytanie posiadają przede wszystkim problem nie z samym zorganizowaniem MENU ale z czymś innym co powoduje zawrót głowy przy podejściu do tego tematu. Wymieniłbym tu dwie główne przyczyny:

1. niestety poważne problemy z obsługą czy to klawiszy, czy pilota czy enkodera - czyli prościej mówiąc jakiegoś urządzenia wejściowego za pomocą którego można byłoby płynnie poruszać się po takim MENU

2. poważne problemy z właściwą organizacją programu tak aby nie był on pisany i aby nie działał w sposób liniowy ponieważ to rozkłada na łopatki większość podejść do każdego MENU. Czyli organizacja tych wszystkich funkcji do obsługi każdego z poziomów MENU

czy nie uważacie, że coś w tym jest ? Można się bowiem spotkać z tzw przepisami na MENU. Owszem niektóre są nawet bardzo fajne - jednak sprowadzają się one często do zapakowania całego projektu MENU w  jakieś sztywne ramy - powiedzmy struktur, które zorganizowane są w tzw listy jednokierunkowe czasem dwukierunkowe. O ile sama idea jest słuszna i to bardzo - to jednak rzadko można spotkać dokładny opis czy porady jak sobie z czymś takim radzić w praktyce, jak później tworzyć funkcje, które nie tylko będą wyświetlać na MENU na LCD - bo przecież to nie jest celem samym w sobie - ale jeszcze jak podłączyć kolejne własne funkcje, które już będą wykonywać jakieś rzeczywiste operacje w urządzeniu. Dodałbym więc tu jeszcze trzecią przyczynę:

3. brak umiejętności posługiwania się realizacją wielu procesów w mikrokontrolerze, które mogłyby działać w tym samym czasie. (A podstawy tego opisuję na łamach swojej pierwszej książki "Mikrokontrolery AVR Język C Podstawy programowania). Tyle, że często jak zauważyłem wiele osób pomija ten rozdział albo też próbę zmierzenia się z opisaną funkcją SuperDebounce() ... jak wielkiego kudłatego jeża uznając, że to tylko dla specjalistów....

W związku z powyższym chciałbym pokazać tutaj na razie pewną nową chyba ideę. Tylko proszę mnie źle nie zrozumieć, nie jest to żadne odkrycie! Takie sposoby są bowiem wykorzystywane już przez wielu programistów a także znanych nawet każdemu z nas programów - że się posłużę nazwą LCD Smartie!!!

Program ten pozwala w piękny sposób na wyświetlanie na takim alfanumerycznym LCD wielu danych z komputera PC za pomocą wielu dowolnych łącz. I nie ważne są tu na tym etapie rodzaje tych łącz, czy to RS232, czy USB czy LPT czy inne

Najważniejsze jest to żebyśmy spróbowali czasem podejrzeć to co inni robią już od dawna i jakie sposoby wykorzystują do tego celu. Właśnie o tym powiem teraz kilka słów.

Zasada działania takich programów opiera się na czymś takim jak WARSTWY (być może znane pojęcie tym osobom, które miewały do czynienia z programami graficznymi czy CADowskimi.) Zanim przejdę do krótkiego omówienia warstw to zwrócę uwagę na jedną bardzo ważną rzecz. Całe wyświetlanie opiera się na tym, że WSZYSTKIE ale to WSZYSTKIE operacje prezentujące na ekranie LCD jakiekolwiek dane nie odbywają się bezpośrednio na nim! Niemożliwe ? Jak to? zadasz może sobie pytania. Ano tak - zasada działania opiera się na tym, że fizyczny kontakt z LCD następuje w najprostszy z możliwych sposobów a jednocześnie najszybszy. Otóż co 20ms do 40ms na ekranie LCD wykonywane są tylko takie schematyczne instrukcje jak niżej i TO WSZYSTKO !!!!!! (zapamiętaj to)

lcd_locate(0,0);
lcd_str( buf_line1 );
lcd_locate(1,0);
lcd_str( buf_line2 );

to dla wyświetlacza 2 wierszowego , zatem łatwo sobie wyobrazić co będzie dla wyświetlacza 4 wierszowego:


lcd_locate(0,0);
lcd_str( buf_line1 );
lcd_locate(1,0);
lcd_str( buf_line2 );

lcd_locate(2,0);
lcd_str( buf_line3 );
lcd_locate(3,0);
lcd_str( buf_line4 );

przy czym buf_lineX zawiera tyle znaków ile kolumn posiada dany wyświetlacz LCD. Przyznasz, że takie operacje wziąwszy pod uwagę czas trwania tych operacji są najszybsze w dostępie do LCD. Nie jest tu broń Boże nigdzie używany rozkaz CLS !!!! .... I takie procedury są wykonywane jak wspominałem np co 20 ms. Widać z tego, że musi być jakiś BUFOR, który przechowuje każdą linię wyświetlacza gdzieś w pamięci RAM programu, który to realizuje. A skoro tak - to znaczy, że wszystkie pozostałe operacje powodujące, że cokolwiek ma się ukazać na wyświetlaczu LCD realizowane są właśnie na tym buforze. Poza tymi wyżej wymienionymi cyklicznie wykonywanymi procedurami NIGDZIE więcej w programie takim nie znajdziemy jakiejkolwiek innej funkcji operującej na LCD jeśli chodzi o wyświetlanie na nim czegokolwiek. (co najwyżej używane zostają czasem funkcje które pozwalają zdefiniować własne znaki użytkownika)

Dobrze skoro już wiemy jak wygląda podstawa takiego działania to już się orientujesz chyba, że te 20ms odpowiada nam za tzw czas odświeżania tego co dzieje się na ekranie LCD. A przecież 20ms a nawet 40ms to bardzo krótki czas. Można zatem wykonać mnóstwo różnych operacji na tym buforze obrazu LCD w pamięci RAM programu - aby wyświetlać przeróżne ciekawe rzeczy na LCD. Zachęcam cię do realizacji dostępu do LCD w ten sposób, nawet bez wykorzystania tego co opiszę dalej.

Kolejnym krokiem na który chciałbym zwrócić uwagę będą teraz działania na samym BUFORZE w pamięci RAM programu. Przede wszystkim czym one się charakteryzują i jakie mają zalety w porównaniu do bezpośredniego wyświetlania na LCD:

1. absolutnie szybszy czas dostępu do pamięci ekranu !
2. możliwość dokonywania zmian w takim buforze nawet z procedur obsługi przerwań !!!! co jest absolutnie nie zalecane a nawet zabraniane jeśli chodzi o wysyłanie fizycznych danych do LCD.
3. możliwość organizacji dużo większej ilości efektów specjalnych ale nie tylko - także dodatkowych buforów - odpowiadających za poszeczególne WARSTWY !!!

tak - na tym etapie dochodzimy do warstw. Bo skoro działamy na pamięci RAM to cóż za problem stworzyć sobie w pamięci RAM nawet tak niewielkich mikrokontrolerów jak AVR kilka buforów roboczych. Przecież jeden bufor dla typowego wyświetlacza LCD 2x16 zabierze nam zaledwie 32 bajty !!! to przecież niedużo. Zatem na takim mikrokontrolerze już jak ATmega88 możemy sobie pozwolić nawet na kilka takich buforów.

Kilka słów wyjaśnienie na temat warstw dla tych, którzy się nie zetknęli z czymś takim w programach graficznych. Otóż wyobraź sobie, że kładziesz przed sobą białą kartkę papieru - to będzie nasz główny BUFOR w pamięci RAM. Rysujemy sobie na niej nasz bufor w postaci 32 prostokątów ułożonych na kształt znaków w wyświetlaczu LCD albo 64 prostokątów jeśli mowa o wyświetlaczu 4x16 ;)

Na razie nie chcemy nic bazgrać w tym buforze - ale mamy ochotę aby pokazać w nim godzinę i datę w prawym górnym rogu. Bierzemy zatem przeźroczystą folię i kładziemy na białą kartkę przykrywając nasze prostokąty symbolizujące bufor 64 znaków wyświetlacza LCD 4x16 - będzie to nasza PIERWSZA WARSTWA. Na tej przeźroczystej folii piszemy w miejscach odpowiadająym znakom wyświetlacza w buforze pod folią cyfry i znaki - które pokazują nam godzinę i datę. Jeśli patrzeć od góry to z uwagi na to że narysowałeś to na folii przeźroczystej mamy efekt tak jakby te znaki były bezpośrednio narysowane na buforze prawda? Zatem bierzemy kolejną folię i także nakładamy ją na tą która już leży - to będzie nasza DRUGA WARSTWA. Tym razem na środku obszaru wyświetlacza rysujemy sobie tylko 8 znaków:

[alarm!]

Następnie bierzemy sobie kolejną folię przeźroczystą i rysujemy inne znaki - będzie to nasza TRZECIA WARSTWA. Przy czym nadal patrząc od góry - widzimy wyświetlacz, na którym widać razem:

1. godzinę i datę
2. napis [alarm!]
3. inny napis na trzeciej warstwie

właśnie ! - nasz program będzie miał za zadanie co 20 ms dokonywać połączenia w dół tych wszystkich warstw tak aby uzyskać jeden spójny obraz dla użytkownika. Posłużę się tu rysunkiem:

Myślę, że rysunek lepiej prezentuje to co starałem się tak żmudnie opisać, przy czym należy pamiętać, że każda warstwa to po prostu kolejny bufor w pamięci RAM. Jak się domyślasz - realizacja połączenia zawartości tych wszystkich buforów nie będzie chyba programowo jakąś trudną rzeczą prawda ? ;)

Co więcej, możemy tak zorganizować te bufory aby nie zajmowały one tyle znaków ile mieści się na całym ekranie danego LCD. Będziemy mogli tworzyć wręcz dowolne okienka. No bo jeśli np komunikaty mają się wyświetlacz w takim okienku jednowierszowym i ośmio-znakowym  zawsze - to po co nam większy bufor. Podobnie na trzeciej warstwie którą za chwilę użyję jako MONITOR dla pokazywania kodów z pilota jakie na bieżąco wciskam żeby wiedzieć jakie klawisze sobie przyporządkować do różnych operacji a chcę żeby zawsze wyświetlało się to na wierzchu ekranu i nie było zasłonięte przez inne warstwy ;)...

nawet więcej za chwilę na filmiku przedstawię przykład, gdzie tak na prawdę będzie użyta jeszcze kolejna warstwa do zrobienia MENU. Tymczasem spójrzmy jak można zorganizować te mniejsze bufory:

Każdy bufor będzie posiadał kilka swoich właściwości takich jak:

1. pozycja X
2. pozycja Y
3. szerokość - width
4. wysokość - height



dzięki temu tak na prawdę będę mógł dokonywać ciekawych operacji z tymi buforami. Wyobraź sobie na przykład, że gdy masz już równo ułożone te 3 przeźroczyste folie i wszystko ładnie wyświetla się na LCD, aż tu nagle łapiesz za środkową - WARSTWA 2 i zaczynasz ją powoli ciągnąć w lewą stronę !!! Co się powinno stać na LCD - zauważysz, że tylko ten napis na warstwie nr 2 zaczyna się przesuwać w LEWO ;) ... Cóż to dla nas za problem zrealizować to programowo skoro mamy do dyspozycji współrzędne warstwy takie jak X,Y oraz szerokość i wysokość ? Przy czym nasza cała biała kartka jest tak na prawdę wielkim VIRUALNYM buforem i w pewnym momencie gdy będziesz ciągnął tę folię z warstwy nr 2 - napis zacznie wychodzić poza obszar wyświetlacza trafiając na białą kartkę czyli nasz virtualny bufor. My natomiast programowo będziemy wyświetlać TYLKO TE ZNAKI z tej warstwy, które jeszcze znajdują się nad obszarem naszego fizycznego BUFORA w pamięci RAM ;) - to też proste zadanie.

Spróbuj teraz pomyśleć, jeśli do takich właściwości każdej warstwy dodamy jeszcze coś tak ciekawego jak własne zdarzenie EVENT, czyli prościej mówiąc procedurę która będzie wykonywana za każdym razem co 20ms gdy będą składane te wszystkie warstwy tuż przed wysłaniem ich na LCD - to nagle okaże się, że uzyskamy wręcz coś na kształt KLASY być może znanej ci z języka C++. No tak coś w tym jest - czuję się wręcz trochę teraz jak archeolog, gdy to piszę ponieważ jeśli ubierzemy taką warstwę w strukturę w języku C i dołączymy do niej wskaźnik do funkcji która ma być wykonywana wraz z jej obróbką - to nagle mamy do czynienia jakby z wykopaliskiem, które stanowi PROTOPLASTĘ mechanizmu, który w toku rozwoju (ewolucji) przekształcił się właśnie w klasy i rzeczywiste obiekty w języku C++. Myślę, że warto na takich przykładach pokazywać skąd się wywodzi język C++ i jak powstawał - żeby potem nie było przesądów i bajek wśród ludzi, którzy piszą na forach że twórcy języka C to sado-masochiści że wymyślili coś tak złego ludzkości - za to stwórcy języka C++ to całkiem inna ekipa aniołów, która stworzyła niezależnie i w oderwaniu od C język C++ ;) .... no może za daleko jak zwykle posunąłem się w swoich dywagacjach dlatego teraz wracam na ziemię i prezentuję jak to może wyglądać w tzw praniu - czyli w rzeczywistym działaniu na LCD. Myślę że to dopiero przemówi do każdego lepiej niż słowa i rysunki. A dodam, że to tylko wstęp . Bo jak pomyśleć że można będzie organizować warstwy z tak zwanymi obszarami zawierającymi właściwość TRANSPARENCY ;) żywcem jak z programów graficznych oraz praktycznym zastosowaniem, które opisuję własnie w książce, a do tego wszystkiego - próbę organizacji całości w jakieś zamknięte biblioteki, z których będzie można wygodnie korzystać - to myślę że tego typu sposoby na końcu przypadną wielu osobom do gustu. Oczywiście tym, które nie ulękną się nieco większej ilości linii kodu oraz posługiwania się wskaźnikami, które w tym przypadku stają się nieodzowne.

poniżej krótki film - taka mała zajawka możliwości rodzącej się biblioteki.

Na zakończenie powiem jedno, już kiedyś próbowałem na pewnym forum przedstawić takie podejście do obsługi LCD, jednak jak to bywa - zostałem zmieciony z powierzchni ponieważ kilku cwaniaczków wlazło, tłumacząc, że to bzdury i przerost formy nad treścią, że tak się nie robi z LCD, że to głupota i tym podobne

..... tymczasem ja powiem jedno, zwykle to co niezrozumiałe to wywołuje czasem na takich forach skrajne emocje. A ci fachowcy z koziej łaski mało mieli do czynienia z takimi zagadnieniami (mam tu na myśli tych, którzy psioczą na tego typu sposoby obsługi LCD. Na ten temat też wybuchła swego czasu mini wojna na jednym z forów). Wiem za to z kursów które mam przyjemność prowadzić, że każdy kto spotkał się z takimi rozwiązaniami jest później nimi tak samo zafascynowany jak ja i zaczyna ich z chęcią używać na co dzień. A przypominam, że to nie jest żaden mój wynalazek czy odkrycie - to jest raczej próba przybliżenia tego co używają już od dawna mądrzejsi od nas w swoich fajnych i zaawansowanych programach, które podziwiamy na co dzień ale nie zawsze zdajemy sobie sprawę:

"JAK TO JEST ZROBIONE?"

;)

..... a na zakończenie dla tych, którzy myślą, że tu chodzi o jakieś tam tylko durne pseudo animacje na LCD, jeszcze jeden przykład, z którego mam nadzieję jeszcze lepiej widać że to będzie kolejny przykład tworzenia systemu wielozadaniowego (pseudo-wielowątkowości) na AVR .... tyle że tym razem każdy z niezależnych procesów dostaje do dyspozycji swój własny bufor pamięci RAM - pamięci EKRANU dzięki czemu każdy z procesów może uwaga!!! NIEZALEŻNIE wykonywać swoje operacje bądź to na całym ekranie , bądź na jego dowolnym fragmencie. Ale uwaga - każdy z procesów może także wykonywać swoje zadania w tle bez żadnego kontaktu z ekranem. Tak jak w jednym komentarzu na dole dodam - że możliwości uzyskania efektów specjalnych jak animacje są tutaj niejako efektem ubocznym - ot tak ! można je mieć przy okazji za DARMO ;) przy takim podejściu do programowania. Jeśli więc ktoś postrzega to tylko jako animację na LCD - to rzeczywiście - dalej nie ma co czytać opracowania tego tematu, które się wkrótce ukaże.

poniżej kolejny filmik - prezentujący jeszcze dodatkową warstwę z użyciem efektu przeźroczystości i nie jest to tylko gadżet - można bowiem - jeśli ma się wyobraźnię bardzo fajnie zorganizować wszystko co się przyśni na dowolnym LCD alfanumerycznym ;)..... Dodatkowo dodane zostało teraz maleńkie zdarzenie do warstwy monitora kodów z pilota, dzięki czemu kody pojawiają się tylko na chwilkę tzn na np 2 sekundy i znika warstwa. Zwróćcie uwagę proszę na to, że to co widać na LCD to efekt działania wielu procesów i każdego z osobna a nie jakaś jedna mistyfikacja - animacja ;)

w zasadzie to pętla główna tego hmmm niby skomplikowanego programu wygląda tylko tak ;)

i to wszystko - reszta obsługiwana jest pięknie w oddzielnych zdarzeniach .

Przy okazji na zakończenie podam przykład do tego do jakich granic może posunąć się ignorancja jeśli chodzi o wykorzystywanie takich prostych mechanizmów programowania. Toż niektórzy potrafią polecać/sugerować FreeRTOS nawet do tego żeby wykonywać dwie niezależne funkcje na 8-bitowcu. A skoro tak, to w zasadzie nie ma co używać 8-bitowca - bo nie da rady - lepiej od razu postawić ARM a na nim FreeRTOS'a albo linuxa i proszę mamy multitasking. Bo przecież na 8-bitowcu to herezja. A ja uważam, że właśnie takie podpowiedzi to herezja i są wręcz szkodliwe - oto przykład:

http://www.elektroda.pl/rtvforum/topic2239451.html