ATNEL tech-forum https://forum.atnel.pl/ |
|
Test LCD Negatyw vs standard https://forum.atnel.pl/topic22176.html |
Strona 1 z 1 |
Autor: | mirekk36 [ 16 kwi 2019, o 11:15 ] |
Tytuł: | Re: Test LCD Negatyw vs standart |
I BARDZO dobry test - widać, że jest tak jak mówiłem odnośnie zwyklaków żółto-zielonych Niebieskie się wprawdzie wszystkim podobają bo kolorek - ale przewijanie czegokolwiek to masakra ... i pięknie widać to na tym teście |
Autor: | Jaglarz [ 16 kwi 2019, o 11:17 ] |
Tytuł: | Re: Test LCD Negatyw vs standart |
A myślałem że to tylko różnica w filtrach polaryzacyjnych |
Autor: | mirekk36 [ 16 kwi 2019, o 11:38 ] |
Tytuł: | Re: Test LCD Negatyw vs standart |
Technologia wytwarzania tych wyświetlaczy żółtozielonych zapewnia lepsze odświeżanie po prostu. Poza tym na zwyklaku widać dane bez podświetlenia a na tych negatywowych ? porażka bo nie widać Ale za to jakie ładne bo na niebiesko świecą |
Autor: | SylwekK [ 16 kwi 2019, o 16:06 ] |
Tytuł: | Re: Test LCD Negatyw vs standart |
Ciekawa dyskusja się rozwija zubik napisał(a): negatyw ~39.367ms standart ~45.879ms ...to jest właściwie gwoździem do trumny przy bardziej zaawansowanych programach. Taki czas opóźnienia pętli głównej czasem kompletnie rozwala algorytm, który potrzebuje np. co 5ms coś czytać. Niech tylko kilka razy będzie odwołanie do LCD z większą ilością znaków i uzyskanie czasu 45ms to będzie marzeniem w porównaniu np. z 200ms, które to się może uzbierać po drodze. Oczywiście można wspomóc się przerwaniami, ale gdy te już są wyśrubowane to zaczynają się schody. Programy powinny być pisane nieblokująco czyli z ciągłym przelotem przez pętlę główną. Przy takim programie właściwie trzeba zapomnieć o jakimkolwiek delay, a zamiast tego stosować timery programowe. Jak więc przyspieszyć pętlę aby mieć również bezproblemowy podgląd na LCD przy minimalnym opóźnieniu pętli...? Odpowiedź jest prosta - ekran buforowany z odświeżaniem cyklicznym. Może brzmi to złowrogo i zawile, ale jest bardzo proste, a dłuższego już czasu każdy mój program ma tylko właśnie taką obsługę LCD. O co więc chodzi...? Ekran buforowany czyli nie operujemy bezpośrednio na LCD tylko na buforze stworzonym w pamięci RAM (Mirkowym GB jest o czymś bardzo podobnym) i to na tej pamięci dokonuje się wszelkich zmian, a przy końcu pętli głównej wszystkie te zmiany wysyłamy na LCD. No dobra, ale to nadal kupa czasu 16 linii x 2 to dalej wychodzi około 40ms (operacji na RAM nawet nie ma co tu brać pod uwagę, bo wykonują się błyskawicznie). Co więc zrobić...? Posiekać, podrobić i wysyłać po kawałku Wystarczy wysyłać nie wszystko na raz, a po jednym znaku do LCD i czas opóźnienia drastycznie spadnie. Przykładowo u mnie pętla pędzi sobie z ciągłym wyświetlaniem na LCD zatrzymując się tylko przy odświeżaniu na jakieś 100us... Jak widać to trochę mniej niż 40ms Najciekawsze jest to, że nie muszę NIGDY używać do kasowania ekranu pojedynczych znaków ani systemowych komend CLS, HOME, itd, które są strasznie czasochłonne. Jeśli chcę coś skasować to po prostu tego nie drukuję i w kolejnym obiegu zniknie z ekranu (zrobiłem opcję autoczyszczenia bufora). Jeśli więc zależy wam na szybkości pętli z wyświetlaniem na LCD to polecam zainteresować się tą metodą i nie psioczyć, że LCD muli ------------------------ [ Dodano po: 25 minutach ] Tak mnie jeszcze naszło... czy na pewno @zubik podałeś dobry rząd wielkości, czy przecinek nie powinien być o 1 w lewo??? Jakoś tak dużo za duży mi się wydaje ten Twój wynik. |
Strona 1 z 1 | Strefa czasowa: UTC + 1 |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |