Układ pamięci RAM w wyświetlaczach 128x64: wyjątek JM12864A czy standard?

Sat Oct 24, 2009 10:52 pm   

Mam tu takiego LCDka:

http://www.dartelektronik.com.pl/pdf/lcd12864a.pdf

Jego układ pamięci RAM jest chyba najbardziej popieprzony ze wszystkich
jakie widziałem - nie dośc, że bajty leżą w pionie, to jeszcze są
ułożone obok siebie a czare goryczy przepełnia podział na dwie fizyczne
jednostki sterujące. Kompletna porażka jeśli chodzi o typowe
odwzorowanie w pamieci CPU. Na razie zrobiłem pośredniczący kontroler
ktory to doprowadza do postaci liniowej i jest ok, ale ...

chodzi mi o coś innego:

Czy JM12864A to jest wyjątek czy też wiekszośc wyświetlaczy 128x64 ma
rownie popieprzony układ RAMu wewnątrz? W innych wyświetlaczach "typu"
12864 nie zawsze widzę dwa sygnaly CS na osobne jednostki, więc
zakładam, że pewnie niekoniecznie jest to reguła.

Rozglądam się za jakimś wynalazkiem 128x64 z mozliwie małą ilością
peryferiów i najlepiej z magistralą szeregową, ale wolałbym nie wdepnąć
w organizację pamięci jak w tym moim, bo kompletnie to rozwala koncepcje
transmisji do niego z użyciem DMA, a z różnych wzgledow powinienem miec
liniowy framebuffer.

Więc: czy nielinowośc RAMu LCD 128x64 to wyjatek czy reguła w tej klasie
wyswietlaczy?

Sat Oct 24, 2009 11:06 pm   

Sebastian Biały pisze:


To reguła dla tego kontrolera (KS0107). Wyświetlacze 192x64 mają trzy
CS. A co do ułożenia bajtów w pionie, to jest to fajny patent; bardzo
prosto kopiuje się dzięki temu czcionki (zwłaszcza te o zmiennej
szerokości).

Sat Oct 24, 2009 11:22 pm   

Zbych wrote:

Czy to popularny kontroler w 128x64? Boję się, że np. _był_ popularny i
nowe są z nim zgodne ...


Zawsze można znaleźć za i przeciw. Ale tak się akurat składa felernie,
że w "normalnym" świecie prawie każda bitmapa i font wymaga
przekonwertowania do postaci pionowych bitów. W dodatku prawie każdy
algorytm rysowania linii, koła, itd wymaga przepisania. I niestety nie
można zamieniać tylko "x" z "y" bo wyświetlacz nie dość że ma pionowe
bajty, to posklejane dłuższymi krawędziami. Dlatego zysk z rysowania
czcionek jest dla mnie pomijalnie mały, bo trace masę czasu na
dostosowanie innych elementów. I w dodatku nie mogę użyć prostego
algorytmu przepisyania RAM do LCD bo mam dwa CS i jeszcze na domiar
złego wyświetlacz nie zmienia automatycznie "Pages".

Sun Oct 25, 2009 1:37 am   

No to z tymi CS'ami i Pages'ami to rozumiem, a pozostałe rzeczy mógłbyś
wyjaśnić dokładniej o co Ci chodzi?? Ja jakoś nie widzę problemu w
rysowaniu linii przy bajtach pionowych i poziomych ...

Pozdrawiam
Konop

Sun Oct 25, 2009 10:09 am   

Konop wrote:

a) Fonty bitmapowe. 99% dostarczane jest w organizacji poziomej bajtów.
Trzeba przerabiać.

b) Niskopoziomowe algorytmy rysowania lini czasem wykorzystują fakt, że
bajty leżą obok siebie bo moge wykonać (++ptr) i załatwic na raz 8
bitów. W przypadku tego wyswietlacza: w poziomie można narysować na raz
1 pixel, a w pionie nie można zrobić ++ptr. Oganizacja sklejania bajtów
dłuższymi krawędziami jest nietypowa.

Sun Oct 25, 2009 10:19 am   

Sebastian Biały pisze:

Powiedzmy, że popularny w segmencie tanich wyświetlaczy
monochromatycznych z interfejsem równoległym.


Ale to robisz na PC. Są do tego gotowe programy.


Koła przy tej rozdzielczości i prostokątnych pikselach? :-)


Da się jak masz uC z DMA z możliwością tworzenia "łańcuchów transmisji".

Sun Oct 25, 2009 3:28 pm   

No fakt, tu jest problem, jeśli ma się gotowe ... ale czy stworzenie
algorytmu, który by to przerabiał dużo zajmie?? Może prosty programik,
napisany w pół godziny wszystko przerobi w myk i otrzymasz gotowe fonty??


Hmmm... zależy ile tych linii rysujesz i jakiej potrzebujesz wydajności
... ja ostatnio się takim LCD bawiłem i nie chciało mi się bawić w
rozróżnianie poziomych i pionowych linii, po prostu rysowałem od (x1,
y1) do (x2, y2), i wtedy ta organizacja bajtów niewiele mi zmieniała
... A poza tym, czy aż taka duża jest różnica pomiędzy napisaniem
++ptr a ptr+= 8 ?? ... wiem, osobna linia kodu, no ale mimo wszystko ...

Rozumiem, o co Ci chodzi - jest to niewygodne i w Twoim przypadku wymaga
wielu zmian.. ale niestety, chyba tego nie unikniesz, więc staram się
Ciebie jakoś pocieszyć ...

Pozdrawiam
Konop

Sun Oct 25, 2009 3:52 pm   

Konop wrote:

Przeciez nie mowie, że się nie da. Tylko to dodatkowa praca. Zysku brak
poza wspomnianymi czcionaki proporcjonalnymi.


Powiedzmy że najwiekszej.


Większość sensownych algorytmow rysowania linii nie polega na
istniejacej funkcji "plot(x,y)" tylko zakłada pewna organizację pamięci
i manipuluje bajtami/bitami. Tak jest szybciej niż za każdym razem wołać
algorytm liczący offsety w plocie. Dla takiego wyswietlacza jak JM12864A
wymaga to gruntownego przepisania i raczej nie jest to kosmetyka. Po
prostu "reszta swiata" ma organizację szeregową pixeli.


Niektore procesory mają support dla post inkrementacji/dekrementacji.
Jedna instrukcja maszynowa wklada coś do RAM i przemiesza ptr o jedna
szerokość danych. Na przykład MC680x0.


Już uniknąłem, wsadzilem po drodze ATMega8 ktory robi konwersje
real-time 50ramek/s (grubo powyżej czasu reakcji LCD). Wyszło taniej niz
przerabiać pół bibliteki graficznej. Dodatkowo robi konwersje z UARTa,
więc mogę w procku zastosować wprost DMA do wysyłania liniowego
framebuffera. Ideałem dla mnie było by coś takiego zaszyte w LCD i wiem
ze niektore z SPI tak mają, ale boje się ze w grupie 128x64 czekają mnie
jakieś niespodzianki. Wole zapytać zawczasu czy to norma.

Mon Oct 26, 2009 9:27 pm   

Sebastian Biały wrote:

Ale za to tekst bardzo latwo wyslac (jak font 8x8).

--
Jerry1111