Z cykly dziś w biurze:
Szykuję sie właśnie do napisania framweworku w Processingu, służącego do wyświetlania tekstu na wyświetlaczu ciekłokrystalicznym. Nie
zacznę od początku tej, bo byłaby ona wtedy zbyt nudna, opowiem tylko nad czym pracowałem dzisiaj.
Wyświetlacze LCD w postaci 'klasycznego' alfanumerycznego 16x2 (max 20x4), cieszą się popularnością, z racji kilku cech, takich jak
dostępność dokumentacji, powwszechność używanego 'API' (do tego jeszcez wrócimy - wszyscy skopiowali rozwiązanie Hitachi (?) I stało
się ono de-facto standardem.
Do Thinklitez, chcieliśmy więcej, Piskun zamówił więc jakiś wyświetlacz graficzny, Trochę strzał w ciemno podytkowany nieco dostępnością podzespoułu na Polskim rynku, ale prawdopodobnie jednak nada się nieźle do naszych potrzeb. Jest to wyświetlacz oparty na
HDcostamcostam który podobno w ogólnej zasadzie działania i pinoutem jest kompatybilny z ilomaśtam innymi wyświetlaczami, typowo dość małymi, nasz ma 128x160 pikseli i od przyszłego tygodnia będę pewnie prototypował jakąś sensowną metodę 'obrotu' wyświetlacza tak,
aby móc traktować go jako 160x128 pikseli bez zbędnej utraty wydajności na jakieś przekształcenia, które na pewno można wyeliminować
jakimś sprytnym pomysłem. Jednocześnie musi to być zrobione tak, aby ów sprytny pomysł dało się wymienić na inny, sprytniejszy pomysł,
kiedy takowy zasygalizuje swoją konieczność.
Przedstawię może jednak jakieś tło do tej historii, spróbuję bardzo pobieżnie. W przeciwieństwie bowiem do 'starych dobrych' 16x2,
wyświetlacze graficzne często różnią się znacznie pod względem dos†epnych funkci. Można więc kupić wyświetlacze które oprócz komend, pozwalających na ustawienie piksela, dają ci także możliwość narysowania linii, prostokąta, a czasami nawet koła, o zadanym kolorze.
. Dzięki takim funkcjom, wyświetlacz można obsłużyć względnie prosto z poziomu mikroprocesora, o których cały czas mowa.
Mikroprocesor robi czasami dość dużo różnych rzeczy naraz, w wielu z nich pomagają mu wbudowane peryferia, kanały DMA, skomplikowane
hierarchie przerwań, ale wciąż dość dużo operacji trzeba wykonać 'ręcznie' za pomocą stosu i zestawu szybkich, jednocyklowych rejestrów. Takie ręczne liczenie np. gdzie zaczyna a gdzie kończy się krawędź koła, dla każdego z np 128x160 pikseli (szbki cmdtab do
kalkulatora) = 20480 pikseli. Do tego pamiętajmy że fajnie mieć po bajcie na R G i B, daje nam >60kb buffor.
60k to nie jest jakoś dużo w porównaniu do ponad 6M gdy mowa o HD, ale w świecie embedded zasoby są ograniczone.
Tyle wstępu, i teraz moje zadanie na dziś: zanim nie ząłem pisać emulator, chciałem upewnić się że rozumiem model koloru jakiego użyć chciał sterownik wyświetlacza.
Nasz wyświetlacz, jak się szybko nie posiada najprostszych nawet funkcji graficzych, nie uświadczysz ani koła, ani linii, ani nawet funkcji ustawienia pojedynczego piksela niestety nie ma, i stało się oczywiste że będziemy potrzebować pisać do bufora, bez tego ani rusz, bo sklecona naprędce funkcja putPixel(x,y,r,g,b) składającą się modła sę z szeregu roskazów najpierw ustawiających w okno pracy
układu piszącego do pamięci GRAM w kontorlerze wyświetlacza, co realizuje się ani tości w rejestry CASET i PASET, a następnie inicjując transfer danych komendą 0x2A ? po której należy wypluć ów felerny piksel.
Dało się odczuć, że projektujący ten system mieli określone założenia dotyczące tego jak zamierzasz pracować z ekranem, i jedyne w czym
zamierzają ci pomóc to scroll, z czego jeszcez nei wiem czy zamierzam skorzystać,
Ponieważ w aktualnym projekcie nie będzie nam potrzebne precyzyjne odwzorowanie koloru, stało się jasne że warto skorzystać z
zostawionej przez projektantów scalaka furtki do zmniejszenia bufora. Zamiast słać po 3 bajty odpowiadające za R G i B, możnta
skompresować nieco informacje i użyć koloru 16bitwego (paleta 65k kolorów), tak w latach 90 pracowały graficzne komputery osobiste, ponieważ ram był drogi, się poświęcić mniejszą ilość bitów na rozdzielczość kolorów. Podczas obecnie gdy w high-endowych produkcjach wideo spotkać można przesadnie wielkie głębie koloru w rodzaju 32bitowy float na każdą ze składowych koloru plus Aplha, dający niebagatelne 32bit*1920x1080*4(rgba)=33177600bajtów, czyli około 32MiB na klatkę, do wielu zastosowań (np dtp) wysarczał kolor i16bitowy w którym pierwszych pięć bitów przeznaczonych jest na kolor Czerwony, następne sześć na Zielony, ichcreszcie ostatnie cztery
na niebieski. 5 bitów czyli raptem 32 możliwości. Nie za dużo. Jeżeli np zamierzasz wyświetlić precyzyjnie jakiś motyw z nieznacznym gradientem typu niebo, to istnieje ryzyko że całe niebo może zawrzeć się np pomiędzy 23 a 25 rysując a kontury po widonokręgu. Na un uniknięciu takiej właśnie sytuacji wyraźnie zależało projektantom tego sterownika wyświetlacza, albowiem oferuje on serię funkcji skupiających się no detalach implementacji takich jak prąd driveró∑ na różnych etapach analogowego wysterowania alementów optycznych, możliwość tuningu kwarcu pod odbieranie sygnału wideo itp. Ogólnie nuda i z większości funkcji nigdy nie skorzystamy, ale możliwość zredukowania bufora jaki trzeba policzyć do 40kb to juź coś czym możnaby się zainteresować, może się przydać. Ponieważ liczyłem się
z tą możliwością w momencie gdy zacyznałem pisać kod, przejście z 24Bit na 16bit wymagało zmiany *3 na *2 w trzech miejscach oraz dopisania funkcji pakującej bity dla ciekawskich podaję wzór L (r&0x wejwiejre). W zasadzie od razu (po pierwszej kompilacji bez błędów) na ekranie pojawił się migoczący wesoło blonk migoczących (matrix style) znaków demonstrujący zasłysazny w sieci szybki generator liczb pseudolosowych, Wydawałob się to szybkim zwycięstwem ale niestety był pewien problem.
Litery owszem, dało się odczytać ale tekst był jasnofioletowy na ciemniofioletowym zamiast biało na czarnym, a zamiast mojego delikatnego gradientu
blue-green widać było w tle brutalne kloce pozornie przypadkowych kolorów. Coś było nie tak.
Datasheet wskazywał niewiele tropów ale gdzieś mignęła mi wzmianka o LUT do translacji kolorów pomiędzy formatami bitów. Trudnością było zgadnięcie że wypełnienie tabeli LUT wybraną paletą barw jest dla trybu 16bit obowiązkowe, i że bez niego obraz wygląda jak kupa. datasheet mówi o
maksymalnie 18-bitowym kolorze, czyli po sześć bitów na kanał (nie pełne 24bity jak trzeba mu wtedy słać dane), w trybie 16bit dla czerwonego i niebieskiego pośwwięcamy po jednym bicie aby nie marnować pasma magistr(i. Po wygenerowaniu liniowych przebiegów od zera do 31 (dla R) i od 0 do 63 dla Zielonego koloru (dobrze robią, w zieleni wzrok człowieka jest najczulszy), i wyeliminowaniu błędu w arytmetyce wyświetlania 0xFF zamiast 0xFF00, moim oczom ukazał się w pełni kolorowy obrazek testowy. LUT to bardzo potężne, choć trudne do maksymalnego wykorzystania narzędzia e. W trosce o jakość odwzorowania koloru pozwala dowolnie (w tym winwersji i innych dziwnych krzywych) zmapowanie podawanych mu 5-6-5 bitów. na dostępne 6-6-6.
Skoro temat już był rozgrzebany to wydałem jeszcez komendę ustawiania parametru Gamma, przy aktualnym prądzie świecenia wioczne różnice jasności barw były pomiędzy 0 a mniej więcej połową skali, podczas gdy droga od 50% do 100% zdawała się nie piąć już tak stromo. Po sprawdzeniu opcji pierwszej i ostatniej zostałem na ostatniej. Różnica w jasności środka była nieznaczna ale przynajmniej realizuje to analogowo driver i nie musiałem dobierać żadnegj drogiej obliczeniowo funkcji nieliniowej żeby to skompensować.
No to tyle, czwartek w biurze. zbr odmeldowuje się, przepraszam za niejasności, w razie potrzeby pytać.
Za każdym razem gdy google oferowało mi wybór zmiany domyślnego języka z Angielskiego na Polski, klikałem że nie. Nie interesuje mnie ściągaj.pl pobierz.pl ani inne serwisy kradnące ruch, nie interesuje mnie piąta największa wikipedia tylko po prostu wikipedia itp itp. Google sugerowało mi zmianę mniej więcej raz na dwa dni, ale pomimo mojej wytrwałości zmiana i tak nastąpiła. Pewnie niedługo nawet nie będą się pytać. Po prostu program stwierdził że skoro tak długo siedzę w polsce to po prostu MUSZĄ mnie bardziej interesować wyniki wyszukiwań w grafice spersonalizowane do lokalizacji.
Co przypomina mi sytuację sprzed jakichś sześciu, siedmiu lat, kiedy google dopiero testowało personalizację wyników i pierwszy raz można było łatwo zaobserwować 'glitche w matrixie' typu zupełnie inne wyniki wyszukiwania w zależności od komputera z którego wpisujesz zapytanie. Co ciekawe inna przeglądarka z tego samego komputera dawała podobne. Wtedy też wpisałem może trzeci raz 'Edirol V4' a wyszedł w image search krzyż, lokalizacja w polsce dała wyższy priorytet stronie 'Church Videos' zamiast oczekiwanego VJForums. Na szczęście po zalogowaniu anomalia ustąpiła.