On 01.12.2021 23:12, heby wrote:

> Masz te parametry podane w lini opcji jądra i/lub /etc/modules?
>
> https://tlfong01.blog/2020/05/23/mgd-blog-ili9341-sc
reen-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.

do góry

Atlantis <m...@w...pl> napisał(a):
> 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.

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-beagl
ebone-black-device-tree/compiling-an-overlay

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

do góry

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. :)

do góry

Atlantis <m...@w...pl> napisał(a):
> Złącze wyświetlacza wygląda tak:
> https://ibb.co/3CTV7Yx

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.

> 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. :)

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

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

do góry

On 03.12.2021 13:47, Grzegorz Niemirowski wrote:

> 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.

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. :)

do góry

Atlantis <m...@w...pl> napisał(a):
> 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. :)

Chyba nie bardzo... Twój moduł znalazłem tutaj:
https://pl.aliexpress.com/item/32609689069.html
Tu również piszą, że SPI tylko do dotyku.

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

do góry

On 03.12.2021 14:34, Grzegorz Niemirowski wrote:

> Chyba nie bardzo... Twój moduł znalazłem tutaj:
> https://pl.aliexpress.com/item/32609689069.html
> Tu 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ą.

do góry

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?

do góry

W dniu 2021-12-03 o 22:52, Atlantis pisze:
> 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?

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

do góry

On 06.12.2021 11:41, MKi wrote:

> 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.

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. ;)

do góry