Mam pewien projekt oparty na Raspberry Pi Zero, w którym wykorzystuję
wyświetlacz SPI na ILI9341. Na karcie pamięci siedzi Raspbian Bullseye.
Do obsługi wyświetlacza używam samodzielnie skompilowanego pliku dtbo,
wrzuconego do /boot/overlays - musiałem go samodzielnie skompilować,
ponieważ używam trochę innego zestawu pinów niż to przewidziano w
standardowym sterowniku rpi-display.dtbo.

Do tej pory wszystko działało w pełni poprawnie:
1) Niedługo po uruchomieniu systemu inicjował się sterownik wyświetlacza
i pokazywał komunikaty systemowe w konsoli.
2) W chwilę potem w /etc/rc.local wywoływane było polecenie sudo
FRAMEBUFFER=/dev/fb1 startx&
3) Następnie w .xinitrc uruchamiał się zegarek (xclock -update 1 -hd red
-norender) - docelowo miał zostać zastąpiony przez moją własną aplikację
z GUI.

Korzystając z faktu, że musiałem ostatnio zainstalować kilka programów,
wyłączyłem overlayfs i zrobiłem aktualizację systemu (sudo apt-get
update && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y).

Jednak aktualizacja w jakiś dziwny sposób zepsuła mi działanie
wyświetlacza. W skrócie wygląda to następująco:
- Plik /dev/fb1 nadal istnieje w systemie.
- Dmesg pokazuje, że inicjacja wyświetlacza przebiega prawidłowo.
- Przez krótką chwilę podczas uruchamiania systemu wyświetlacz
rozświetla się na biało, a potem może przez sekundę czy dwie pokazuje
komunikaty w konsoli. Zaraz potem gaśnie i robi się czarny.
- Konsola jest też widoczna przez ułamek sekundy przy zamykaniu systemu.
- Niemal na pewno nie odpowiada za to system okienkowy, bo problem
występuje także po zakomentowaniu komendy "startx" w rc.local.

Ktoś ma jakiś pomysł co może za to odpowiadać?

do góry

poniedziałek, 4 kwietnia 2022 o 09:22:14 UTC-5 Atlantis napisał(a):
> Mam pewien projekt oparty na Raspberry Pi Zero, w którym wykorzystuję
> wyświetlacz SPI na ILI9341. Na karcie pamięci siedzi Raspbian Bullseye.
> Do obsługi wyświetlacza używam samodzielnie skompilowanego pliku dtbo,
> wrzuconego do /boot/overlays - musiałem go samodzielnie skompilować,
> ponieważ używam trochę innego zestawu pinów niż to przewidziano w
> standardowym sterowniku rpi-display.dtbo.
>
> Do tej pory wszystko działało w pełni poprawnie:
> 1) Niedługo po uruchomieniu systemu inicjował się sterownik wyświetlacza
> i pokazywał komunikaty systemowe w konsoli.
> 2) W chwilę potem w /etc/rc.local wywoływane było polecenie sudo
> FRAMEBUFFER=/dev/fb1 startx&
> 3) Następnie w .xinitrc uruchamiał się zegarek (xclock -update 1 -hd red
> -norender) - docelowo miał zostać zastąpiony przez moją własną aplikację
> z GUI.
>
> Korzystając z faktu, że musiałem ostatnio zainstalować kilka programów,
> wyłączyłem overlayfs i zrobiłem aktualizację systemu (sudo apt-get
> update && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y).
>
> Jednak aktualizacja w jakiś dziwny sposób zepsuła mi działanie
> wyświetlacza. W skrócie wygląda to następująco:
> - Plik /dev/fb1 nadal istnieje w systemie.
> - Dmesg pokazuje, że inicjacja wyświetlacza przebiega prawidłowo.
> - Przez krótką chwilę podczas uruchamiania systemu wyświetlacz
> rozświetla się na biało, a potem może przez sekundę czy dwie pokazuje
> komunikaty w konsoli. Zaraz potem gaśnie i robi się czarny.
> - Konsola jest też widoczna przez ułamek sekundy przy zamykaniu systemu.
> - Niemal na pewno nie odpowiada za to system okienkowy, bo problem
> występuje także po zakomentowaniu komendy "startx" w rc.local.
>
> Ktoś ma jakiś pomysł co może za to odpowiadać?

Trudno powiedziec na odleglosc.
Sprobuj poubijac procesy i inicjalizowac wyswietlacz ponownie po kazdym ubiciu. Moze
znajdziesz ktory przykrywa ekran na czarno.
Obstawiam ze jak robiles update to cos dodatkowego sie zaciagnelo jako zaleznosc i
teraz bruzdzi.
Nie pamietam czy da sie latwo stwierdzic ktory proces ma otwarte piny do zapisu. Nie
wiem czy lsof pokaze cos ciekawego ale warto sprobowac.

Jak robisz inicjalizacje juz po starcie to jakies bledy wypluwa? czy po prostu jest
czarno? nie wyczytalem czy to oled czy po prostu podswietlenie jest zgaszone...

do góry

Atlantis <m...@w...pl> napisał(a):
> Mam pewien projekt oparty na Raspberry Pi Zero,

Właściwiej chyba będzie zapytać na pl.comp.os.linux

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

do góry

On 04.04.2022 16:51, ptoki wrote:

> Trudno powiedziec na odleglosc. Sprobuj poubijac procesy i
> inicjalizowac wyswietlacz ponownie po kazdym ubiciu.

Ok, już mam. Wychodzi na to, że nie był za to odpowiedzialny żaden z
procesów. Pomogło zamienienie jednego parametru w kodzie źródłowym pliku
dtbo z "1" na "0". Jeśli dobrze to interpretuję to odpowiada on za
odwrócenie logiki działania linii sterującej podświetleniem. Przed
aktualizacją systemu ten parametr musiał być ignorowany, przynajmniej
taka jest moja robocza hipoteza.

do góry

poniedziałek, 4 kwietnia 2022 o 11:39:22 UTC-5 Atlantis napisał(a):
> On 04.04.2022 16:51, ptoki wrote:
>
> > Trudno powiedziec na odleglosc. Sprobuj poubijac procesy i
> > inicjalizowac wyswietlacz ponownie po kazdym ubiciu.
> Ok, już mam. Wychodzi na to, że nie był za to odpowiedzialny żaden z
> procesów. Pomogło zamienienie jednego parametru w kodzie źródłowym pliku
> dtbo z "1" na "0". Jeśli dobrze to interpretuję to odpowiada on za
> odwrócenie logiki działania linii sterującej podświetleniem. Przed
> aktualizacją systemu ten parametr musiał być ignorowany, przynajmniej
> taka jest moja robocza hipoteza.

Gratulacje :)
A u mnie testuje sie 200 stopniowa kamerka
roznica miedzy 160 stopni a 200 to przepasc
ale mam com chcial. Widac co ma byc widac.
Teraz huginem musze to ponaciagac spowrotem.

do góry

ptoki <s...@g...com> wrote:

> Gratulacje :)
> A u mnie testuje sie 200 stopniowa kamerka

Jaki model?

--
Po roku studiow przyjezdza do domu studentka i od progu wola:
- Mamo, mam chlopaka!
- Swietnie coreczko, a gdzie studiuje?
- Alez mamo, on ma dopiero dwa miesiace!

do góry

środa, 6 kwietnia 2022 o 04:18:27 UTC-5 Arnold Ziffel napisał(a):
> ptoki <s...@g...com> wrote:
>
> > Gratulacje :)
> > A u mnie testuje sie 200 stopniowa kamerka
> Jaki model?
>
waveshare model M
Maja pare innych modeli. Ale wszystkie to raczej malinowa kamerka v1.
v2 jest nieco lepsza ale te to chyba tylko w wersji 72stopnie mozna dostac.

te 200 to jest masakra. Z jednej strony widzi az za siebie a z drugiej tam nie ma
zadnego rozciagania wiec obraz jest w sumie na kole o srednicy wysokosci obrazu.

Ale zrobilem pare szybkich fotek i hugin znosnie calosc polaczyl.

Mozna u waveshare kupic kabelek ktory umozliwia przelaczanie sie miedzy dwiema
kamerkami na jednej malinie.
Nie testowalem jeszcze tego co mam.

do góry

ptoki <s...@g...com> wrote:

> te 200 to jest masakra. Z jednej strony widzi az za siebie a z drugiej
> tam nie ma zadnego rozciagania wiec obraz jest w sumie na kole o
> srednicy wysokosci obrazu.

Pokazałbyś jak to wygląda prosto z kamery, przed obróbką Huginem?

--
Mrówek ucieka z lasu i nagle na swej drodze spotyka leśniczego :
- Co się stało? - pyta leśniczy
- Ktoś zgwałcił słonicę. Wszyscy są podejrzani.

do góry

czwartek, 7 kwietnia 2022 o 07:06:14 UTC-5 Arnold Ziffel napisał(a):
> ptoki <s...@g...com> wrote:
>
> > te 200 to jest masakra. Z jednej strony widzi az za siebie a z drugiej
> > tam nie ma zadnego rozciagania wiec obraz jest w sumie na kole o
> > srednicy wysokosci obrazu.
> Pokazałbyś jak to wygląda prosto z kamery, przed obróbką Huginem?
>
https://imgur.com/a/rc8f7pA
Wisi se byle jak przed oknem od wewnatrz
Rozdzielczosc randomowa, testuje jak sie zachowuje.

do góry

czwartek, 7 kwietnia 2022 o 07:06:14 UTC-5 Arnold Ziffel napisał(a):
> ptoki <s...@g...com> wrote:
>
> > te 200 to jest masakra. Z jednej strony widzi az za siebie a z drugiej
> > tam nie ma zadnego rozciagania wiec obraz jest w sumie na kole o
> > srednicy wysokosci obrazu.
> Pokazałbyś jak to wygląda prosto z kamery, przed obróbką Huginem?
>
>
Dla porownania standardowa v2 malinowa:
https://imgur.com/a/x7JTv5h
ta ma chyba 60 stopni, albo 72, nie pamietam

do góry