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

Wed Nov 24, 2021 5:07 pm   

Powróciłem ostatnio do starego projektu na Raspberry Pi Zero, który od
dłuższego czasu leżał w szufladzie. Po odpaleniu i zalogowaniu przez SSH
stwierdziłem, że zainstalowany jest na nim przestarzały Raspbian Jessie.
Podniosłem go więc najpierw do Stretcha, a potem Bustera.

Niestety okazało się, że ta druga aktualizacja zepsuła działanie małego
wyświetlacza LCD na SPI, który był obsługiwany za pomocą modułu jądra
fbtft_device, identyfikował się w systemie jako /dev/fb1 i można było na
nim uruchomić programy systemu okienkowego X.

Konfiguracja wyświetlacza była zawarta w pliku /etc/modprobe/fbtft.conf
options fbtft_device custom name=fb_ili9341 rotate=90 speed=16000000
fps=50 bgr=1 buswidth=8 cs=1 gpios=reset:23,dc:24,led:25

Niestety, próba wywołanie sudo modprobe z tymi parametrami powoduje
wywalenie komunikatu:

modprobe: FATAL: Module fbtft_device not found in directory
/lib/modules/5.10.63+

Wygląda więc na to, że ten moduł jądra nie jest kompatybilny z kernelem
5/4 i został usunięty.

Ktoś może orientuje się w jaki sposób obecnie należy korzystać z tych
wyświetlaczy? Google zwraca głównie nieaktualne opisu tej już
nieaktualnej metody, a także tutoriale do obsługi wyświetlaczy
bezpośrednio, z poziomu Pythona.

Zależy mi szczególnie na tym, żeby w konfiguracji dało się wybrać te
same piny, z których korzystałem oryginalne - urządzenie ma już
zaprojektowaną płytkę i np. drugi pin CE interfejsu SPI jest używany
przez inne urządzenie.

Wed Nov 24, 2021 9:14 pm   

On 24/11/2021 17:07, Atlantis wrote:

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

Instalacja od zera nie działa?

https://learn.watterott.com/hats/rpi-display/fbtft-install/

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

https://github.com/notro/fbtft/issues/10

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

Thu Nov 25, 2021 12:16 am   

On 24.11.2021 21:14, heby wrote:


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.

Thu Nov 25, 2021 7:57 pm   

On 25/11/2021 00:16, Atlantis wrote:

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.

Fri Nov 26, 2021 9:01 pm   

On 25.11.2021 19:57, heby wrote:


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.

Fri Nov 26, 2021 9:06 pm   

On 26/11/2021 21:01, Atlantis wrote:

HDMI:

MPI3508.


Nic nie trzeba konfigurowac, działa z HDMI.

Fri Nov 26, 2021 11:09 pm   

On 26.11.2021 21:06, heby wrote:


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.

Fri Nov 26, 2021 11:15 pm   

On 26/11/2021 23:09, Atlantis wrote:

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.

Wed Dec 01, 2021 10:45 pm   

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?

Wed Dec 01, 2021 11:12 pm   

On 01/12/2021 22:45, Atlantis wrote:

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/

Thu Dec 02, 2021 6:49 pm   

On 01.12.2021 23:12, heby wrote:


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.

Fri Dec 03, 2021 1:35 am   

Atlantis <marekw1986NOSPAM@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:
https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/compiling-an-overlay

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Fri Dec 03, 2021 1:39 pm   

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:
https://ibb.co/3CTV7Yx

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.

Fri Dec 03, 2021 1:47 pm   

Atlantis <marekw1986NOSPAM@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
http://www.lcdwiki.com/3.2inch_16BIT_Module_ILI9341_SKU:MRB3205 na której
mamy wszystko rozpisane.


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

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Fri Dec 03, 2021 2:17 pm   

On 03.12.2021 13:47, Grzegorz Niemirowski wrote:


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.