ILI9486 Display von Raspberry auf STM32 portieren

[Daniel F. (lmdaniel999)]

Hallo zusammen,

ich habe ein Problem mit einem Display: 
https://www.berrybase.de/raspberry-pi-co/raspberry-pi/displays/3-5-display-f-252-r-raspberry-pi-mit-resistivem-touchscreen

Das Display ist für den Raspberry Pi gedacht, ich betreibe es aber am 
STM32H7. Es "scheint" einen ILI9486 Controller zu haben. Deshalb habe 
ich diverse Libs für den Controller getestet und mich für eine 
entschieden. Daraus dann eine Applikation erstellt.

Nun habe ich mehrere dieser Displays gekauft und an mehrere gleiche 
selbst entwickelte Boards angeschlossen. Nachdem ca. 50% der Displays 
nicht funktionierten, bin ich auf Fehlersuche gegangen.

Die Displays sind scheinbar unterschiedlich. Das Platinen Layout ist 
leicht unterschiedlich. Die Bauteile sind gleich.
Scheint, als ob auf der Platine unterschiedliche LCD-Module verbaut 
sind. Und bis auf eine Ausnahme funktionieren alle mit Layout 1 und 
keines mit Layout 2.
Laut Händler sind die Displays aber alle gleich und verwenden alle den 
gleichen Controller.

Das Layout, welches am STM32 nicht funktioniert, funktioniert aber am 
Raspberry Pi mit der Waveshare Lib. Daher kann ich einen Defekt der 
Displays ausschließen.

Ich habe nun schon diverse Initialisierungsroutinen aus diversen 
Librarys getestet. Auch schon verschiedene Routinen vom 
Controllerhersteller.
Ich bekomme die eine Hälfte der Displays aktuell nicht zum Laufen!

Kann es sein, dass der Raspberry innerhalb der Waveshare Library 
verschiedene Displaytypen automatisch erkennt und die Initialisierung 
anpasst?

Kann man diese Initialisierungsroutine aus dem Treiber herausfinden, die 
der Raspberry nutzt? Außer, dass ich einen Logger per SPI anschließe, 
der vermutlich eh nicht die ganze Init-Phase auf einmal aufnehmen 
kann...

Ich hoffe, dass einer schonmal ein ähnliches Problem hatte und mir einen 
Tip geben kann! :-)

[Dennis H. (c-logic)]

"Kann es sein, dass der Raspberry innerhalb der Waveshare Library
verschiedene Displaytypen automatisch erkennt und die Initialisierung
anpasst?"

Ja.

Read display identification information (Register 04h)

Der overlay von waveshare35a nutzt z.B. den Treiber ili9486

waveshare35a: waveshare35a@0{
        compatible = "ilitek,ili9486";
        reg = <0>;
        pinctrl-names = "default";
        pinctrl-0 = <&waveshare35a_pins>;

        spi-max-frequency = <16000000>;
        txbuflen = <32768>;
        rotate = <90>;
        bgr = <0>;
        fps = <30>;
        buswidth = <8>;
        regwidth = <16>;
        reset-gpios = <&gpio 25 1>;
        dc-gpios = <&gpio 24 0>;
        debug = <0>;

        init = <0x10000b0 0x00
                0x1000011
          0x20000ff
          0x100003a 0x55
          0x1000036 0x28
          0x10000c2 0x44
          0x10000c5 0x00 0x00 0x00 0x00
          0x10000e0 0x0f 0x1f 0x1c 0x0c 0x0f 0x08 0x48 0x98 0x37 0x0a 
0x13 0x04 0x11 0x0d 0x00
          0x10000e1 0x0f 0x32 0x2e 0x0b 0x0d 0x05 0x47 0x75 0x37 0x06 
0x10 0x03 0x24 0x20 0x00
          0x10000e2 0x0f 0x32 0x2e 0x0b 0x0d 0x05 0x47 0x75 0x37 0x06 
0x10 0x03 0x24 0x20 0x00
          /* piscreen -> waveshare35a */
          0x1000036 0x28
          0x1000011
          0x1000029>;
      };
https://github.com/swkim01/waveshare-dtoverlays/blob/master/waveshare35a.dts

[Mitlesa (Gast)]

Dennis H. schrieb:
> Ja.

Nein.

Die 3.5" Displays für Raspberry die ich kenne haben ein "dummes"
16-Bit Schieberegister das nur schreiben kann, selbst der CS
wird hardwaremässig (am Ende eines 16 Bit Write durch Zähler)
generiert. Wer auf die Leiterplatte schaut kann sich das auch
selbst aufgrund der einfachen "Käfer-Konfiguration" zusammen-
reimem. Eine Schreib-/Leseumschaltung wäre deutlich aufwendiger.

Wie sonst die Displays erkannt bzw unterschieden werden sollen
kann ich mir beim besten Willen nicht vorstellen.

[Mitlesa (Gast)]

Hier die meistens verwendete Schaltung, minimalistisch, billig
und ohne Lesefunktion. Read Leitung statisch auf high gelegt.

YMMV

[Mitlesa (Gast)]

Daniel F. schrieb:
> Kann man diese Initialisierungsroutine aus dem Treiber herausfinden, die
> der Raspberry nutzt?

Ja, Dennis hat sie dir schon gezeigt.

Suche nach dem magischen Schlüsselwort "init".

Aber ich würde eher nach einem kleinsten gemeinsamen Init-Code
suchen. Vermutlich sind beide Sorten von Display-Controllern
ILI9486 und ILI9488 in Verwendung die sich beide nur minimal
voneinander unterscheiden.

[Dennis H. (c-logic)]

Mitlesa schrieb:
> Dennis H. schrieb:
>> Ja.
>
> Nein.
>
> Die 3.5" Displays für Raspberry die ich kenne haben ein "dummes"
> 16-Bit Schieberegister das nur schreiben kann, selbst der CS
> wird hardwaremässig (am Ende eines 16 Bit Write durch Zähler)
> generiert. Wer auf die Leiterplatte schaut kann sich das auch
> selbst aufgrund der einfachen "Käfer-Konfiguration" zusammen-
> reimem. Eine Schreib-/Leseumschaltung wäre deutlich aufwendiger.
>
> Wie sonst die Displays erkannt bzw unterschieden werden sollen
> kann ich mir beim besten Willen nicht vorstellen.

Danke für die Info. Das die Waveshare-Displays so minimalistisch sind 
wusste ich nicht.

Dann könnte eine Übernahme der Initialisierung vom RPi-Overlay 
vielleicht helfen.

Ah. Noch ein Tipp. Die (A) und (B) Versionen sind recht lahm vom Takt 
her.

[Daniel F. (lmdaniel999)]

Hi,

danke für die Antworten, werde den Init Code gleich probieren!

Ich hätte gerne einen minimalistischen Init Code, der für beide 
funktioniert. Das war mein Ziel. Bei google habe ich keine Init von dem 
Raspberry Treiber gefunden, nur irgendwelche Libs, die ich schon alle 
durch hatte.

Da ich mich aber schon ein paar Tage damit beschäftige, drehe ich mich 
aber vermutlich im Kreis...

Die Displays, die ich verwende, sind keine Waveshare Displays. Meine 
haben auch die Schieberegister, die per SPI beschrieben werden. Rein aus 
Interesse: Kann man die Waveshare auslesen, oder die auch nicht?

[Daniel F. (lmdaniel999)]

Dennis H. schrieb:
> init = <0x10000b0 0x00
>                 0x1000011
>           0x20000ff
>           0x100003a 0x55
>           0x1000036 0x28

Ich hab den Init Code getestet, ohne Erfolg. Bzw. wieder bei einigen 
geht er, bei anderen nicht....

Was bedeutet die 0x20000ff?

Ich habe folgenden Init-code:

   HAL_GPIO_WritePin(resetPORT, resetPIN, GPIO_PIN_SET);
   HAL_Delay(120);

   //Turn LCD ON
   ILI9486_SendCommand (0xB0); // Interface Mode Control
   ILI9486_SendData    (0x00);

   ILI9486_SendCommand (0x11); // Sleep out, also SW reset
   HAL_Delay(120);

   ILI9486_SendCommand (0x3A); // Interface Pixel Format
   ILI9486_SendData    (0x55);

   ILI9486_SendCommand (0x36); // Memory Access Control
   ILI9486_SendData    (0x28);

   ILI9486_SendCommand (0xC2); //  Power/Reset on default
   ILI9486_SendData    (0x44);

   ILI9486_SendCommand (0xC5); // VCOM Control
   ILI9486_SendData    (0x00);
   ILI9486_SendData    (0x00);
   ILI9486_SendData    (0x00);
   ILI9486_SendData    (0x00);

   ILI9486_SendCommand (0xE0); // PGAMCTRL(Positive Gamma Control)
   ILI9486_SendData    (0x0F); //HSD
   ILI9486_SendData    (0x1F); //HSD
   ILI9486_SendData    (0x1C); //HSD
   ILI9486_SendData    (0x0C); //HSD
   ILI9486_SendData    (0x0F); //HSD
   ILI9486_SendData    (0x08); //HSD
   ILI9486_SendData    (0x48); //HSD
   ILI9486_SendData    (0x98); //HSD
   ILI9486_SendData    (0x37); //HSD
   ILI9486_SendData    (0x0A); //HSD
   ILI9486_SendData    (0x13); //HSD
   ILI9486_SendData    (0x04); //HSD
   ILI9486_SendData    (0x11); //HSD
   ILI9486_SendData    (0x0D); //HSD
   ILI9486_SendData    (0x00); //HSD

   ILI9486_SendCommand (0xE1); // NGAMCTRL (Negative Gamma Correction)
   ILI9486_SendData    (0x0F); //HSD
   ILI9486_SendData    (0x32); //HSD
   ILI9486_SendData    (0x2E); //HSD
   ILI9486_SendData    (0x0B); //HSD
   ILI9486_SendData    (0x0D); //HSD
   ILI9486_SendData    (0x05); //HSD
   ILI9486_SendData    (0x47); //HSD
   ILI9486_SendData    (0x75); //HSD
   ILI9486_SendData    (0x37); //HSD
   ILI9486_SendData    (0x06); //HSD
   ILI9486_SendData    (0x10); //HSD
   ILI9486_SendData    (0x03); //HSD
   ILI9486_SendData    (0x24); //HSD
   ILI9486_SendData    (0x20); //HSD
   ILI9486_SendData    (0x00); //HSD

   ILI9486_SendCommand (0xE2);
   ILI9486_SendData    (0x0F);
   ILI9486_SendData    (0x32);
   ILI9486_SendData    (0x2E);
   ILI9486_SendData    (0x0B);
   ILI9486_SendData    (0x0D);
   ILI9486_SendData    (0x05);
   ILI9486_SendData    (0x47);
   ILI9486_SendData    (0x75);
   ILI9486_SendData    (0x37);
   ILI9486_SendData    (0x06);
   ILI9486_SendData    (0x10);
   ILI9486_SendData    (0x03);
   ILI9486_SendData    (0x24);
   ILI9486_SendData    (0x20);
   ILI9486_SendData    (0x00);

   ILI9486_SendCommand (0x36); // Memory Access Control
   ILI9486_SendData    (0x28); //44

   ILI9486_SendCommand (0x11); // Sleep out, also SW reset
   HAL_Delay(120);
   ILI9486_SendCommand (0x29); // Display ON
   HAL_Delay(120);

Noch eine Frage:
Wo stammt denn der Init-Codeabschnitt von oben her?
Aus dem Raspberry Treiber? Dort habe ich sowas gesucht, aber nicht 
gefunden...

[Mitlesa (Gast)]

Daniel F. schrieb:
> Kann man die Waveshare auslesen, oder die auch nicht?

Der Schaltplan den ich gepostet habe enthält das Zauberwort
Waveshare. Oder wolltest oder konntest du den Schalplan nicht
lesen?

Und ich behaupte mal dass diese Diplays bis 3.5" oder 4.0"
alle die gleiche Logik zum Ansteuern haben.

Poste doch einfach mal ein (detailliertes) Foto von der
Rückseite deines Displays.

[Mitlesa (Gast)]

Daniel F. schrieb:
> Wo stammt denn der Init-Codeabschnitt von oben her?

Von wo oben? Oben ist gross, und ich sehe gerade nicht wo
du oben hinschaust.

[Daniel F. (lmdaniel999)]

Mitlesa schrieb:
> Daniel F. schrieb:
>> Kann man die Waveshare auslesen, oder die auch nicht?
>
> Der Schaltplan den ich gepostet habe enthält das Zauberwort
> Waveshare. Oder wolltest oder konntest du den Schalplan nicht
> lesen?
>
> Und ich behaupte mal dass diese Diplays bis 3.5" oder 4.0"
> alle die gleiche Logik zum Ansteuern haben.
>
> Poste doch einfach mal ein (detailliertes) Foto von der
> Rückseite deines Displays.

Hab ich zu spät im Schaltplan gesehen, konnte aber meine Frage nicht 
mehr bearbeiten.

Anbei ein Bild der Displays mit den unterschiedlichen Layouts.
Das Linke funktioniert beim STM32 und am RPi, das Rechte nur am RPi.

Mitlesa schrieb:
> Daniel F. schrieb:
>> Wo stammt denn der Init-Codeabschnitt von oben her?
>
> Von wo oben? Oben ist gross, und ich sehe gerade nicht wo
> du oben hinschaust.

Ich meinte den folgenden Codabschnitt aus einem der Threads "über" dem 
Aktuellen, wenn man "hoch" scrollt... Entschuldige meine unklare 
Ausdrucksweise, die manche Menschen verwirrt.... ;-)

Dennis H. schrieb:
> waveshare35a: waveshare35a@0{
>         compatible = "ilitek,ili9486";
>         reg = <0>;
>         pinctrl-names = "default";
>         pinctrl-0 = <&waveshare35a_pins>;
>
>         spi-max-frequency = <16000000>;
>         txbuflen = <32768>;
>         rotate = <90>;
>         bgr = <0>;
>         fps = <30>;
>         buswidth = <8>;
>         regwidth = <16>;
>         reset-gpios = <&gpio 25 1>;
>         dc-gpios = <&gpio 24 0>;
>         debug = <0>;
>
>         init = <0x10000b0 0x00
>                 0x1000011
>           0x20000ff
>           0x100003a 0x55
>           0x1000036 0x28
>           0x10000c2 0x44
>           0x10000c5 0x00 0x00 0x00 0x00
>           0x10000e0 0x0f 0x1f 0x1c 0x0c 0x0f 0x08 0x48 0x98 0x37 0x0a
> 0x13 0x04 0x11 0x0d 0x00
>           0x10000e1 0x0f 0x32 0x2e 0x0b 0x0d 0x05 0x47 0x75 0x37 0x06
> 0x10 0x03 0x24 0x20 0x00
>           0x10000e2 0x0f 0x32 0x2e 0x0b 0x0d 0x05 0x47 0x75 0x37 0x06
> 0x10 0x03 0x24 0x20 0x00
>           /* piscreen -> waveshare35a */
>           0x1000036 0x28
>           0x1000011
>           0x1000029>;
>       };

[Mitlesa (Gast)]

Daniel F. schrieb:
> Das Linke funktioniert beim STM32 und am RPi, das Rechte nur am RPi.

Ist doch eindeutig der gleiche Schaltplan, nur die Leitungsführung
ist gerinfügig anders.

Ich vermute immer noch minimale Unterschiede ILI9486 vs. ILI9488.
Dann denke ich auch mal an deinen Aufbau der das schlechte Signal-
Handling des Displays vielleicht noch schlechter macht.

Einfacher Test wäre auch einfach mal den SPI Takt auf niedrige
Werte, z.B. 2 MHz, herunterzufahren.

Was ich an diesen Leiterplatten grundsätzlich schlecht finde ist
dass an den vier Digitalbausteinen U1 bis U4 keine Ahbblock-
Kondensatoren vorgesehen wurden. Ein schwerwiegender Fehler der
nur zu minimalen Einsparungen führt aber die Betriebssicherheit
deutlich verringert.

Vielleicht haben "sie" irgendwann mal gemerkt dass doch mit ein
paar Störungen zu rechnen ist und das Layout so geändert dass es
doch noch ohne Ahbblock-Kondensatoren funktioniert. Im Extremfall
dann vielleicht nicht mehr.

Zeig doch mal deinen Aufbau.

[Franz M. (elmo64)]

Daniel F. schrieb:
> Anbei ein Bild der Displays mit den unterschiedlichen Layouts.
> Das Linke funktioniert beim STM32 und am RPi, das Rechte nur am RPi.

Das unterschiedliche Layout lässt möglicherweise auf unterschiedliche 
Panels schließen.
Löse das Pannel je eines Display-Boards, das am STM32 nicht-, bzw. 
funktioniert und such dir die passenden Datenblätter bei zum Beispiel 
google oder www.panelook.com. Bei den fertigen Display-Modulen 
garantiert keiner, das wirklich der Display-Controller drinnen ist, mit 
dem geworben wird.
Pass beim durchtrennen des Schaumstoffes auf die Flexplatine auf.

Schaue auch mal hier: http://www.lcdwiki.com/Main_Page

Daniel F. schrieb:
> Kann man die Waveshare auslesen, oder die auch nicht?

Grundsätzlich kann man die Meisten üblicherweise auf solchen Boards 
verbauten Pannels lesen, nur der SPI Adapter...

Mitlesa schrieb:
> Hier die meistens verwendete Schaltung, minimalistisch, billig
> und ohne Lesefunktion. Read Leitung statisch auf high gelegt.

[Dennis H. (c-logic)]

Der Code ist aus der
https://github.com/swkim01/waveshare-dtoverlays/blob/master/waveshare35a.dts
ich nehm mal an du hast es per script auf dem Raspberry installiert ?

nach den Anweisungen von

https://www.berrybase.de/raspberry-pi-co/raspberry-pi/displays/3-5-display-f-252-r-raspberry-pi-mit-resistivem-touchscreen

mit ./LCD35-show ?

[Daniel F. (lmdaniel999)]

SPI Geschwindigkeit reduzieren bringt nichts... :-(

Hab eines der nicht-funktionierenden Displays zerlegt, finde aber keinen 
Hersteller. Anbei sind die Bilder, vielleicht kommt es ja jmd. bekannt 
vor...

Es gibt einen Hersteller "sky lcd", aber dort finde ich kein Display, 
was so aussieht. Ich werde dort mal anfragen...

Den Init-Code vom ILI9488 werde ich auch mal testen und mein Ergebnis 
berichten!

[Daniel F. (lmdaniel999)]

Dennis H. schrieb:
> Der Code ist aus der
> https://github.com/swkim01/waveshare-dtoverlays/blob/master/waveshare35a.dts
> ich nehm mal an du hast es per script auf dem Raspberry installiert ?
>
> nach den Anweisungen von
>
> 
https://www.berrybase.de/raspberry-pi-co/raspberry-pi/displays/3-5-display-f-252-r-raspberry-pi-mit-resistivem-touchscreen
>
> mit ./LCD35-show ?

Ja genau, hab es per Script installiert.
Die Datei schau ich mir an, danke!

[Dennis H. (c-logic)]

DTS ist die Source von der Device Tree Blob Overlay. Und so wie ich das 
gesehen hab installiert das Script die waveshare35a.dtbo und baut sie in 
die /boot/config.txt

[Mitlesa (Gast)]

Ich wiederhole hiermit mein Anliegen / meine Aufforderung:

Mitlesa schrieb:
> Zeig doch mal deinen Aufbau.

Auch darauf kann es ankommen, believe it or not. If not, I call
you beratungsresistent.

Stelle dir vor du schliesst dein Display an den H7 genau so
mit knappen Leitungen, guter Masse und stabilisierter Versorgung
(inkl. Abblockung) an wie am Raspberry  .... was schon nicht
ganz einfach ist ....

Sorry aber ich habe schon zu viel Scheisse gesehen. Deshalb frage
ich regelmässig bei solchen Gelegenheiten nach dem Aufbau.

Um den gedanklichen Kontext noch besser herzustellen nochmal dies:

Mitlesa schrieb:
> Vielleicht haben "sie" irgendwann mal gemerkt dass doch mit ein
> paar Störungen zu rechnen ist und das Layout so geändert dass es
> doch noch ohne Ahbblock-Kondensatoren funktioniert. Im Extremfall
> dann vielleicht nicht mehr.

[Dennis H. (c-logic)]

Der dazugehörige Framebuffer-Treiber ist
https://github.com/notro/fbtft/blob/master/fb_ili9486.c

ob die default_init_sequence[] vorher geschrieben wird weiß ich jetzt 
nicht so genau.

0x20000ff dürfte Wartezeit sein (255 ms oder us eventuell)

[Mitlesa (Gast)]

Ich habe mir scon vor langer Zeit mal ein Testboard für den F407
gebaut an dem ich sowohl 16-Bit Parallel Displays als auch die
Raspberry Displays austesten konnte. Ziel war es natürlich die
Display Treiber nach eigenem Gustus zu erstellen da mir die
vorgefertigten Treiber (wenn ich sie überhaupt zu verstehen
wagte) zu langsam sind. Man sieht hier das Raspberry 4.0"
Display in Action:

Beitrag "Re: STM32 F746zg nucleo und ILI9488 TFT per SPI langsam ?"

Also wenn es um Aufbau geht weiss ich auch wovon ich rede,
ich lasse da funktional nichts anbrennen. Dies als weitere
Erklärung warum ich so auf dem Aufbau "herumreite".

[Daniel F. (lmdaniel999)]

Mitlesa schrieb:
> Zeig doch mal deinen Aufbau.

Was möchtest du denn genau sehen?
Einen Schaltplan?
Ein Layout?

Anbei ein Ausschnitt des Layouts, mit markierter CLK und MOSI Leitung.
Oben am Stecker folgen dann 10cm Flachbandkabel zum Display.

Ich hab die SPI Kommunikation mit einem Logik-Analyzer getestet.
Dort passt alles, auch trotz nicht perfekter Verlegung.
Auch am EVAL-Board geht das Display nicht.

Also entweder passt die Initialisierung wirklich nicht, oder das Display 
ist so massiv schlecht, dass es die Probleme gibt... Kann man das 
Display optimieren?

[Franz M. (elmo64)]

Daniel F. schrieb:
> Hab eines der nicht-funktionierenden Displays zerlegt, finde aber keinen
> Hersteller. Anbei sind die Bilder, vielleicht kommt es ja jmd. bekannt
> vor...

Auf der Unterseite war vermutlich ein Blech montiert. Steht dort etwas 
auf der Außenseite drauf? das könnte dich auch auf deiner Suche 
unterstützen. Durch das freilegen des Polarisators wird das Display 
vorraussichtlich nun defekt sein. (Anheben des Displaymoduls hätte 
gereicht)
Grundsätzlich ist das Finden des passenden Datenbattes für solche 
Displays oft eine langwirige und manchmal erfolgose Angelegenheit (OEM).

Hier gibt es Appnotes für gebräuchliche, in Hobbyanwendungen/ bei 
solchen China-Displays de facto Standard ILITEK-Controllern mit 
Initialisierungssequenzen:

ILI9486:
https://www.jameco.com/Jameco/Products/ProdDS/2278271.pdf
ILI9488:
http://www.lcdgo.com/upfiles/files/1574163595.pdf

Des Weiteren könntest du bei den Arduino-Jüngern, oder hier im Forum 
fündig werden. Alternativ natürlich Reverse engeneering des Treibers.

Wie verhät sich das Display nach dem Einschalten und nach der 
Initialisierung?

[Dennis H. (c-logic)]

Hattest du mal das SPI per Logicanalyser mitgeloggt vom Raspberry ?
Den CLK-Takt kannste dafür auch reduzieren.

[Daniel F. (lmdaniel999)]

A. M. schrieb:
> Auf der Unterseite war vermutlich ein Blech montiert. Steht dort etwas
> auf der Außenseite drauf? das könnte dich auch auf deiner Suche
> unterstützen. Durch das freilegen des Polarisators wird das Display
> vorraussichtlich nun defekt sein. (Anheben des Displaymoduls hätte
> gereicht)

Leider stand dort nichts.
Das Display war eh nicht mehr in Ordnung.
Mich hat der Aufbau interessiert...

A. M. schrieb:
> Wie verhät sich das Display nach dem Einschalten und nach der
> Initialisierung?

Es bleibt weiß und macht keinen Mucks...

Eine andere Frage:
Könnte der Touch Controller stören?
Ich habe die CS Leitung des Touch Controllers offen gelassen...

Noch eine Frage:
Theoretisch muss das Problem ja zwischen dem µC und den Schieberegistern 
liegen, oder?

[Daniel F. (lmdaniel999)]

Dennis H. schrieb:
> Hattest du mal das SPI per Logicanalyser mitgeloggt vom Raspberry ?
> Den CLK-Takt kannste dafür auch reduzieren.

Nein, das war auch schon eine Idee von mir.
Ich befürchte aber, dass ich nicht alles drauf bekomme, während dem 
Init.

Vermutlich muss ich es testen...
Leider finde ich auch keine "passende" ILI9488 Initialisierung...

[Franz M. (elmo64)]

Daniel F. schrieb:
> A. M. schrieb:
>> Wie verhät sich das Display nach dem Einschalten und nach der
>> Initialisierung?
>
> Es bleibt weiß und macht keinen Mucks...

Ganz klar, es ist nicht erfolgreich initialisiert und per Software 
eingeschaltet. Sobald Pixel-Daten erwartet werden, wird es "schwarz".

Wichtig ist das Timing bei der Initialisierung. Grundsätzlich ist beim 
Debugging weniger mehr. Die H7 schaffen recht hohe IO/SPI Frequenzen.


Du solltest dich auch mit den Eigenheiten der Ansteuerung (d)eines ILI 
controllers und dem "SPI to Parallel Wandler" auf deinem Dispayboad 
auseinandersetzen. Vielleicht empfängt das Display auf paralleler Seite 
aufgrund ungeeigneten Codes überhaupt keine validen Daten?


Ohne LA kommst du vermutlich nicht weiter. Hierbei ist nicht nur die SPI 
Kommunikation, sondern vor Allem der Output der Schieberegister, der 
Writepuls und der Pegel der Command/Data-Select line wichtig. Das Pannel 
interessieren nämlich nur die Pegel, die es selbst sieht.

[Daniel F. (lmdaniel999)]

Dennis H. schrieb:
> Hattest du mal das SPI per Logicanalyser mitgeloggt vom Raspberry ?
> Den CLK-Takt kannste dafür auch reduzieren.

Wie kann ich die CLK Speed auf dem Raspberry in der Lib reduzieren?

Ich habe ein Red Pitaya, wo ich die ersten Bytes des Inits sehe.
Leider kann das Red Pitaya nur 1M Samples aufnehmen, was nicht 
ausreicht.
Dann habe ich noch so ein Saleae Nachbau, der aber scheinbar zu langsam 
ist. Das Signal ergibt keinen Sinn...

A. M. schrieb:
> Ganz klar, es ist nicht erfolgreich initialisiert und per Software
> eingeschaltet. Sobald Pixel-Daten erwartet werden, wird es "schwarz".

Stimme ich zu!

A. M. schrieb:
> Wichtig ist das Timing bei der Initialisierung. Grundsätzlich ist beim
> Debugging weniger mehr. Die H7 schaffen recht hohe IO/SPI Frequenzen.

Wie meinst du das?
Der H7 ist schnell, aber die SPI Geschwindigkeit habe ich reduziert.
Hier habe ich maximal mit 16MBit/s übertragen, was auch funktioniert. 
Aktuell teste ich mit 4MBit/s.

A. M. schrieb:
> Du solltest dich auch mit den Eigenheiten der Ansteuerung (d)eines ILI
> controllers und dem "SPI to Parallel Wandler" auf deinem Dispayboad
> auseinandersetzen. Vielleicht empfängt das Display auf paralleler Seite
> aufgrund ungeeigneten Codes überhaupt keine validen Daten?

Grundsätzlich habe ich das getan. Die Schaltung war das Erste, was ich 
nachvollzogen habe. Fand ich sehr interessant und der SPI ist ja 
sozusagen ideal für diese Wandlungsart.
Leider weiß ich noch immer nicht sicher, welcher Controller verbaut ist.
Ich versuche aktuell einfach die Initialisierung des Raspberrys mit 
Hilfe des Logic Analyzers zu "kopieren".
Damit sollte es ja funktionieren!

A. M. schrieb:
> Ohne LA kommst du vermutlich nicht weiter. Hierbei ist nicht nur die SPI
> Kommunikation, sondern vor Allem der Output der Schieberegister, der
> Writepuls und der Pegel der Command/Data-Select line wichtig. Das Pannel
> interessieren nämlich nur die Pegel, die es selbst sieht.

Stimme ich zu!
Aber wenn die SPI Signale laut Logic Analyzer gleich sind, sollte der 
Ausgang der Schieberegister ja auch passen!

[Dennis H. (c-logic)]

in der /boot/config.ini
dtoverlay=waveshare35a,speed=8000000
oder noch langsamer
(standard ist 16000000)

[Bernd (Gast)]

Daniel F. schrieb:
> Könnte der Touch Controller stören?
> Ich habe die CS Leitung des Touch Controllers offen gelassen...
Im oben geposteten Schaltplan ist an /CS vom XPT ein Pullup dran.
Wenn der bei Dir auch auf dem Board ist, sollte der Touch-Controller 
nicht stören.

[Daniel F. (lmdaniel999)]

Hi,

die Analyse des RPi-SPI-Signals hat gezeigt, dass alle Befehle und Daten 
im 16-Bit Format übertragen werden. Also vor jedem 8-Bit-Befehl und 
jedem 8-Bit-Datenpaket wird einmal 0x00 übertragen.

Wenn ich die SPI-Sende-Routinen so anpasse, dann initialisiert das 
Display!

Irgendwie werden aber nun meine Bilder nicht richtig übertragen und der 
Text ist gespiegelt.
Da die Bilder mit einer separaten Sende-Routine übertragen werden, 
vermute ich nun einen Fehler bei den Initialisierungs-Parametern. Die 
hab ich ja 1zu1 vom RPi übernommen. Ich muss nun nochmal die 
Initialisierung überprüfen, ob alle Parameter passen!

Ich muss mich die Tage nochmal da ran setzen, da ich aktuell nicht den 
Kopf dafür frei habe... Aber ich denke, dass ich schonmal auf dem 
richtigen Weg bin.

Einerseits scheint die Übertragung in 16-Bit-Paketen logisch, da es zwei 
8-Bit-Schieberegister gibt. Andererseits finde ich das beim 
kontinuierlichen Beschreiben des Displayspeichers (z.B. beim Bild 
übertragen) komisch, immer ein 0x00 dazwischenzupacken....
Ich muss mich nochmal dahinterklemmen. Gibt noch Wissenslücken! :-)

Danke vorab, ich werde das Ergebnis berichten!

[Daniel F. (lmdaniel999)]

Hallo zusammen!

Ich bin noch ein Ergebnis schuldig! :-)

Nachdem ich den Waveshare Schaltplan untersucht und das Verhalten der 
Displays verglichen habe, kann ich Folgendes berichten:

Das Display mit dem ich die Probleme hatte, unterscheidet sich in zwei 
Punkten:

1. Es müssen immer zusammenhängende 16-Bit-Commands und Daten geschickt 
werden. Auch wenn im Command nur 8 Bit (D0-D7) genutzt werden, so 
reagiert das Display nicht, wenn ich nur die 8 Bit schicke. Ich vermute, 
dass die WR Leitung anders angeschlossen ist und nur vom Counter 
abhängt...

2. Die Orientierung des Displays ist anders. Das Display ist scheinbar 
gespiegelt. Das gleiche Programm erzeugt unterschiedliche Ausgaben auf 
beiden Displays. Ich bekomme die Anzeige nicht gleich hin, indem ich 
"nur" das Memory Access Control ändere. Scheinbar ist die Adressierung 
und die Pixel-Zuordnung anders.

Hier muss ich nochmal ran, aber das grundsätzliche Problem ist gelöst!
Danke für die Hilfe!