Jak obsłużyć wyświetlacz SPI TFT ILI9341 na Raspberry Pi Zero po aktualizacji?

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.

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.

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.

On 06.12.2021 11:41, MKi wrote:
7-8 cm to żadna długość.

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.

Hm, obsluga karty powinna byc gdzies w przerwaniach, a potem w jądrze

... wydaje mi sie ze powinna miec wyzszy priorytet, niz programy
użytkownika.

2021-12-06 o 13:46 +0100, J.F napisał:
Hm, obsluga karty powinna byc gdzies w przerwaniach, a potem w jądrze

Współcześnie karty sieciowe nie są już raczej obsługiwane via IRQ, bo
narzut obsługi przerwania dla jednego pakietu jest za wysoki przy
szybkich sieciach (aczkolwiek jak jest przy RPi Zero - przyznaję, nie
wiem).

... wydaje mi sie ze powinna miec wyzszy priorytet, niz programy
użytkownika.

A to swoją drogą.

Mateusz

Cos w tym jest, ale z drugiej strony ... to kiedy system ma sprawdzac,
czy cos na karte nie przyszlo ?

google podrzuca
https://forums.raspberrypi.com/viewtopic.php?t=13058
https://forums.raspberrypi.com/viewtopic.php?f=28&t=7866
J.

J.F <jfox_xnospamx@poczta.onet.pl> napisał(a):
Cos w tym jest, ale z drugiej strony ... to kiedy system ma sprawdzac,
czy cos na karte nie przyszlo ?

Okresowo, w krótkich odstępach. Jak jest duży ruch, to wyłącza się IRQ, a
soft IRQ włącza mechanizm NAPI. Wykonuje on polling w oddzielnym wątku aż
nie odbierze określonej liczby pakietów. Potem się wyłącza i włącza IRQ
spowrotem.

google podrzuca
https://forums.raspberrypi.com/viewtopic.php?t=13058
https://forums.raspberrypi.com/viewtopic.php?f=28&t=7866
J.

To jakieś stare wątki dotyczące innego tematu.

Możesz popatrzeć np. tu:
https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux-networking-stack-receiving-data/#irqs
https://en.wikipedia.org/wiki/New_API

ale czy nie sprzężonego?

"karta" sieciowa nie jest podpieta przez USB?
To chyba wtedy sterownik USB rzadzi przerwaniami ...

J.F <jfox_xnospamx@poczta.onet.pl> napisał(a):
ale czy nie sprzężonego?

Może się mylę, ale wydaje mi się, że nie. Te wątki dotyczyły dużej liczby
przerwań nawet przy braku ruchu.

"karta" sieciowa nie jest podpieta przez USB?
To chyba wtedy sterownik USB rzadzi przerwaniami ...

Obecnie (RPi4) nie jest, była w przeszłości (RPi1-3).

A Atlantis ma Pi Zero.

J.F <jfox_xnospamx@poczta.onet.pl> napisał(a):
A Atlantis ma Pi Zero.

To tym bardziej, bo Zero nie ma Ethernetu. Atlantis dodał Ethernet po SPI.