Układ pamięci w LCD JM12864A

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

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

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

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

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

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

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

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.

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