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

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

A myślałem że to tylko różnica w filtrach polaryzacyjnych

_________________
http://www.jaglarz.info

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ą

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Ciekawa dyskusja się rozwija



...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.

_________________
http://www.sylwekkuna.com

Coś jednak musiałeś zawalić. Aż specjalnie wstawiłem pułapkę przy odświeżaniu LCD w projekcie, nad którym aktualnie ślęczę żeby zmierzyć czas poświęcony na drukowanie i oto efekty wizualizacji:





Na pierwszym wykresie to właśnie moje standardowe cykliczne odświeżanie w projektach czyli jeden obieg pętli = jeden znak na LCD. Jak widać jest to 70us(!) +- 2us
Na drugim wykresie przełączyłem "odświeżacz" aby cały bufor (czyli 32 znaki) od razu wywalił na LCD co odpowiada całemu zapełnieniu ekranu. Czas podskoczył do 2,2ms. Co prawda aby było bardziej miarodajnie dla typowej biblioteki to standardowo trzeba by użyć dwóch komend LCD i jeszcze lokowania kursora więc nawet niech by te 3-4ms były dla zwykłej biblioteki to jak widzisz gdzieś musiałeś zbłądzić w obliczeniach i ten przecinek o jeden w lewo umieścić powinieneś
Jak by jednak nie patrzył 70us na korzystanie z LCD to już jest czas, który można spokojnie przyjąć bez męki, że coś będzie przyblokowane i właściwie można go nie brać pod większą uwagę* przy pisaniu programu choćby do badania enkodera bez gubienia impulsów w poolingu w pętli głównej

*w granicach rozsądku oczywiście

_________________
http://www.sylwekkuna.com