EDIPTFT32 gibt falschen ACK zurück.

[Maik G. (maik_l)]

Moin zusammen.

Ich versuche seit Wochen ein ACK zu erreichen, weiß gerade nur nicht, ob 
ich da einem Denkfehler auf dem leim gegangen bin wie bei der Auswahl 
des Übertragungsmodus...
Dies habe ich nunmehr erfolgreich zum laufen bekommen...
Daten welche auf dem Display erscheinen sollen, werden auch sauber 
dargestellt.

Nur sowie ich einen das ACK haben will, bekomme ich alles nur kein ACK 
bzw NAK.

der Code schaut wie folgt aus...

#include <iostream>
#include <sstream>
#include <string>
#include <stdlib.h>
#include </home/satan/Programming/APIs/gnublin.h>
#include </home/satan/Programming/APIs/TestColor.h>


using namespace std;

/* const for eDIP-Display ; Kontroll */
unsigned int    Read    = 0x6F;
unsigned char   bcc     = 0x00;
char            DC1     = 0x11;
char            DC2     = 0x12;
char            _1      = 0x01;
char            _2      = 0x02;
char            _3      = 0x03;
char            D       = 0x44;
char            I       = 0x49;
char            S       = 0x53;

/* var for eDIP-Display ; Data */

unsigned char   sbbr, rbbf;     /* [S]end [B]uffer [B]yte [R]eady
                                   [R]eceive [B]uffer [B]yte [F]ree */
uint8_t         ACK;            /* Read ACK from eDIP-Display */
unsigned char   _DC2, __2;


#define rt_Bar "#fb,3,8,1,"
#define gn_Bar "#fb,4,8,1,"
#define bl_Bar "#fb,2,8,1,"

gnublin_i2c I2C;

void ReadSender(){
    bcc = 0;
    cout << "Sende " << DC2 << " Status: " << I2C.send(DC2) << "\n";
    cout << "Sende " << _1 << " Status: " << I2C.send(_1) << "\n";
    cout << "Sende " << S << " Status: " << I2C.send(S) << "\n";
    bcc = DC2 + _1 + S;
    cout << "Sende " << bcc << " Status: " << I2C.send(bcc) << "\n";
    I2C.receive(&ACK, 1);
    cout << "Lese " << ACK << "\n";
    printf ("Versuche ACK zu lesen: %x\n", ACK);

}

void ReadBuffer(){
    bcc = 0;
    cout << "Sende " << DC2 << " Status: " << I2C.send(DC2) << "\n";
    cout << "Sende " << _1 << " Status: " << I2C.send(_1) << "\n";
    cout << "Sende " << I << " Status: " << I2C.send(I) << "\n";
    bcc = DC2 + _1 + I;
    I2C.receive(&ACK, 1);
    cout << "Lese " << ACK << "\n";
    cout << "\tLese Buffer:";
    if (I2C.receive((unsigned char*)_DC2, 1) != 1){
        cout << I2C.getErrorMessage() << "\n";
    }
    if (I2C.receive((unsigned char*)__2, 1) != 1){
        cout << I2C.getErrorMessage() << "\n";
    }
    if (I2C.receive((unsigned char*)sbbr, 1) != 1){
        cout << I2C.getErrorMessage() << "\n";
    }
    if (I2C.receive((unsigned char*)rbbf, 1) != 1){
        cout << I2C.getErrorMessage() << "\n";
    }
    cout << "\tDaten zu 100% geladen...\nDC in: " << _DC2 << "\n2 in: " << __2;
    cout << "\nsbbr in: " << sbbr << "\nfbbr in:" << rbbf << "\n";
}

void SendData(string Data){

    unsigned char lang= Data.length();

    stringstream sData;
    bcc = 0;
    sData << Data;

    cout << "Sende " << DC1 << " Status: " << I2C.send(DC1) << "\n";
    cout << "Sende " << lang << " Status: " << I2C.send(lang) << "\n";

    for (unsigned int a=0; a < lang; a++){
        cout << "Sende " << Data[a] << " Status: " << I2C.send(Data[a]) << "\n";
    }

    uint8_t response;
    cout << "Versuche ACK zu lesen: " << I2C.receive(&response, 1) << " Rückgabe: " << response ;

}

int main()
{
    cout << "Start I2C-1: " << I2C.setAddress(Read) << "\n";
    cout << "Slave found at: " << I2C.getAddress() << "\n";

    SendData("\x23""H75,");
    SendData("\x23""TI,");
    SendData("\x23""SV,");
    ReadSender();
}

Echt keinen plan, warum ich bei ReadSender kein ACK/NAK bekomme sonder 
irgendwelchen Datenmüll.
Hat jemand von euch eine Idee?

Zusatzinfo: Programme schreibe ich alle mit Code:Blocks und arbeite auf 
den GNUBLIN Systemboards.

[Peter D. (peda)]

Ich kenn Deine I2C-Lib ja nicht, aber üblicher Weise braucht man auch 
die Funktionen Start, sende Adresse+R/W und Stop.

Versuch doch erstmal, einen standard I2C-Slave im Page-Mode zuzugreifen, 
z.B EEPROM 24C64.

Es sieht auch nicht sonderlich übersichtlich aus, wenn man Funktions- 
und Debug-Code miteinander verwurstet. Ich würde dafür wenigstens 
separate Zeilen nehmen.

Besser wäre natürlich, daß man nur bei falschen Ergebnissen in einen 
Fehlerabbruch geht, der dann den Fehler ausgibt. Es ist ja in der Regel 
sinnlos, bei einem Fehler mit dem nächsten Schritt weiter zu machen.
Und bei einem I2C-Fehler muß man ja wenigstens noch ein Stop senden, um 
den Bus wieder in den Ruhezustand zu bringen.

P.S.:
IMHO muß man auch die Paketlänge und die korrekte CRC senden, sonst 
kommt natürlich kein ACK.

[Maik G. (maik_l)]

Peter Dannegger schrieb:
> Ich kenn Deine I2C-Lib ja nicht, aber üblicher Weise braucht man auch
> die Funktionen Start, sende Adresse+R/W und Stop.

wird alles durch die API 
http://gnublin.org/gnublin-api/doc/html_de/classgnublin__i2c.html 
gesteuert...

> Versuch doch erstmal, einen standard I2C-Slave im Page-Mode zuzugreifen,
> z.B EEPROM 24C64.

Ähmmm da seh ich aber keine Daten soweit ich das im Filter habe...

> Es sieht auch nicht sonderlich übersichtlich aus, wenn man Funktions-
> und Debug-Code miteinander verwurstet. Ich würde dafür wenigstens
> separate Zeilen nehmen.

Jedesmal rein und raus ebenso bescheiden. die von dir erwähnten 
Debugzeilen fliegen sowieso, wenn ich ein ACK bzw NAK sehe...

> Besser wäre natürlich, daß man nur bei falschen Ergebnissen in einen
> Fehlerabbruch geht, der dann den Fehler ausgibt. Es ist ja in der Regel
> sinnlos, bei einem Fehler mit dem nächsten Schritt weiter zu machen.
> Und bei einem I2C-Fehler muß man ja wenigstens noch ein Stop senden, um
> den Bus wieder in den Ruhezustand zu bringen.

Fehlerabbruche habe ich Bisher keine gehabt. sonst läuft das Programm ja 
wie es soll... erhalte im ACSII-Modus nur kein ACK / NAK. Egal, ob ich 
bcc mit sende oder nicht. Im beschriebenen BINÄR-Modus arbeitet das 
System nicht.

> P.S.:
> IMHO muß man auch die Paketlänge und die korrekte CRC senden, sonst
> kommt natürlich kein ACK.

Soviel zum Thema Paketlänge...

    I2C.send(lang);

[Peter D. (peda)]

Maik LoveNigth schrieb:
> wird alles durch die API
> http://gnublin.org/gnublin-api/doc/html_de/classgnublin__i2c.html
> gesteuert...

Na wenn Du das sagst.
Ich würds trotzdem erstmal mit einem EEPROM testen.

Maik LoveNigth schrieb:
>> Versuch doch erstmal, einen standard I2C-Slave im Page-Mode zuzugreifen,
>> z.B EEPROM 24C64.
>
> Ähmmm da seh ich aber keine Daten soweit ich das im Filter habe...

Du schreibst was rein "Hallo Welt" und dann liest Du es aus.

Maik LoveNigth schrieb:
> Soviel zum Thema Paketlänge...    I2C.send(lang);

Genau das meinte ich mit verwursten. In den riesen Debugausgaben 
übersieht man leicht die Funktion.
Und was machst Du, wenn die Daten 0-Bytes enthalten?
Und wo wird die CRC gesendet?

[Maik G. (maik_l)]

Peter Dannegger schrieb:
> Maik LoveNigth schrieb:
>> wird alles durch die API
>> http://gnublin.org/gnublin-api/doc/html_de/classgnublin__i2c.html
>> gesteuert...
>
> Na wenn Du das sagst.
> Ich würds trotzdem erstmal mit einem EEPROM testen.
>
> Maik LoveNigth schrieb:
>>> Versuch doch erstmal, einen standard I2C-Slave im Page-Mode zuzugreifen,
>>> z.B EEPROM 24C64.
Schauen, ob ich noch einen alten finde... Mach mir da a keine Hoffnung.
Bestellen??? Hmmm. Mindesbestellwert?!
> Maik LoveNigth schrieb:
>> Soviel zum Thema Paketlänge...    I2C.send(lang);
>
> Genau das meinte ich mit verwursten. In den riesen Debugausgaben
> übersieht man leicht die Funktion.

Da geb ich dir recht... Aber wer schreibt darf sowas nicht übersehen, 
und wenn doch muß er halt Trafic in kauf nehmen.
Bei so kleinen sachen geht das ja noch aber wenn es ü 2K zeilen Code 
sind... Aber wir verstehen uns.
> Und was machst Du, wenn die Daten 0-Bytes enthalten?

[c]if (Data != '')
     {
     Anweisung
     }

Darüber mach ich mir gedanken, wenn es soweit kommen sollte.
> Und wo wird die CRC gesendet?

Wenn du mit CRC das im Datesheet beschriebene bbc meinst...
Spielt keine Rolle, ob ich das im ACSII-Modus mitschicke oder nicht...

ACK Ist und bleibt <> 0x06 und NAK <> 0x15

und das ist das KERNPROBLEM...
Habe hier Sehr viele Themen gefunden, was dieses TFT-Display angeht, NUR 
Nicht die Bohne, wie das mit dem ACK gelöst wurde...

Wie gesagt... Selbst wenn ich es mir eine 24cxx teste wird das ergebnis 
das selbe sein... Das weiß ich jetzt schon...

Edit: Ob ich das nun via RS, I²C oder SPI mache spielt keine Rolle... 
das Problem ist und bleibt das selbe...

[Peter D. (peda)]

Ich kann Dir ja mal meinen funktionierenden Code zeigen.
Er läuft auf dem ATmega2560 über die UART3.

Ich hab die UART genommen, weil man da nicht irgendwelche Wartezeiten 
einbauen muß.
Bei I2C oder SPI muß man das nämlich.

[Maik G. (maik_l)]

Hmmm...

Ich hab so einen Leisen verdacht, als ob ich das Problem erahne...
Da ich ja mit "enDebian" also Systemboard arbeite werd ich wohl ein 
Problem mit dem Timings bekommen...

setzt mich heut Abend nochmal ran...

[Maik G. (maik_l)]

Moin peda.

Hab hier nochmal das Programm ohne Debug.

#include <cstdio>
#include <iostream>
#include <sstream>
#include <string>
#include <stdlib.h>

//#include with phad
#include </home/satan/Programming/APIs/gnublin.h>

using namespace std;

/* const for eDIP-Display ; Kontroll */
unsigned int    Read    = 0x6F;
unsigned char   bcc     = 0x00;
char            DC1     = 0x11;
char            DC2     = 0x12;
char            _1      = 0x01;
char            _2      = 0x02;
char            _3      = 0x03;
char            D       = 0x44;
char            I       = 0x49;
char            S       = 0x53;

/* var for eDIP-Display ; Data */

unsigned char   sbbr, rbbf;     /* [S]end [B]uffer [B]yte [R]eady
                                   [R]eceive [B]uffer [B]yte [F]ree */
uint8_t         ACK;            /* Read ACK from eDIP-Display */
unsigned char   _DC2, __2;


#define rt_Bar "#fb,3,8,1,"
#define gn_Bar "#fb,4,8,1,"
#define bl_Bar "#fb,2,8,1,"

gnublin_i2c I2C;

void ReadSender(){
    bcc = 0;
    I2C.send(DC2);
    I2C.send(_1);
    I2C.send(S);
    bcc = DC2 + _1 + S;
    I2C.send(bcc);
    I2C.receive(&ACK, 1);
    cout << "Lese " << ACK << "\n";

}

void ReadBuffer(){
    bcc = 0;
    I2C.send(DC2);
    I2C.send(_1);
    I2C.send(I);
    bcc = DC2 + _1 + I;
//    cout << "Sende " << bcc << " Status: " << I2C.send(bcc) << "\n";
    I2C.receive(&ACK, 1);
    cout << "Lese " << ACK << "\n";
    cout << "\tLese Buffer:";
    I2C.receive((unsigned char*)_DC2, 1);
    I2C.receive((unsigned char*)__2, 1);
    I2C.receive((unsigned char*)sbbr, 1);
    I2C.receive((unsigned char*)rbbf, 1);
    cout << "\tDC in: " << _DC2 << "\n2 in: " << __2;
    cout << "\nsbbr in: " << sbbr << "\nfbbr in:" << rbbf << "\n";
}

void SendData(string Data){

    unsigned char lang= Data.length();

    stringstream sData;
    bcc = 0;
    sData << Data;

    I2C.send(DC1);
    I2C.send(lang);

    for (unsigned int a=0; a < lang; a++){
        I2C.send(Data[a]);
    }

    uint8_t response;

    cout << "Versuche ACK zu lesen: " << I2C.receive(&response, 1) << " Rückgabe: " << response ;
}

int main()
{
    
    I2C.setAddress(Read);
    cout << "Slave found at: " << I2C.getAddress() << "\n";

    SendData("\x23""H75,");
    SendData("\x23""TI,");
    SendData("\x23""SV,");
    ReadBuffer();
    ReadSender();
}

Bin nur noch am überlegen, wie ich das mit dem udelay hinwerfe. Habe 
keine bescheide .h auf dem System liegen und codeblocks liefert wohl 
keine.