Wolny wyświetlacz

Witam,
korzystam z wyświetlacza: http://www.waveshare.com/wiki/2.8inch_TFT_Touch_Shield i z biblioteki udostępnionej pod tym linkiem. Problem polega na tym, że rysowanie działa bardzo wolno. Czy jest to wina samego wyświetlacza czy kodu?

A skąd możemy to wiedzieć? Ani nie napisałeś jakiego procesora używasz, ani nie widzimy Twojego kodu, ani też nie wiemy co znaczy "rysowanie".

Skoro masz tam transmisję szeregową SPI, to żeby odświeżyć cały ekran musisz przepchnąć przez jeden drut (320*240*16) bitów. Przy prędkości zegara 8MHz daje to ponad 6 ramek na sekundę - w sumie nieźle. Musisz mieć wtedy jednak cały "ekran" w procesorze (czyli pond 150 kbajtów RAMu), na nim rysować a potem głupią pętlą (a najlepiej przez DMA) wysyłać to do LCD. Takiej pamięci typowe mikrokontrolery nie mają więc zapewne wołasz jakieś funkcje rysowania wprost na ekranie. No i teraz wszystko zależy od tego co robisz, jak są te funkcje napisane i w jaki sposób używasz SPI.

Na pewno jest to wielokrotnie wolniejsza metoda, bo przed każdym pixelem driver musi wysłać jego adres. Wypełniając prostokątny obszar obrazu (np. cały ekran), możesz zdać się na autoinkrementację liczników w LCD i wtedy transfer jest najszybszy.

Na Arduino przy takiej rozdzielczości nie spodziewałbym się cudów, to bardzo "ciężki" ekran dla takiego małego procka. A na drugi raz nie lej wody ("działa bardzo wolno") tylko zrób jakieś testy czasów (millis?) np. narysowanie 100 linii ukośnych o długości 200 pixeli każda) lub wypełnienie całego ekranu kolorem i zapodawaj konkretne liczby. I jeśli zadajesz pytania to staraj się wstawiać jak najwięcej szczegółów technicznych.

Używam Intel Edison z Arduino Breakout Kit. Wypełnienie całego ekranu kolorem zajmuje 20725 ms. Kod:

void lcd_clear_screen(uint16_t hwColor)  
{
	uint32_t i, wCount = LCD_WIDTH;

	wCount *= LCD_HEIGHT;

	lcd_set_cursor(0, 0);
	lcd_write_byte(0x22, LCD_CMD);

    __LCD_DC_SET();
	__LCD_CS_CLR();
	for (i = 0; i < wCount; i ++) {
		__LCD_WRITE_BYTE(hwColor >> 8);
		__LCD_WRITE_BYTE(hwColor & 0xFF);
	}
	__LCD_CS_SET();
}

I ustawienia SPI:

   SPI.setDataMode(SPI_MODE3);
   SPI.setBitOrder(MSBFIRST);
   SPI.setClockDivider(SPI_CLOCK_DIV4);
   SPI.begin();

Twój kod robi to prymitywne wypełnianie w najszybszy możliwy (programowo) sposób więc przyczyna tego mulenia jest gdzie indziej. Od strony sprzętu, platforma taka jak Edison powinna zamalować ten ekran w ułamku sekundy. Musiałeś coś głupio podłączyć i widocznie SPI robiony jest przez software'owe machanie pinami. Na dodatek nad tym siedzi jakiś Linux (nie znam tej płytki) no i mamy 20 sekund(!) transmisji.

Tu jest oryginalny dokument:

https://www.intel.com/content/dam/support/us/en/documents/edison/sb/edison-arduino-hardware-guide.pdf

opisujący sprzęt Arduino/Edison. Przejrzyj tabelki. Jeśli nie użyłeś pinów 10-13 na których jest sprzętowy SPI, to pewnie tu jest problem - z dobrze napisanym driverem SPI ten sprzęt powinien mieć ciągły transfer na poziomie kilku Mbit/s i Twój ekranik powinien umieć w tej konfiguracji wyświetlać filmy.

Niestety może być tak, że w żaden sposób nie jesteś w stanie wykorzystać tych możliwości w systemie programowania Arduino, bo np. nie masz dostępu do programowania kanałów DMA. Gdybyś mógł podpiąć się oscyloskopem, to zobaczyłbyś czy to same bity tak wolno przepływają, czy sprzętowy SPI szybko wysyła bajt ale potem czeka jakieś setki us na wolny program.

A może masz tam jakieś inne funkcje w bibliotece? Np. narysowanie zamalowanego prostokąta? Akurat rysowanie grafiki pixel po pixelu to marny pomysł z punktu widzenia współpracy ze sprzętem, bo w żaden sposób kompilator nie może tego zoptymalizować. Korzystając z innych funkcji jest szansa, że są dobrze napisane i w pełni wykorzystują możliwości sprzętu, np. nie rysują prostokąta punkt po punkcie jak Ty, tylko programują sterownik LCD, SPI, kanał DMA i jednym strzałem wysyłają cały obszar. Choć wątpię..

Spróbuj też z innym podzielnikiem SPI, ale tu nie widać szansy na dużą poprawę..

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

Pod tym linkiem: https://learn.sparkfun.com/tutorials/using-an-lcd-on-the-edison jest informacja: "The SPI driver on the Edison is currently quite slow. A full-screen refresh takes around 20 seconds, so don't expect any video or fast cycling images. If the SPI driver is updated in a future Edison image, you can ignore this message."

Korzystałem z pinów 10-13. Z innym podzielnikiem SPI bez zmian.

Hm, no to masz odpowiedź. Swoją drogą to skandal, żeby coś takiego nazywać produktem i z rozbrajającą szczerością sprzedawać to ludziom za pieniądze. Chyba jesteś zmuszony poczekać na kolejny patch systemu Edisona i mieć nadzieję, że coś w nim poprawili w SPI. Duże firmy (Intel?) nie muszą nic, więc możesz się nie doczekać.

Nie wiem co tam chcesz zrobić, ale jeśli nie musisz mieć jakichś graficznych fajerwerków a Edison jest z jakiegoś powodu konieczny, możesz spróbować wariantu pośredniego: poprzez np. UART (może tego nie skopali?) podłączyć coś mniejszego (ATmega?) i niech ona wykonuje polecenia graficzne. Kasowanie całego ekranu powinno jej zająć ułamek sekundy a odpowiednio mniejsze operacje będą jeszcze szybsze. Gdy wstawisz do niej którąś z ogólnie dostępnych bibliotek graficznych, dodatkowy program nie będzie wielki. Po prostu niech przenosi API biblioteki na UART. Przecież gorzej niż teraz już nie będzie.

Z tego co zwraca google, driver SPI na edisonie ma pewne wady - spore opóźnienie przed rozpoczęciem i po zakończeniu transmisji. Możesz spróbować utworzyć bufor ramki w pamięci RAM i przesyłać więcej albo i wszystko na raz.

Inna sprawa, że podejście które stosujesz czyli sterownie wyświetlaczem bezpośrednio jest bardzo "mikrokontrolerowe". Edison to całkiem potężny komputer pracujący pod kontrolą linuxa i niestety to może mieć plusy, jak i minusy. Jeśli sterownik nie został odpowiednio zotymalizawany, każde wysyłanie danych może wykorzystywać wywołanie systemowe, czyli całe przejscie z trybu użytkownika do jądra i z powrotem. To oczywiście nic strasznego, ale zajmuje czas - a ponieważ wysyłasz bajt po bajcie, takie opóźnienia mogą sprawić, że transmisja zajmuje wieki.

Nieco lepsza opcja to jak napisałem wysłanie większych bloków - to oznacza mniej wywołań systemowych i daje sterownikowi szansę na optymalizację. Dla jednego bajtu DMA nic nie da, dla bloku może - chociaż nie musi.

Znacznie lepszym wyjściem byłoby napisanie sterownika, albo wykorzystanie gotowego zgodnego z architekturą systemu. Przykład takiego podejścia możesz zobaczyć pod adresem: http://hobby.farit.ru/linux-framebuffer-fbtft-with-dma-for-intel-edison/

Jak widać nie tylko działa szybko ale i filmy odtwarza 🙂

Może nie jest to aż tak zły produkt, chociaż trochę skomplikowany. A co do jego dokumentacji i jakości dostarczanego oprogramowania niestety trzeba przyznać, że intel się nie popisał.

Chyba jesteś zmuszony poczekać na kolejny patch systemu Edisona i mieć nadzieję, że coś w nim poprawili w SPI. Duże firmy (Intel?) nie muszą nic, więc możesz się nie doczekać.

Z tego co wiem, Edison jest obecnie wycofywany z rynku przez Intela, więc można się na tego patcha nie doczekać.