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?

do góry

Sebastian Biały pisze:

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

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

do góry

Zbych wrote:
> To reguła dla tego kontrolera (KS0107).

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

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

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

do góry

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

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

do góry

Konop wrote:
> 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 ;)...

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.

do góry

Sebastian Biały pisze:
> Zbych wrote:
>> To reguła dla tego kontrolera (KS0107).
>
> Czy to popularny kontroler w 128x64? Boję się, że np. _był_ popularny i
> nowe są z nim zgodne ...

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

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

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

> algorytm rysowania linii, koła,

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

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

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

do góry

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

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

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

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

do góry

Konop wrote:
>> a) Fonty bitmapowe. 99% dostarczane jest w organizacji poziomej
>> bajtów. Trzeba przerabiać.
> 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??

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

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

> Hmmm... zależy ile tych linii rysujesz i jakiej potrzebujesz wydajności
> ;)...

Powiedzmy że najwiekszej.

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

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.

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

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.

> wielu zmian.. ale niestety, chyba tego nie unikniesz

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.

do góry

Sebastian Biały wrote:
> Zbych wrote:
>> To reguła dla tego kontrolera (KS0107).
>
> Czy to popularny kontroler w 128x64? Boję się, że np. _był_ popularny i
> nowe są z nim zgodne ...
>
>> 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).
>
> 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.

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

--
Jerry1111

do góry