RTV forum PL | NewsGroups PL

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

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Obsługa wyświetlacza SPI TFT (ILI9341) w no wym Raspbianie

Goto page Previous  1, 2

Grzegorz Niemirowski
Guest

Fri Dec 03, 2021 2:34 pm   



Atlantis <marekw1986NOSPAM_at_wp.pl> napisał(a):
Quote:
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. Smile

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/

Atlantis
Guest

Fri Dec 03, 2021 2:40 pm   



On 03.12.2021 14:34, Grzegorz Niemirowski wrote:

Quote:
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ą.

Atlantis
Guest

Fri Dec 03, 2021 10:52 pm   



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?

MKi
Guest

Mon Dec 06, 2021 11:41 am   



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

Atlantis
Guest

Mon Dec 06, 2021 12:21 pm   



On 06.12.2021 11:41, MKi wrote:

Quote:
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. Wink

Dariusz Dorochowicz
Guest

Mon Dec 06, 2021 12:32 pm   



W dniu 06.12.2021 o 11:41, MKi pisze:
Quote:
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.

Może pull-up jest nieobecny? Niby nie jest wymagany, ale może pomóc.
Oczywiście we właściwym miejscu, tzn na końcu linii.
A może słaba masa?

Pozdrawiam

DD

J.F
Guest

Mon Dec 06, 2021 1:46 pm   



On Mon, 6 Dec 2021 12:21:04 +0100, Atlantis wrote:
Quote:
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. Wink

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.

J.

Mateusz Viste
Guest

Mon Dec 06, 2021 2:07 pm   



2021-12-06 o 13:46 +0100, J.F napisał:
Quote:
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).

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

A to swoją drogą.

Mateusz

J.F
Guest

Mon Dec 06, 2021 3:56 pm   



On Mon, 6 Dec 2021 14:07:12 +0100, Mateusz Viste wrote:
Quote:
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).

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.

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

A to swoją drogą.

Mateusz


Grzegorz Niemirowski
Guest

Mon Dec 06, 2021 4:57 pm   



J.F <jfox_xnospamx_at_poczta.onet.pl> napisał(a):
Quote:
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.

Quote:

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

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

J.F
Guest

Tue Dec 07, 2021 9:52 am   



On Mon, 6 Dec 2021 16:57:03 +0100, Grzegorz Niemirowski wrote:
Quote:
J.F <jfox_xnospamx_at_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.

Ma to jakis sens ... tylko pamieci na pakiety musi starczyc, a karty
teraz szybkie :-)

Quote:

ale czy nie sprzężonego?
"karta" sieciowa nie jest podpieta przez USB?
To chyba wtedy sterownik USB rzadzi przerwaniami ...

Quote:

Dzieki, w wolnej chwili popatrze.

J.

Grzegorz Niemirowski
Guest

Tue Dec 07, 2021 10:02 am   



J.F <jfox_xnospamx_at_poczta.onet.pl> napisał(a):
Quote:
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.

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

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

J.F
Guest

Tue Dec 07, 2021 10:20 am   



On Tue, 7 Dec 2021 10:02:28 +0100, Grzegorz Niemirowski wrote:
Quote:
J.F <jfox_xnospamx_at_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.

Chodzi mi o samo podlaczenie interfejsu sieci przez USB.


Quote:
"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.

Grzegorz Niemirowski
Guest

Tue Dec 07, 2021 10:43 am   



J.F <jfox_xnospamx_at_poczta.onet.pl> napisał(a):
Quote:
A Atlantis ma Pi Zero.

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

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

J.F
Guest

Tue Dec 07, 2021 10:55 am   



On Tue, 7 Dec 2021 10:43:00 +0100, Grzegorz Niemirowski wrote:
Quote:
J.F <jfox_xnospamx_at_poczta.onet.pl> napisał(a):
A Atlantis ma Pi Zero.

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

A, no tak.
Czyli szukamy jak tam w kernelu jest SPI obslugiwany :)

J.

Goto page Previous  1, 2

elektroda NewsGroups Forum Index - Elektronika Polska - Obsługa wyświetlacza SPI TFT (ILI9341) w no wym Raspbianie

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map