Atmega644+TFT LCD - Jakich szybkości wyświetlania mogę się spodziewać?

Zamierzam pobawić się z kolorowymi TFT LCD. Problem jest w dość niskich napięciach zasilania 2.8V do 3.3V. Całość będzie działała z procesorem Atmega644 na 20MHz.

I tu pojawia się pierwszy problem. 20MHz może być tylko przy zasilaniu 5V, ekran może być na max 3.3V. Najprościej pod względem konwersji napięć jest puścić transmisję po SPI (tylko 3 tranzystory). Transmisja równoległa 8-bit będzie szybsza ale zajmie więcej pinów i wymaga bardziej złożonego konwertera napięć.

LCD ma 240x400 pikseli = 96 tysięcy punktów x bity kolorów = masakryczna ilość danych do wysłania. Chciałbym go sterować na 256 kolorów żeby zmniejszyć ilość danych.

W urządzonku które chcę zbudować, cały ekran będzie przerysowywany tylko raz na jakiś czas, natomiast często będą wyświetlane małe ikonki np 32x32 pikseli i jakieś literki (bo nie ma szans na upchnięcie większej grafiki w 64kb).

Czy ktoś z was orientuje się ile czasu zajmie przerysowanie całego ekranu w transferze po SPI i dla porównania równoległego 8-bit?
- TFT-LCD 3" 240x400px, sterownik R61509V, wymaga 2 bajtów danych na 1 piksel
- procesor Atmega644 20MHz
- dane graficzne ciągnięte z pamięci flash procesora, program w ASM (zassaj dane LPM, wypluj OUT na port lub do SPI, nic więcej)

Może już ktoś się bawił takimi ekranami i ma jakieś doświadczenie odnośnie szybkości wyświetlania?

1) Projekt będzie jako open-source więc nikt mi za to nie płaci. Nie chce poświęcać na to kilka miesięcy. Będzie to kolejny sterownik do Radmorów, ale tym razem porządnie dobajerowany funkcjami.
2) ATXmega to niby AVR ale więcej rzeczy trzeba pokonfigurować, czyli w ASM jest więcej roboty, a ja babrać się nie chcę.
3) AtMega znam bardzo dobrze więc skraca mi się czas uruchomienia wszystkiego.
4) Nie zależy mi na energooszczędności.
5) Przerysowanie ekranu będzie tylko raz na jakiś czas przy zmianie głównej funkcji. Potem będę przerysowywał tylko malutkie fragmenty (window) przy wyświetlaniu liter. Jednak chcę żeby to ładnie wyglądało. Pół-sekundowe przerysowanie to już będzie porażka (dlatego chcę też zejść do 256 kolorów)
6) Od strony połączeń bardziej mi pasuje SPI ale nie wiem jaką mi to da szybkość. Wolę zrobić projekt płytki już na gotowo bez poprawek.

robiw - całkiem sprawnie to działa, chociaż widać jak przerysowuje ekran. W każdym razie szybkość jest bardzo dobra. Widzę że dałeś interfejs 16-bit. A czy sprawdzałeś jak to działa na 8-bit lub SPI?

Mirekk - ja już ekran sobie wybrałem więc sterownik jest jaki jest. Czyli wychodzi że lepiej podłączyć to na 8-bit + konwerter. Było widać że ładowanie obrazków do najszybszych nie należy.

Do tego chcę dodać kompresję RLE plików BMP. Bo nawet prosta belka menu 20x400px to już kawał danych. Ponieważ urządzonko będzie wyświetlało menu typu buttony/belki/jakieś strzałki to RLE nadaje się doskonale. Nie będę wyświetlał obrazków typu zdjęcia.
Do tego chcę wprost includować pliki BMP do programu (czyli kompilator przepisze dokładną zawartość pliku do pamięci FLASH) i dopiero program powyciąga sobie bajty (a struktura BMP jest bardzo prosta). Wtedy będzie można sobie łatwo zmieniać wygląd przycisków, belek itp.

tmf - że będzie scalak 245 to już mirekk schemat podrzucił. Transfer danych już do pixeli idzie szybko bo tylko wcześniej ustawiam rozmiar okna, kierunek auto-zwiększania liczników położenia pixeli i pluję danymi pixeli do wyświetlacza już bez komend, wszystko właściwie robi się samo.

Użycie dataflash nic mi nie daje bo dane musiałbym sczytać po SPI i wypluć równolegle, czyli marnowanie czasu. 64kb na proste ikonki w BMP+RLE mi wystarczy.

Oczywiście że będzie to w assemblerze. Panuje jakaś dziwna moda że każdy musi pisać w C. Ja akurat piszę w ASM i mi z tym dobrze. Nie dotykam C z samego powodu dziadowskiego odwoływania się do pamięci flash i upierdliwości przy wstawkach ASM. Jakoś tak wyszło że ASM jest dla mnie prostszy niż C, no ale każdy lubi co innego

1) Projekt będzie jako open-source więc nikt mi za to nie płaci. Nie chce poświęcać na to kilka miesięcy. Będzie to kolejny sterownik do Radmorów, ale tym razem porządnie dobajerowany funkcjami.

Xmega też będzie open-source i nie trzeba kilka miesięcy.

2) ATXmega to niby AVR ale więcej rzeczy trzeba pokonfigurować, czyli w ASM jest więcej roboty, a ja babrać się nie chcę.

Jeżeli uporządkujesz na początku kwestię zegara, PLL i PR, to nie ma nic więcej do konfigurowania na początek. Chyba, że mówisz o EBI(3port) + DMA (Xmega128A1U), dzięki którym dzisiaj bez większego problemu przerysowuję ekran 800x480 w 24 bitach w 0,8s (przy Wait State=6). Dane są przesyłane sekwencyjnie na 8 bitach w 3 zapisach (RGB) do SSD 1963.
Albo chcesz mieć funkcjonalność, albo "nie chcesz się babrać" i nic nie robisz.

3) AtMega znam bardzo dobrze więc skraca mi się czas uruchomienia wszystkiego.

Jeżeli poświęcisz 2 wieczory na programowanie Xmegi po wcześniejszej lekturze DSa i Manuala, to do zwykłej megi nie będziesz chciał wracać. Xmega jest bardzo dobrze poukładana i pozwala zaoszczędzić mnóstwo czasu przy zmianach.

4) Nie zależy mi na energooszczędności.

Xmega to nie tylko mniejszy pobór prądu. To również praca z zegarem 32MHz (lub nawet 48MHz) przy 3,3V.

5) Przerysowanie ekranu będzie tylko raz na jakiś czas przy zmianie głównej funkcji. Potem będę przerysowywał tylko malutkie fragmenty (window) przy wyświetlaniu liter. Jednak chcę żeby to ładnie wyglądało. Pół-sekundowe przerysowanie to już będzie porażka (dlatego chcę też zejść do 256 kolorów)

Dlaczego rezygnować z jakości, jeżeli można mieć wyższą?

6) Od strony połączeń bardziej mi pasuje SPI ale nie wiem jaką mi to da szybkość. Wolę zrobić projekt płytki już na gotowo bez poprawek.

Prędkość SPI nawet dla Xmegi nie przekracza 16MHz (24MHz). Efektywnie jest to min. 32x wolniej (256 kolorów jest tragiczne) lub ok. 100x wolniej dla 24 bitowego koloru względem EBI + DMA. A projekt płytki i tak zrobisz przynajmniej 2 razy.

Aha, dzięki EBI możesz doczepić np. 4MB ramu, do których załadujesz dane z karty pamięci czy Data Flash i będziesz mógł swobodnie pracować z dowolnymi ikonkami, przewalając dane z ramu do tft niemal bez udziału rdzenia, który w tym czasie może wykonać coś pożytecznego.

Pozdrawiam!

Czasem czytając niektóre wypowiedzi widzę że budując nawet migacz LED należałoby już wziąć ARMa podkręconego na 100MHz.
Urządzenie ma być jak najprostsze, stąd zwykła Atmega+pamięć na SPI to już największa prostota, do tego ograniczenie do 256 kolorów dla zmniejszenia ilości danych.
Chodziło mi jedynie o to aby się dowiedzieć co z takiej konfiguracji można wyciągnąć, a nie że buduję odtwarzacz video dający 600 kl/s. To ma być zwykły sterownik z dobajerowaniem w postaci kolorowego LCD graficznego na którym raz na jakiś czas coś się zmieni.
Czyli na obecną chwilę widzę że warto przejść na połączenie równoległe do LCD i pozostać przy szeregowym SPI ciągnącym dane z pamięci data flash. Tam będzie tylko kilka ikonek i czcionki.

To będzie zwykły panel pokazujący częstotliwość, ikonki i stan radia. Podczas wyświetlania procesor nie musi robić nic innego, ekran odświeża się tylko gdy zmienisz częstotliwość, wciśniesz nadawanie itp.

Ponieważ grafika zajmuje dużo to wymyśliłem że będzie w zewnętrznej pamięci data-flash. Dla ułatwienia czcionki mógłbym trzymać już w pamięci procesora (1 kolorowe i małe, ale wiadomo że kilkadziesiąt znaków to już kilkanaście kb może się zrobić).
Inna opcja to będzie taka że LCd i pamięć będa podpięte pod 1 SPI i będę sterował tylko ich sygnałem CS, czyli zasysam bajt z pamięci, zmieniam CS i wypluwam do LCD, i tak powtarzam aż narysuje się grafika.