Obsługa wyświetlacza SPI TFT (ILI9341) w no

Albo go nie zainstalowałes, to nie jest raczej część kernela, tylko osobny dodatek.

Instalacja od zera nie działa?

Internety twierdzą, że można aktualizować system, ale trzeba zatrzymać aktualizacje kernela.

PS. Nie mam go, wiec mogę pomóc tylko w ciemno.

Po wykonaniu tego skryptu instalacyjnego w /dev pojawia się plik fb1. W /boot/config.txt pojawia się linia zaczynająca się od dtoverlay=rpi-display.

Nie mam jednak obrazu na ekranie. Dodatkowo przestaje działać DAC, który pracuje na tym samym interfejsie SPI, ale korzysta z pinu CE0. Być może więc chodzi tylko o konflikty ze sterownikiem ekranu, który domyślnie chce operować tym samym pinem, podczas gdy u mnie jest to CE1. Nigdzie nie mogę doszukać się informacji o tym, jak ten pin zamienić w konfiguracji.

Gdy zakomentuję dtoverlay=rpi-display, DAC zaczyna działać po resecie.

Temat z 2013 roku, czy na długo zanim w ogóle powstało to urządzenie (okolica roku 2016). Więc raczej tutaj mowa o znacznie starszym kernelu i znacznie wcześniejszej aktualizacji, która zepsuła działanie wyświetlacz u mnie.

Chodzi o to, że masz możliwość zatrzymania aktualizacji kernela. Skoro chodziło Ci na starym, to zainstaluj stary OS, zatrzymają aktualizaję kernela i zrób update.

Myślałem o tym, ale w miarę możliwości chciałbym zachować w pełni współczesny system.

Generalnie i tak prawdopodobnie będę chciał w tym projekcie zastosować inny wyświetlacz. Pierwotny zamysł zakładał, że wszystko będzie się mieściło na jednej "płycie głównej", w którą będzie wetknięty zarówno wyświetlacz, jak i RasPi0. Obudowa miała być drukowana w 3D albo wycinana laserem ze sklejki.

Teraz zmieniłem koncepcję i całość trafi do metalowej obudowy, więc wyświetlacz umieszczę na przednim panelu i połączę go z płytą przewodami. Mogę więc sobie pozwolić na nieco większy wyświetlacz.

Stąd moje kolejne pytanie: Ktoś może wie coś na temat SPRAWDZONEGO wyświetlacza SPI TFT o przekątnej 2,8"-3,5", który działałby ze współczesnym Raspbianem i był wykrywany przez system jako /dev/fbx? Warunek konieczny to możliwość skonfigurowania w sterowniku wszystkich pinów (łącznie z CS), bo płytka jest już gotowa.

HDMI:

MPI3508.

Nic nie trzeba konfigurowac, działa z HDMI.

Trochę strzelanie z armaty do komara. W projekcie wyświetlacz będzie musiał pokazywać interfejs złożony ze statycznych grafik i tekstu. W dodatku widzę jeszcze jeden problem - zaproponowany MPI3508 nie ma otworów montażowych pozwalających na łatwe przykręcenie do przedniego panelu. Został zaprojektowany jako nakładka nm "duże" RasPi.

Tylko, że rozwiązuje bardzo dużo problemów za bardzo małą cenę.

Świetnie się sprawdzi. X-y na tym znakomicie działają.

Od czego drukarki 3D. Wyświetlacz ma cztery "skrzydełka" w postaci wyrostkó z PCB, które mają słuzyć do mocowania.

To że zaprojektowano do dużego Pi, nic nie zmienia. Sam go używałem, przez jakis czas, jako dodatkowy wyświetlacz w laptopie. Ma nawet dodatkowe zasilanie na microUSB, specjalnie do tego.

Zaryzykuje, że jest idealnym zastepnikiem kłopotliwych ekranów na SPI, a mocowanie to jedyny problem.

Wydaje mi się, że analiza zawartości dmesg przybliżyła mnie nieco do ujawnienia przyczyny takiego zachowania. Kluczowe fragmenty poniżej:

[ 8.969897] spi-bcm2835 20204000.spi: chipselect 0 already in use [ 8.973392] spi_master spi0: spi_device register error /soc/spi@7e204000/enc28j60@0 [ 8.979635] spi_master spi0: Failed to create SPI device for /soc/spi@7e204000/enc28j60@0 (...) [ 15.150009] ads7846 spi0.1: supply vcc not found, using dummy regulator [ 15.173601] ads7846 spi0.1: touchscreen, irq 160 [ 15.175904] input: ADS7846 Touchscreen as /devices/platform/soc/20204000.spi/spi_master/spi0/spi0.1/input/input0 [ 15.258677] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 15.298044] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned. [ 15.299292] fb_ili9341 spi0.0: fbtft_property_value: buswidth = 8 [ 15.299340] fb_ili9341 spi0.0: fbtft_property_value: debug = 0 [ 15.299367] fb_ili9341 spi0.0: fbtft_property_value: rotate = 270 [ 15.299396] fb_ili9341 spi0.0: fbtft_property_value: fps = 50 (...) [ 16.381278] graphics fb1: fb_ili9341 frame buffer, 320x240, 150 KiB video memory, 16 KiB buffer memory, fps=50, spi0.0 at 16 MHz (...) [ 18.704521] pinctrl-bcm2835 20200000.gpio: pin gpio18 already requested by spi0.0; cannot claim for 20203000.i2s [ 18.704566] pinctrl-bcm2835 20200000.gpio: pin-18 (20203000.i2s) status -22 [ 18.704594] pinctrl-bcm2835 20200000.gpio: could not request pin 18 (gpio18) from group gpio18 on device pinctrl-bcm2835 [ 18.704613] bcm2835-i2s 20203000.i2s: Error applying setting, reverse things back [ 18.704673] bcm2835-i2s: probe of 20203000.i2s failed with error -22

Wygląda więc na to, że:

- dtoverlay=rpi-display (pomimo próby użycia odpowiednich parametrów) upiera się przy użyciu pewnych zafiksowanych parametrów.

- Sterownik upiera się, żeby w roli pinu CE wyświetlacza używać CE0, chociaż u mnie ten pin jest wykorzystywany do sterowania kontrolerem LAN. Dochodzi do konfliktu i Ethernet się wykrzacza. Wyświetlacz oczywiście też nie działa, bo system nie może się z nim skomunikować, skoro ten w rzeczywistości jest na pinie CE1.

- Żeby tego było mało, sterownik próbuje jeszcze aktywować warstwę dotykową przyjmując, że jest podłączona do pinu CE1. Dodatkowo do obsługi tej funkcji rezerwowane są inne piny, co prowadzi do konfliktu z I2S i wywala się DAC.

Ktoś ma pomysł jak mu powiedzieć, że z ekranem ma się komunikować przez CE1, a funkcji ekranu dotykowego ma nie używać wcale?

Masz te parametry podane w lini opcji jądra i/lub /etc/modules?

https://tlfong01.blog/2020/05/23/mgd-blog-ili9341-screen-setup-notes/

To jest właśnie ten stary sposób, o którym pisałem w pierwszej wiadomości. On przestał działać wraz z aktualizację systemu do najnowszej wersji.

Z tego co zdążyłem do tej pory ustalić to:

1. Teraz robi się ro za pomocą wpisów "dtoverlay=" w pliku /boot/config.txt.
2. Żeby wpis zadziałał, w katalogu /boot/overlays musi się znaleźć korespondujący z nim plik *.dtbo
3. W mojej obecnej wersji systemu znajduje się plik rpi-display. Czy był tam od początku, czy zainstalowałem go podczas eksperymentów - już nie jestem pewien. Dlatego jakikolwiek efekt jestem w stanie uzyskać dodając wpis "dtoverlay=rpi-display".
4. Niestety, ten sterownik nic sonie nie robi z parametrów konfiguracyjnych i próbuje korzystać z pinów, które są już przypisane do innych peryferiów. Do tego upiera się, żeby część z tych pinów przeznaczyć na obsługe panelu dotykowego. Tak więc wyświetlacz nie działa prawidłowo, a LAN i DAC się wywalają.
5. Być może lepsze efekty przyniósłby "dtoverlay=fbtft", który widziałem w paru przykładach. Niestety, pliku fbtft.dtbo nie ma w moim systemie, ani nie mogę go nigdzie znaleźć.
6. Pliki *.dtbo z tego co widzę kompiluje się z plików źródłowych *.dtb za pomocą kompilatora dtc. Prawdopodobnie w ten sposób dałoby się przygotować customowy plik dtbo do mojego ekranu, w którym mógłbym ustawić określone pliki i inne parametry domyślne. Niestety, nie rozgryzłem jeszcze struktury i znaczenia poszczególnych elementów tych plików.

Atlantis snipped-for-privacy@wp.pl napisał(a):

To jest po prostu device tree. Na x86 jest ACPI, które pozwala wykrywać sprzęt podczas uruchamiania komputera. ARM tego nie ma i trzeba kernelowi powiedzieć gdzie co jest w komputerze. Sprzęt jest opisywany za pomocą plików Device tree, zawierających drzewo urządzeń. Pliki źródłowe DT mają rozszerzenie .dts i znajdziesz do nich mnóstwo dokumentacji. Plik .dts można skompilować do formy binarnej kompilatorem dtc. I teraz dochodzimy overlay'ów, które są takimi patchami na DT. Zamiast modyfikować DT całego systemu mikroprocesorowego przygotowujesz tylko plik nakładki. Piszesz normalny plik .dts i kompilujesz go za pomocą dtc. Tylko dajesz rozszerzenie .dtbo żeby było widać, że to overlay. Nie kompiluje się .dtb do .dtbo bo .dtb już jest skompilowane a poza tym oba pliki mają inne zastosowanie. Tak jak kiedyś MS wymyślił, żeby wygaszacze ekranu nie miały rozszerzenia .exe ale .scr, choć format pliku był ten sam i nie kompilowało się exe do scr. Do poczytania na start:

Ok, wczoraj wieczorem udało mi się to rozgryźć. Znalazłem plik dts odnoszący się do jakiegoś gotowego modułu z wyświetlaczem, którego schemat udało mi się znaleźć. Potem analizując strukturę pliku i wykonując parę eksperymentów pozmieniałem parametry tak, że wyświetlacz w końcu zaczął działa ze skompilowanym plikiem dtso, wrzuconym do /boot/overlays.

Teraz mam kolejne pytanie. Pod wpływem tego sukcesu postanowiłem zainstalować większy wyświetlacz na płycie czołowej urządzenia. Wyjąłem z pudełka trzymany tam od jakiegoś czasu 3,2" wyświetlacz, który z tego co pamiętam również ma być oparty na kontrolerze ILI9341 (lub podobnym). Trochę się pospieszyłem z wycięciem dziury pod wyświetlacz i wywierceniem otworów na śrubki, bo dopiero po jego przykręceniu przyjrzałem mu się bliżej i ogarnęły mnie wątpliwości.

Złącze wyświetlacza wygląda tak:

Co prawda znajdują się na nim piny wskazujące na interfejs SPI (MISO, MOSI, CLK i CS), są też tam jednak piny o nazwach wskazujących na 8/16 bitowy interfejs równoległy. Nie widzę nigdy jasno opisanych zworek pozwalających na skonfigurowanie tego w trybie SPI. Nie widzę też PIN-u DC.

Czy ten wyświetlacz będzie się dało podpiąć do SPI bezpośrednio? Ewentualnie są dostępne jakieś konwertery? jeśli nie, to cóż - zamontuję jakiś mniejszy moduł LCD na płytce uniwersalnej, a z przodu przykręcę maskownicę drukowaną w 3D albo wyciętą na laserze. Tylko trochę szkoda mi tego dużego wyświetlacza jednak. :)

Atlantis snipped-for-privacy@wp.pl napisał(a):

Wpisujemy więc w Google 3.2 lcd module, klikamy Grafika i mamy obrazek Twojego modułu. Obrazek jest na stronie

na której mamy wszystko rozpisane.

Z podanej strony wynika, że SPI jest do dotyku, grafika idzie po równoległym.

To już znalazłem. Przy czym zwróć uwagę na to, że to nie jest do końca zdjęcie mojego modułu. Są pewne różnice w PCB - chociażby są tam zworki do ustawiania szerokości magistrali równoległej. Nie ma natomiast zworki J1, która u mnie jest nieobsadzona. Miałem więc cichą nadzieję, że może moją wersję będzie się jakoś dało zmusić do pracy na SPI. :)

Atlantis snipped-for-privacy@wp.pl napisał(a):

Chyba nie bardzo... Twój moduł znalazłem tutaj:

również piszą, że SPI tylko do dotyku.

Dzięki, to wyjaśnia sprawę. Czyli jednak będę musiał zamontować mniejszy wyświetlacz na płytce uniwersalnej i zakryć go maskownicą.

I jeszcze jedno pytanie, w związku z opisywanymi eksperymentami. Nie chcę zakładać kolejnego wątku, więc pytam tutaj.

Przeniosłem wyświetlacz z płyty głównej na płytę czołową urządzenia. Niestety wymagało to użycia wiązki przewodów o długości około 7-8 cm. Stało się coś, czego się obawiałem - pojawiły się problemy z działaniem urządzeń na tej magistrali SPI. Sam wyświetlacz nie chciał już dłużej pracować stabilnie przy prędkości 16 MHz, obniżyłem więc taktowanie. Potem okazało się, że kontroler LAN (ENC28J60) także ma podobne problemy, więc stopniowo obniżałem jego szybkość do 6 MHz, jednak nawet przy tej prędkości pojawiają się chwilowe przerwy w łączności i epizody gubienia pakietów.

Co jest bardziej prawdopodobną przyczyną?

1. Zbyt długie kable i wynikający z nich wzrost pojemności magistrali. Powinienem dać jakiś bufor w pobliżu RasPi?
2. A może bardziej prawdopodobne jest to, że magistrala za sprawą długich kabli łapie zakłócenia od przetwornicy impulsowej, zasilającej cały układ?

W dniu 2021-12-03 o 22:52, Atlantis pisze:

7-8 cm to żadna długość. Raczej zakłócenia. Jak wygląda ta wiązka? Zrób skrętkę, może zaekranuj - powinno pomóc.

Pozdrowienia, MKi

Ok, już znalazłem przyczynę. Głupi błąd montażowy - na płytce brakowało rezystora podciągającego do VCC na linii CS wyświetlacza. W momencie, gdy wyświetlacz znajdował się na płytce i ścieżka miała mniej niż centymetr, wystarczał wewnętrzny pull-up i wszystko było w porządku. Przy dłuższych przewodach to już nie wystarczało i wyświetlacz od czasu do czasu mieszał w komunikacji na magistrali.

Po wlutowaniu brakującego elementu wszystko wróciło do normy i znów mam stabilna pracę, nawet po ustawieniu obydwu urządzeń w tryb 16 MHz.

Podczas normalnej pracy mogę pingować urządzenie po interfejsie ethernetowym i nie zgubi ani jednego pakietu, nawet po dłuższym czasie. No chyba, że obciążę procesor na 100% - wtedy zaczyna już nie wyrabiać i czasem jakiś pakiet się zgubi... No ale to tylko Raspberry Pi Zero, o mocy obliczeniowej porównywalnej chyba do jakiegoś Pentium II. ;)