ili9341 2.8 Zoll Modul Problem

[Karl K. (leluno)]

hallo,

habe jetzt einige schöne Stunden mit der Fehlersuche bei meinem 
ili9341-spi-display verbracht:
https://www.ebay.de/itm/365658110658

bitbang geht - hw-spi nicht. Statt rot kommt blau. Orientierung stimmt 
auch nicht.

Habe jetzt ein anderes lcd eingesetzt und dadurch festgestellt, dass es 
nicht am code sondern am modul liegt.

Kennt jemand das Problem?
ist eventuell ein anderer 4-line-chip /cs-dc-mosi-ck verbaut für den es 
angepassten code gibt?

[Harald K. (kirnbichler)]

Karl K. schrieb:
> bitbang geht - hw-spi nicht.

Dann häng' einen Logikanalysator dran und vergleiche. Wenn Du SPI via 
Bitbang machst, sollte exakt dasselbe passieren wie bei hw-spi.

Tut es das nicht, ist was faul. Und darauf wird das Display reagieren.

[Cartman E. (cartmaneric)]

Möglicherweise ist auf einem der Module gar kein ILI9341 verbaut.
Lies also erstmal die Identifikation aus.

[Ralph S. (jjflash)]

Harald K. schrieb:
> Dann häng' einen Logikanalysator dran und vergleiche. Wenn Du SPI via
> Bitbang machst, sollte exakt dasselbe passieren wie bei hw-spi.
>
> Tut es das nicht, ist was faul. Und darauf wird das Display reagieren.

... und ich habe schon "üble" Displays gehabt, die nicht schnell genug 
nach einem abgeschlossenen SPI-Transfer wieder bereit waren und ich 
mußte hier 2 "NOP" danach einfügen (leider). Hatte ich mit ILI9341 und 
ILI9225.

[Rüdiger B. (rbruns)]

Darauft achten welchen SPI du benutzt, der ESP hat 4, davon sind nur 2 
Frei.

[Joachim B. (jar)]

Karl K. schrieb:
> Statt rot kommt blau. Orientierung stimmt
> auch nicht.

ich kenne das bei TFT als RGB GRB order

da hilft IMHO nur Fehler suchen, notfalls im Code und/oder LIB


für die Orientirung richtig initialisieren oder Code debuggen.

[Holger T. (holgert)]

Ich würde zuerst prüfen, ob bei HW-SPI der Takt (SCK) nicht zu hoch 
eingestellt ist.
(Wenn ich mich richtig erinnere, kann der ili9341 lt. Datenblatt max. 
10MHz)

[Richie (mikro123)]

Karl K. schrieb:
> hallo,
>
> habe jetzt einige schöne Stunden mit der Fehlersuche bei meinem
> ili9341-spi-display verbracht:
> https://www.ebay.de/itm/365658110658
>
> bitbang geht - hw-spi nicht. Statt rot kommt blau. Orientierung stimmt
> auch nicht.


Hast Du das Datenblatt nicht gelesen?

8.2.6. Read Display MADCTL (0Bh)

[Karl K. (leluno)]

Richie schrieb:
> Hast Du das Datenblatt nicht gelesen?
>
> 8.2.6. Read Display MADCTL (0Bh)

Was meinst du mit der Frage?

Ich schaue in das Datenblett, wenn ich spezielle Informationen benötige 
- z.B. Spi-Mode.

Der code geht ja mit anderen ili-Displays, ist also in Ordnung.

Ich brauche das display nur für die Anzeige von Daten. Das geht auch per 
bitbang und die Hintergrundfarbe ist ziemlich egal.

Ich werde also den code mit einem anderen lcd-modul - wegen des 
schnellen hw-spi - weiterentwickeln und - wenn alles fertig ist - auf 
das bitbang-modul umstellen.

[Richie (mikro123)]

Karl K. schrieb:
> Richie schrieb:
>> Hast Du das Datenblatt nicht gelesen?
>>
>> 8.2.6. Read Display MADCTL (0Bh)
>
> Was meinst du mit der Frage?

Ich meine damit, dass Du einfach mal das Datenblatt liest...

> Ich schaue in das Datenblett, wenn ich spezielle Informationen benötige
> - z.B. Spi-Mode.

Und ich auch, wenn etwas nicht funktioniert.

> Der code geht ja mit anderen ili-Displays, ist also in Ordnung.

Offensichtlich ja nicht.

Schau Dir einfach mal an, was ich gepostet habe.
Im Register 0Bh (RDDMADCTL) gibt es nämlich Bits, die das Verhalten des 
Displays je nach Verschaltung einstellen.
Zum einen ist das die Orientierung, die ja bei Dir nicht wie gewünscht 
ist sowie die Farbe.
Für letzteres also das Bit D3:
  0 RGB (When MADCTL B3=’0’)
  1 BGR (When MADCTL B3=’1’)
Für Ersteres die Bits D6 sowie D7.


Und zum Schluß nochmal die Grundregel schlechthin:
RTFM!

[Ob S. (Firma: 1984now) (observer)]

Holger T. schrieb:

> Ich würde zuerst prüfen, ob bei HW-SPI der Takt (SCK) nicht zu hoch
> eingestellt ist.
> (Wenn ich mich richtig erinnere, kann der ili9341 lt. Datenblatt max.
> 10MHz)

Ja, so steht das tatsächlich im DB.

Aber: ILI9341, die weitaus mehr abkönnen, scheinen doch sehr 
verbreitet zu sein. So verbreitet, dass diverse Hersteller solcher 
Displays in den jeweils gelieferten Libs eben diese teils deutlich 
höheren Taktraten standardmäßig benutzen. Das würden sie nicht tun, wenn 
das zu einer hohen Rücklaufer-Quote führen würde...

Beim Schreiben sind z.B. 80MHz als Standard recht verbreitet 
anzutreffen, wenn die Quelle ein (richtiger) Raspi ist.

Ich selber benutze solche TFTs allerdings meistens an einem Pi Pico, 
aber auch da ist mir noch kein Display untergekommen, was die 80Mhz 
schreibend nicht abkann. Zum Lesen allerdings muss man deutlich 
runtertakten, sonst kommt nur Gurkensalat raus. 40Mhz ist auch immer 
noch etwas kitzlig (gelegentliche Einzelbitfehler im MSB), deswegen 
benutze ich zum Lesen nur 20MHz. Das läuft stabil.

[Karl K. (leluno)]

Richie schrieb:
> Im Register 0Bh (RDDMADCTL) gibt es nämlich Bits, die das Verhalten des
> Displays je nach Verschaltung einstellen.

die werden in der ini alle abgearbeitet und richtig eingestellt. Da gehe 
ich wegen einem abweichend arbeitenden ili - das mglw. irgendwas anderes 
ist- nicht ran. Das kostet Zeit und bringt eh nichts. Die ini ist genau 
wie im Datenblatt beschrieben. Sonst würden die anderen ilis nicht 
funktionieren.

[Harald K. (kirnbichler)]

Karl K. schrieb:
> Das kostet Zeit und bringt eh nichts.

Sinnvoller wäre es, herauszufinden, wo die Unterschiede zwischen Deinem 
Bitbanging und Deiner SPI-Programmierung liegen.

Alles andere ist ein Nebenkriegsschauplatz, der vom Problem nur ablenkt.

[Karl K. (leluno)]

Harald K. schrieb:
> Bitbanging und Deiner SPI-Programmierung

void ll_spi_write (const uint8_t *buff, uint16_t size
 //  const u8* buff,  /* Data to be sent */
 //  u16 size    /* Number of bytes to send */
 )
 {
  uint8_t d;
  do {  
   
  #if ili_bitbang

    d = *buff++;
    if (d & 0x80)ll_mosi_high; else ll_mosi_low;  // bit7
     ll_ck_cycle;
    if (d & 0x40)ll_mosi_high; else ll_mosi_low;  // bit6
     ll_ck_cycle;
    if (d & 0x20)ll_mosi_high; else ll_mosi_low;  // bit5
     ll_ck_cycle;
    if (d & 0x10)ll_mosi_high; else ll_mosi_low;  // bit4
     ll_ck_cycle;
    if (d & 0x08)ll_mosi_high; else ll_mosi_low;  // bit3
     ll_ck_cycle;
    if (d & 0x04)ll_mosi_high; else ll_mosi_low;  // bit2
     ll_ck_cycle;
    if (d & 0x02)ll_mosi_high; else ll_mosi_low;  // bit1
     ll_ck_cycle;
    if (d & 0x01)ll_mosi_high; else ll_mosi_low;  // bit0
     ll_ck_cycle;

#else

    SPDR=*buff++;
    while(!(SPSR & (1<<SPIF)));
    //_delay_us(10);
#endif  

   } while (--size);
 }

//#endif

....
//ili-datasheet: pol=0 pha=0 idle=low pha=leading
SPCR=(1<<SPE)|(1<<MSTR);
SPCR&=~(1<<CPOL);// When this bit is written to zero, SCK is low when idle. 
//SPCR|=(1<<CPOL);// When this bit is written to one, SCK is high when idle. 
SPCR&=~(1<<CPHA);//data is sampled on the leading (first 0) or trailing (last 1) edge
//SPCR|=(1<<CPHA);//data is sampled on the leading (first 0) or trailing (last 1) edge
SPSR = (1 << SPI2X);  // maximale Geschwindigkeit: F_CPU / 2 
_delay_ms(50);

'll_ck_cycle;' vereint pha=0 und pha=1 - ansonsten ist es absolut 
gleich. Und nun?

[Ralph S. (jjflash)]

Dein Makro ll_ck_cycle sollte man hier auch noch sehen (um 
festzustellen, wie die Clockleitung hinterlassen wird)

[Andrea B. (stromteam)]

Ist die Versorgungsspannug richtig eingestellt?
J1 offen für 5V, geschlossen für 3,3V

[Karl K. (leluno)]

Ralph S. schrieb:
> Dein Makro ll_ck_cycle sollte man hier auch noch sehen (um
> festzustellen, wie die Clockleitung hinterlassen wird)

#define ll_ck_high      pinset(ll_ck_port,ll_ck_pin)
#define ll_ck_low       pinclr(ll_ck_port,ll_ck_pin)
#define ll_ck_cycle     ll_ck_low;ll_ck_high;

Andrea B. schrieb:
> Ist die Versorgungsspannug richtig eingestellt?
> J1 offen für 5V, geschlossen für 3,3V

perfekte Darstellung auf dem lcd - nur in blau/rotation/bitbang

[Dieter S. (ds1)]

Karl K. schrieb:
>
> perfekte Darstellung auf dem lcd - nur in blau/rotation/bitbang

Zeig den Code der Display Initialisierung.

Wenn es so wie oben beschrieben nicht klappt könnte eventuell die 
Einstellung genau dieser Parameter im einen Fall schiefgehen, die 
Parameter stehen in dem bereits oben erwähnten MADCTL. Eine mögliche 
Ursache dafür wäre dass das unmittelbar davor verschickte Kommando im 
Controller noch nicht fertig ist und daher das Schreiben von MADCTL ins 
Leere läuft.

[Harald K. (kirnbichler)]

Karl K. schrieb:
> Und nun?

In meiner ersten Anwort in diesem Thread habe ich Dir geraten, das ganze 
mit einem Logikanalysator anzusehen.

Denn ganz offensichtlich IST da ein Unterschied.


Deine Macros enthalten keinerlei Zeitbezug, d.h. die rauschen so schnell 
durch, wie es der Controller halt hinbekommt. Das wiederum dürfte einen 
sehr stark vom Takt der Hardware-SPI-Schnittstelle abweichenden Takt zur 
Folge haben.