Jeśli znajdzie się jakaś wolna płytka, to ja bardzo chętnie się podłączę.
W międzyczasie spróbowałem wykorzystać całą powierzchnię wyświetlacza. Dla programisty może byłoby to łatwe... Początkowo udawało się nieznacznie powiększyć x i y, ale po przekroczeniu pewnych wartości wyświetlacz nie uruchamiał się. Okazało się, że firmware wykorzystuje funkcję sprite do budowania całego obrazu zamiast wyłącznie ruchomych i często modyfikowanych obszarów. Bufor obrazu wykorzystuje oczywiście pamięć RAM procesora - przy wyświetlaczu 240x135 jest to 32400 pikseli, przy 320x170 to już 54400 px, więc prawie 2 razy więcej... Rozwiązaniem było znalezienie informacji, że domyślnie biblioteka tft-espi domyślnie pracuje w 16 bitach głębi koloru, więc w pierwszym przypadku rezerwuje 64.8kB, a w drugim usiłuje zarezerwować 108.8kB - i to już jest za dużo. Kompilacja przechodzi bez błędów, ale nie działa... ech Arduino Arduino...
Po jawnym zadeklarowaniu głębi ośmiobitowej
działa cały wyświetlacz.
Sukces jest jednak tylko częściowy - przy kompilacji z zalecanym przez autora poziomem optymalizacji -O3 na ekranie pojawiają się ruchome artefakty.
Przełączenie na poziom standardowy -Os poprawia sytuację, ale nadal nie jest dobrze.
Obawiam się, że nie starczy mi samozaparcia i skończy się na wyświetlaczu 240x135, a szkoda, bo bardzo lubię ten 320x170.
Edit - jak widać przy zabawach z rozdzielczością wyszło, że autor niespecjalnie dba o spójność kodu - niektóre elementy (spektrum i wodospad) dostosowały się wraz z opisami do deklaracji
(co jest tam wyświetlane, to inna sprawa), a współrzędne innych są hardkodowane. Pocieszające jest to, że dało się zwiększyć wysokość wodospadu i to działa.
W międzyczasie spróbowałem wykorzystać całą powierzchnię wyświetlacza. Dla programisty może byłoby to łatwe... Początkowo udawało się nieznacznie powiększyć x i y, ale po przekroczeniu pewnych wartości wyświetlacz nie uruchamiał się. Okazało się, że firmware wykorzystuje funkcję sprite do budowania całego obrazu zamiast wyłącznie ruchomych i często modyfikowanych obszarów. Bufor obrazu wykorzystuje oczywiście pamięć RAM procesora - przy wyświetlaczu 240x135 jest to 32400 pikseli, przy 320x170 to już 54400 px, więc prawie 2 razy więcej... Rozwiązaniem było znalezienie informacji, że domyślnie biblioteka tft-espi domyślnie pracuje w 16 bitach głębi koloru, więc w pierwszym przypadku rezerwuje 64.8kB, a w drugim usiłuje zarezerwować 108.8kB - i to już jest za dużo. Kompilacja przechodzi bez błędów, ale nie działa... ech Arduino Arduino...
Po jawnym zadeklarowaniu głębi ośmiobitowej
Kod:
tft.displayOn();
lcd.setColorDepth(8);
lcd.createSprite(LCD_WIDTH, LCD_HEIGHT);działa cały wyświetlacz.
Sukces jest jednak tylko częściowy - przy kompilacji z zalecanym przez autora poziomem optymalizacji -O3 na ekranie pojawiają się ruchome artefakty.
Przełączenie na poziom standardowy -Os poprawia sytuację, ale nadal nie jest dobrze.
Obawiam się, że nie starczy mi samozaparcia i skończy się na wyświetlaczu 240x135, a szkoda, bo bardzo lubię ten 320x170.
Edit - jak widać przy zabawach z rozdzielczością wyszło, że autor niespecjalnie dba o spójność kodu - niektóre elementy (spektrum i wodospad) dostosowały się wraz z opisami do deklaracji
Kod:
#define LCD_WIDTH 320(co jest tam wyświetlane, to inna sprawa), a współrzędne innych są hardkodowane. Pocieszające jest to, że dało się zwiększyć wysokość wodospadu i to działa.
Kod:
#define WATERFALL_ROWS 96
// 61 for 240x135
Łukasz, Warszawa - FT991, TRX Brass (w budowie), Joker SDR (w głowie) i trochę chińszczyzny dla smaku.