eDIP TFT 32 - jemand schon damit gearbeitet ?

[Klaus (Gast)]

Hallo
Habe ein Display von EA vom Typ eDIP TFT 32 bekommen. Es kann mit SIP 
oder I2C angesteuert werden. Leider sind Beispiele bzw. Anwendungen 
wenig im Netz zu finden. Im Datenblatt des Herstellers sind einige 
Beispiel drin. Die Farbe kannn ich schon einstellen. Leider geht die 
Graphikfunktion nicht bzw. zeigt nichts an.
Einen Code kann ich leider erst heute abend reinstellen.
Könnte mir jemand helfen?
Kl

[Josef (Gast)]

Ich würde mich an EA direkt wenden. Die kennen sich gut aus. Haben mir 
schon ein paar Male geholfen. Wie steuerst du dein Display an (I2C, SPI, 
Uart)?
Am besten du startest über die UART mit 115200 Baud. Dann schau, ob der 
MC auf SBUF reagiert. Dann kann's weiter gehen....

[Steffen W. (derwarze)]

Bei EA auf der Webseite sind Datenblätter und ein Editorprogramm zu 
finden mit dem das Teil recht leicht zu programmieren ist.
Gibt es zum Teil auch auf deutsch.
Es gibt ein Demoboard dafür mit dem der Editor gut zusammenarbeitet, 
braucht man aber nicht unbedingt, über UART mit zusätzlichen USB Wandler 
geht auch. Der Schaltplan fürs Demoboard gibt es auch, der gibt 
nützliche Hinweise für die Beschaltung.

[Klaus (Gast)]

Hallo
mit EA habe ich auch schon mails gewechselt.
Hatte vergessen zu sagen, das ich in C arbeite.
Habe EA auch den Code geschickt mit konkreter Frage. Sollte alles gehen. 
Leider machte es das nicht.
Habe es mit dem I2C Bus angesteuert. Kann alle möglichen Farben 
einstellen, Infos aufrufen usw. Leider bekomme ich das im Datenblatt 
genannte Stück Code mit löschen und zeichnen einer Gerade nicht zum 
laufen. Die Rückgabe des ACK ist 6 und damit korrekt. Leider klappt es 
nicht wie angegeben.
Hatte ja gehofft, das jemand schon was damit gemacht hat.
Kl

[Flo85 (Gast)]

Hi,

ich habe dieses Display, steuere es mit einem Mega128 über SPI. Klappt 
eigentlich problemlos. Mit dem in Datenblatt auf Seite 10 angegebenen 
Flussdiagramm und dem C Beispiel hat es bei mir auf Anhieb funktioniert. 
Wenngleich das Display nicht das erste war was ich über SPI gesteuert 
habe, somit hatte ich Routinen die 1000%ig funktionieren.

Das ACK = 0x06 darf man auch nicht überbewerten, denn es heisst ja nur 
dass das Paket korrekt empfangen wurde. Korrekt empmfangen wird ein 
Paket aber auch mit einer falschen Syntax, nur passiert dann halt 
nichts.

Was heisst du kannst die Farben einstellen? Wenn du den Strich nicht 
gezeichnet bekommst, woher weist du dass die Farbe umgestellt wurde?


Je nachdem was du mit dem LCD vor hast würde ich dir noch das Eval-Board 
empfehlen, oder zumindest einen PC Anschluss über USB/Uart, denn dann 
kann man mit der (kostenlosen) Software von EA den 4MB Speicher des LCDs 
mit Macros, Bildern, eigenen Touchtasten, fertigen Menüs etc. füllen, 
das erspart dem µC viel Arbeit.

Wichtig wäre jetz erstmal dein Code.

[Klaus (Gast)]

Farbe einstellen - Farbe wird auf dem Display angezeigt. Text wird nicht 
dargestellt. Habe noch ein Display vom Typ eDIP 128 mit dem klappt es 
ohne Probleme. Habe es auch wie auf der Seite gemacht, in etwa der 
gleich Ablauf, keinerlei Probleme. Gehe voll nach dem Datenblatt, mache 
die Einstellungen genau so, auch mit den 8 oder 16 Bit. Mache alles über 
I2C.
Kl - ziemlich Ratlos

[Flo85 (Gast)]

Warten wir mal auf deinen Code, denn das Farbe ändern geht und Text 
nicht ist schon etwas seltsam. Denn wenn ein Befehl geht dann sollten es 
alle anderen auch sofern die Syntax stimmt. Aufpassen muss man natürlich 
was man dem LCD für Parameter gibt. Weißen Text auf weißem Hintergrund 
wird man niemals sehen.Grundsätzlich sollte ein Text nach einem Reset 
weiß sein, sofern kein Power On Macro etwas daran ändert.

[josef (Gast)]

"DATENÜBERTRAGUNGSPROTOKOLL (SMALL PROTOKOLL)
Das Protokoll ist für alle 3 Schnittstellenarten RS-232, SPI und I²C 
identisch aufgebaut. Die Datenübertragung
ist jeweils eingebettet in einen festen Rahmen mit Prüfsumme „bcc“. Das 
EA eDIPTFT43-A quittiert dieses
Paket mit dem Zeichen <ACK> (=$06) bei erfolgreichem Empfang oder <NAK> 
(=$15) bei fehlerhafter
Prüfsumme oder Empfangspufferüberlauf. In jedem Fall wird bei <NAK> das 
komplette Paket verworfen und
muss nochmal gesendet werden.
Ein <ACK> bestätigt lediglich die korrekte Übertragung. Ein Syntax-Check 
erfolgt nicht.
Hinweis: <ACK> muß eingelesen werden"


Passt die Prüfsumme?

[Choose (Gast)]

Geradenfarbe einstellen:

ESC F G vf hf

Gerade zeichnen:

ESC D xx1 yy1 xx2 yy2 Eine Gerade von xx1,yy1 bis xx2,yy2 zeichnen



Jetzt wäre wirklich dein Code interessant statt Glaskugel schauen...

[Paulchen (Gast)]

So, jetzt bin ich meinem Rechner und der Code kommt
z.B. für eine Gerade:

void Graphik_C_Gerade(int16_t x1, int16_t y1, int16_t x2, int16_t y2)
  {
    int16_t bcc;
    bcc = DC1 + 0x07 + ESC + 'G' + 'D' + x1 + y1 + x2 + y2;
    i2c_start(slave_adresse_1);
    i2c_write(DC1);    // 0x11
    i2c_write(0x07);  // len 07
    i2c_write(ESC);    // 0x1b
    i2c_write('G');    // G
    i2c_write('D');    // D
    i2c_write(x1);
    i2c_write(y1);
    i2c_write(x2);
    i2c_write(y2);
    i2c_write(bcc);
    i2c_stop();
    
    _delay_us(20);
    i2c_start(slave_adresse_2);
    e = i2c_readAck();
    i2c_stop();
  }

Der Aufruf erfolgt mit

Graphik_C_Gerade(10,10,319,239);

Da mein Display auch in Reichweite ist, kann ich es sofort testen
Kl

[Flo85 (Gast)]

Die Koordinaten sind 16 bit Werte! Damit stimmt die Datenpaketlänge 
nicht.  Die ist nämlich 11 wenn man eine Gerade zeichnet. Denn die 
Koordinaten müssen immer als 2 Datenpakete übertragen werden.

[Flo85 (Gast)]

Die Prüfsumme muss auch nicht als 16Bit Variable definiert werden, sie 
hat sowiso immer nur 8 Bit.

[Flo85 (Gast)]

Sorry für den Dreifachpost.

Das erklärt auch warum du keinen Text siehst, weil du wahrscheinlich 
auch da die Koordinaten und somit die Paketlänge falsch hast.

[Klaus (Gast)]

Nach Datenblatt erfolgt das zeichnen einer Gerade mit

G  D  xx1  yy1  xx2  yy2   (xx und yy sind 16 Bit)

Im Beispiel des Herstellers steht: (Seite 10)

ESC  G  D    0      0     319    239
1B   47 44 00 00  00 00  3F 01  EF 00

Wie erfolgt dabei die übertragung?
Die Zahl 319 entspricht 013F. Damit sind bei der Angabe beide Werte 
vertauscht. Muss ich jetzt 8 Werte übertragen und dabei alles 
vertauschen?
Ki

[Flo85 (Gast)]

So wie es im Datenblatt steht. Bei den 16Bit Werten immer zuerst die 
Bits 0 bis 7 und im nächsten Paket die Bits 8 bis 15.

Also einfach so:

x11 = x1
x12 = x1 >> 8
y11 = y1
y12 = y1 >> 8
x21 = x2
x22 = x2 >> 8
y21 = y2
y22 = y2 >> 8

Also für jede Koordinate die angegeben wird braucht man 4 Datenpakete. 
Bei der Geraden sind es dann 8 da man 2 Koordinaten angibt, Start und 
Ziel.

[Klaus (Gast)]

Bin am eingeben und testen

[Klaus (Gast)]

Habe es so eingegeben. Korrekt?

void Graphik_C_Rechteck_zeichnen(int16_t a11, int16_t a12, int16_t b11, int16_t b12, int16_t a21, int16_t a22, int16_t b21, int16_t b22)
    {
    int16_t bcc;
    bcc = DC1 + 0x0b + ESC + 'G' + 'R' + a11 + a12 + b11 + b12 + a21 + a22 + b21 + b22;
    i2c_start(slave_adresse_1);
    i2c_write(0x11);    // DC1
    i2c_write(0x0b);    // len 07
    i2c_write(0x1B);    // ESC
    i2c_write('G');    // G
    i2c_write('R');    // R
    
    
    i2c_write(a11);
    i2c_write(a12);
    i2c_write(b11);
    i2c_write(b12);
    
    i2c_write(a21);
    i2c_write(a22);
    i2c_write(b21);
    i2c_write(b22);
    
    
    i2c_write(bcc);
    i2c_stop();
     
    _delay_us(50);  
    i2c_start(slave_adresse_2);
    e = i2c_readAck();
    i2c_stop();
    _delay_us(30);
    
    }

Aufruf erfolgt mit:

Graphik_C_Rechteck_zeichnen(0,0,0,0,19,03,39,02);

[Flo85 (Gast)]

Umständlich. Aber Fehler hab ich jetzt keinen gefunden, funktioniert es?

[Klaus (Gast)]

Etwas geht, bin aber noch unsicher. Max. Roter Rahmen mit Pixel 1. Die 
Bereiche der Zahlen sind komisch geordnet bzw. muss mich erst an die 
verdrehte Eingabe gewöhnen. das andere ist, die Angabe der Zahlen, 
scheinbar in 0x3f, dann stimmen die Bereiche aber nicht. Gibt genug zum 
testen, Wichtig dabei ist, die Anzeige kommt
Danke für deine Hilfe, werde berichten was alles geht
Ki

[Flo85 (Gast)]

Ich würde den Funktionsaufruf so machen:

void zeichne_rechteck(uint16_t x1, uint16_t y1, uint16_t x2, uint16_t 
y2)
{
        .
        .
        .
        i2c_write(x1);
        i2c_write(x1 >> 8);
        i2c_write(y1);
        i2c_write(y1 >> 8);

        i2c_write(x2);
        i2c_write(x2 >> 8);
        i2c_write(y2);
        i2c_write(y2 >> 8);
        .
        .
        .
}

Damit ersparst du dir die umständliche eingabe und herumrechnerei.

[Klaus (Gast)]

Gute Idee um nicht zu rechnen. Nach Angabe des Herstllers liegen die max 
Grösse bei x=319 und y=239. Mal testen was für eine Eingabe notwendig 
ist.

[Choose (Gast)]

void Bef2_2Pos_TFT(char Bef1,char Bef2,int Pos1,int Pos2)     //Befehl 
mit Kord

{
       Tel_Pnt = 0;

       Tel_Buf_TFT[Tel_Pnt++] = Bef1;
       Tel_Buf_TFT[Tel_Pnt++] = Bef2;

       Tel_Buf_TFT[Tel_Pnt++] = Pos1;            //Koordinaten schreiben
       Tel_Buf_TFT[Tel_Pnt++] = Pos1 >> 8 ;
       Tel_Buf_TFT[Tel_Pnt++] = Pos2;
       Tel_Buf_TFT[Tel_Pnt++] = Pos2 >> 8 ;

       Send_Tel_TFT(Tel_Buf_TFT);
}


kannst für sämtliche Koordinaten Befehle verwenden.....

[Klaus (Gast)]

Hallo Flo

Flo85 schrieb:
> void zeichne_rechteck(uint16_t x1, uint16_t y1, uint16_t x2, uint16_t
> y2)
> {
>         .
>         .
>         .
>         i2c_write(x1);
>         i2c_write(x1 >> 8);
>         i2c_write(y1);
>         i2c_write(y1 >> 8);
>
>         i2c_write(x2);
>         i2c_write(x2 >> 8);
>         i2c_write(y2);
>         i2c_write(y2 >> 8);
>         .
>         .
>         .
> }

Es klappt soweit alles. Die Einstellung bzw. Angabe der Grösse ist 
wirklich gewöhnungsbedürftig.

Klaus schrieb:
> ESC  G  D    0      0     319    239
> 1B   47 44 00 00  00 00  3F 01  EF 00

Wenn ich die Angaben des Herstellers nehme, dann ist bei dem Wert von 
319 die volle Breite des Displays gemeint. 319 ist unterteilt in 3F und 
01. Dabei ist

3F - die zweite Zahl - mögliche Angabe von 0 bis 255
01 - die erste Zahl - Angabe 01 - max 01 sonst ausserhalb des Displays

Kann die Zahlen in Hex oder Dez eingeben. Klappt das dann auch mit 
deiner Berechnung? oder lieber eine Begrenzung einbauen?
Bei der Eingabe von 8 Werten und verdreht kommt man relativ schnell.
Ki durcheinander

[Flo85 (Gast)]

Ob du die Zahlen in hex oder Dezimal ein gibst sollte egal sein.

Ja 319 ist das letzte Pixel da das LCD 320x240 Pixel hat und bei 0 zu 
zählen begonnen wird. Also 0,0 (links oben) bis 319,239 (rechts unten).

Eine Begrenzung ist nicht zwingend notwendig, denn Werte die über den 
Displayrand gehen werden sowiso nicht verarbeitet.

[Klaus (Gast)]

Habe den Funktionsaufruf so eingegeben:

Flo85 schrieb:
> void zeichne_rechteck(uint16_t x1, uint16_t y1, uint16_t x2, uint16_t
> y2)
> {
>         .
>         .
>         .
>         i2c_write(x1);
>         i2c_write(x1 >> 8);
>         i2c_write(y1);
>         i2c_write(y1 >> 8);
>
>         i2c_write(x2);
>         i2c_write(x2 >> 8);
>         i2c_write(y2);
>         i2c_write(y2 >> 8);
>         .
>         .
>         .
> }

Bei der Berechnung stimmt was nicht. Gebe ich für x1 Werte von 0 - 255 
ein, wird das Rechteck (Gerade) korrekt gezeichnet. Wird ein Wert über 
256 eingestellt, erfolgt keine Darstellung.
Ist das von Choose in C? Komme leider nicht klar mit deiner Rechnung.
Ki

[Choose (Gast)]

Wenn dein X2 oder Y2 Wert keinen Sinn ergibt, dann kann das passieren.

Deswegen habe ich ein Macro, welches den Startpunkt des Rechteckes
und als X2, Y2 nur die Länge und Breite des Rechteckes angibt:


LINE_RECT(x,y,Br,Ho) Bef2_4Pos_TFT ('G','R',x,y,x+Br,y+Ho); 
//Linienrechteck

habs grad getestet, und funzt.

[Flo85 (Gast)]

Klaus schrieb:
> Bei der Berechnung stimmt was nicht. Gebe ich für x1 Werte von 0 - 255
> ein, wird das Rechteck (Gerade) korrekt gezeichnet. Wird ein Wert über
> 256 eingestellt, erfolgt keine Darstellung.

Sind deine Übergabevariablen an die Funktion "unsigned"?

[Klaus (Gast)]

Hallo Flo
Hatte es so geschrieben:

Klaus schrieb:
> ESC  G  D    0      0     319    239
> 1B   47 44 00 00  00 00  3F 01  EF 00

Display Breite max von 0-319 sind 320. Die Zahl 319 setzt sich aus 3F 
und 01 zusammen. Die Zahl 3F sieht eigentlich so aus 0x3F und geht von 
0x00 bis 0xFF, in dez. 0-255. Setze ich die Zahl 01 so wird sofort 255 
dazu addiert.
Ist der Wert unter 256 kann die x direkt ausgegeben werden.
Ist die Zahl grösser 255 muss ich doch die Zahl erst berechnen. z.B so:

Eingabe:   270
Rechnung:  270-255
Ausgabe:   15 (dez) und 01

Habe ich da einen Denkfehler?

Ki

[Klaus (Gast)]

Hallo Choose
Habe deinen Code versucht zu verstehen. Klappt nicht so gut.
Du gibst als erstes char Bef1 an. Bei 8 Bit ghet es bis 255, brauche 
aber 319. Versteh deine Rechnung nicht

Choose schrieb:
> void Bef2_2Pos_TFT(char Bef1,char Bef2,int Pos1,int Pos2)     //Befehl
> mit Kord
>
> {
>        Tel_Pnt = 0;
>
>        Tel_Buf_TFT[Tel_Pnt++] = Bef1;
>        Tel_Buf_TFT[Tel_Pnt++] = Bef2;
>
>        Tel_Buf_TFT[Tel_Pnt++] = Pos1;            //Koordinaten schreiben
>        Tel_Buf_TFT[Tel_Pnt++] = Pos1 >> 8 ;
>        Tel_Buf_TFT[Tel_Pnt++] = Pos2;
>        Tel_Buf_TFT[Tel_Pnt++] = Pos2 >> 8 ;
>
>        Send_Tel_TFT(Tel_Buf_TFT);
> }

Ki

[Klaus (Gast)]

So weit funktioniert es. Kann durch die Eingabe der 4 Werte einen Strich 
darstellen. Es bleibt aber noch eine Sache die nicht funktioniert. Das 
sind Werte über 255. Das ergibt eine Fehlermeldung bzw. es kommt kein 
strich.

 bcc = DC1 + 0x0b + ESC + 'G' + 'D' + x11 + y11 + z21 + y21;
     
    i2c_start(slave_adresse_1);
    i2c_write(DC1);    // DC1
    i2c_write(0x0b);    // len 0b
    i2c_write(ESC);    // ESC
    i2c_write('G');    // G
    i2c_write('D');    // D
      
    i2c_write(x11);
    i2c_write(x11 >> 8);
     
    i2c_write(y11);
    i2c_write(y11 >> 8);

    i2c_write(z21);
    i2c_write(z21 >> 8);
   
    i2c_write(y21);
    i2c_write(y21 >> 8);

Der Aufruf erfolgt damit:

void Graphik_C_Gerade(int16_t x11, int16_t y11, int16_t z21, int16_t y21);

hat jemand eine Idee dazu?
Ki

[Erwin D. (Gast)]

Klaus schrieb:
> void Graphik_C_Gerade(int16_t x11, int16_t y11, int16_t z21, int16_t
> y21);

Schon mal mit uint16_t für die 4 Werte probiert?

[Klaus (Gast)]

Habe es jetz mit uint16 getestet. Bis zu 255 keine Fehlermeldung, ab 256 
Fehlermeldung und bcc stimmt nicht mehr.
Hat jemand eine Idee dazu?
Ki

[Flo85 (Gast)]

Die bcc kann auch nicht stimmen, du musst auch die mit den Werten 
berechnen die du an i2c_write übergibst, also ... + x11 + (x11 >> 8) + 
usw.