ili9341 2.8 Zoll Modul Problem

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.

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

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.

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

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.

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)

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)

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.

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!

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.

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.

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.

Harald K. schrieb:

Bitbanging und Deiner SPI-Programmierung

1

void ll_spi_write (const uint8_t *buff, uint16_t size

2

 //  const u8* buff,  /* Data to be sent */

3

 //  u16 size    /* Number of bytes to send */

4

 )

5

 {

6

  uint8_t d;

7

  do {  

8

9

  #if ili_bitbang

10

11

    d = *buff++;

12

    if (d & 0x80)ll_mosi_high; else ll_mosi_low;  // bit7

13

     ll_ck_cycle;

14

    if (d & 0x40)ll_mosi_high; else ll_mosi_low;  // bit6

15

     ll_ck_cycle;

16

    if (d & 0x20)ll_mosi_high; else ll_mosi_low;  // bit5

17

     ll_ck_cycle;

18

    if (d & 0x10)ll_mosi_high; else ll_mosi_low;  // bit4

19

     ll_ck_cycle;

20

    if (d & 0x08)ll_mosi_high; else ll_mosi_low;  // bit3

21

     ll_ck_cycle;

22

    if (d & 0x04)ll_mosi_high; else ll_mosi_low;  // bit2

23

     ll_ck_cycle;

24

    if (d & 0x02)ll_mosi_high; else ll_mosi_low;  // bit1

25

     ll_ck_cycle;

26

    if (d & 0x01)ll_mosi_high; else ll_mosi_low;  // bit0

27

     ll_ck_cycle;

28

29

#else

30

31

    SPDR=*buff++;

32

    while(!(SPSR & (1<<SPIF)));

33

    //_delay_us(10);

34

#endif  

35

36

   } while (--size);

37

 }

38

39

//#endif

40

41

....

42

//ili-datasheet: pol=0 pha=0 idle=low pha=leading

43

SPCR=(1<<SPE)|(1<<MSTR);

44

SPCR&=~(1<<CPOL);// When this bit is written to zero, SCK is low when idle. 

45

//SPCR|=(1<<CPOL);// When this bit is written to one, SCK is high when idle. 

46

SPCR&=~(1<<CPHA);//data is sampled on the leading (first 0) or trailing (last 1) edge

47

//SPCR|=(1<<CPHA);//data is sampled on the leading (first 0) or trailing (last 1) edge

48

SPSR = (1 << SPI2X);  // maximale Geschwindigkeit: F_CPU / 2 

49

_delay_ms(50);

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

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

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

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

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.

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.