Probleme mit übertragung

[Paul (Gast)]

Hallo
Habe Probleme mit der übertragung von einem Atmega 128 zu einem Display
mit dem I2C Bus. Nach Angabe des Herstellers muss die übetragung so
erfolgen:

Farbe einstellen

#YDC Text-RGB, Text-Opacity(100), Background-
RGB(0x00000000), Background-
Opacity(0)

Definiert die Farbe des Terminalfensters bezüglich
Farbe und Transparenz von Text
Text-RGB(z.B: $FF0000 für Rot), Text-
Opacity und Hintergrund Background-
RGB, Background-Opacity .

Das ganze habe ich so gelöst

void Graphik_EA5_Schriftfarbe1_definieren(int32_t f1, int16_t f2, 
int32_t f3, int16_t f4)
  {
  int8_t bcc;
  bcc = DC1 + 0x09 + ESC + END + 'Y' + 'D' + 'C' + f1 + f2 + f3 + f4;
  i2c_start(slave_adresse_1);
  i2c_write(DC1);
  i2c_write(0x09);  // len 0b 09
  i2c_write(ESC);     // ESC

  i2c_write('Y');    // Y
  i2c_write('D');    // D
  i2c_write('C');    // C

  i2c_write(f1);    // x1
  i2c_write(f2);    // y1

  i2c_write(f3);    // a1
  i2c_write(f4);    // c1

  i2c_write(END);
  i2c_write(bcc);
  i2c_stop();
  }

Es erfolgt auch eine Berechnung der Prüfsumme und wenn alls korrekt ist
wird eine 6 zurück gegeben. Leider funktioniert es nicht.
Brauchte mal dringend Hilfe dazu. Beschreibung steht auf Seite 43.
LG Paul

[Wolfgang (Gast)]

Paul schrieb:
> Leider funktioniert es nicht. Brauchte mal dringend Hilfe dazu.

Was funktioniert nicht. Funktioniert die I2C-Kommunikation 
grundsätzlich, i.e. kommt vom Display ein Ack, wenn du es ansprichst?

[Paul (Gast)]

Hallo Wolfgang
mit dem angegebnen Code berechne eine Prüfsumme und übertrage diese auch 
zum Board. Dies Prüfsumme lese ich wieder aus und zeige sie mir auf 
einem zweiten Display an. Nach Herstellerangabe, wenn die Prüfsumme 6 
ist, ist die übertragung ok. Der Aufruf der Funktion erfolgt damit:

Graphik_EA5_Schriftfarbe1_definieren(000023,100,456700,100);

Damit wird der Farbwert für Vorder- und Hintergrind angegeben und die 
Transparenz. Leider erfolgt keine Reaktion auf dem Display.

LG Paul

[Paul (Gast)]

Die Kommunikation mit dem I2C Bus erfolgt und auch ACK wird 
zurückgegeben. Ein anderer Befehl mit dem Cursor z.B. Position und 
blinken erfolgen ohne Probleme

[Paul (Gast)]

Kann mir keiner helfen?

[Theor (Gast)]

Ich habe mal nachgeschaut, weil mir die Berechnung der Prüfsumme 
"ungewöhnlich" vorkam.

void Graphik_EA5_Schriftfarbe1_definieren(int32_t f1, int16_t f2, 
int32_t f3, int16_t f4)
  {
  int8_t bcc;
  bcc = DC1 + 0x09 + ESC + END + 'Y' + 'D' + 'C' + f1 + f2 + f3 + f4;
  ...

Das entspricht nicht der Beschreibung auf Seite 40, Fußnote 3 sowie dem 
Beispielcode auf Seite 42.

Du rechnest hier nämlich (implizit) in int (nicht int8) und 
berücksichtigst bis auf das niederwerstigste die restlichen Bytes von 
f1, f2, f3 und f4 nicht . Sie müssen aber berücksichtig werden. Der 
Beispielcode auf Seite 42 berechnet nämlich die Checksumme über jedes 
einzelne Byte. (Ich würde erwarten, dass Du da eine Warnung vom Compiler 
erhalten solltest. Schau mal ob Du alle Warnungen angeschaltet hast oder 
ob Du Warnungen ignoriert hast).

Daraus folgt, dass die Checksumme (bis auf Zufälle) nicht stimmen 
kann.

Daraus wiederum folgt die Vermutung, dass Deine Annahme, die Rückgabe 
von "6" würde eine erfolgreiche Übertragung signalisieren nicht stimmt. 
(Da könntest Du mal genauer schreiben, wo genau Du das in der 
Beschreibung gelesen hast).

Ich empfehle Dir, falls der Fehler nach der Korrektur der Prüfsumme 
immer noch vorhanden ist, mal einen minimalen aber kompletten Code zu 
posten. Falls Du eine fertige I2C-Library verwendest auch einen Link 
darauf.

[Paul (Gast)]

Hallo Theor
Du hast als Prüfsummenberechnung das Short angesehen. Verwende aber das 
Small Protokoll. Leider ist im (vorläufigen) Datenblatt des Herstellers 
nichts konkretes drin. Das gleich Smart Ptotokoll wird auch für das E 
DIP TFT 32 verwendet. Dort ist ein "bischen" mehr beschrieben. Da ich 
gleizeitig mit 2 Displays arbeite sehe ich auch immer das Ergebniss der 
Prüfsumme. Beim TFT32 habe ich ca 50 Befehle bereits in C übersetzt. 
Alle laufen dabei nach dem gleichen Schema. Nach Angabe des Herstellers 
wird das gleiche Protokoll verwendet und "soll" genau so funktionieren. 
Es scheint noch eine Anzahl von Fehlern im Datenblatt zu sein. Habe aber 
dazu keine Info bekommen.
Die Wanungen habe ich nicht abgeschaltet. Bekomme keine dazu. Sobald ich 
etwas falsch eingebe bekomme ich eine Warnung oder Fehler angezeigt

LG Paul

[Theor (Gast)]

Paul schrieb:
> Hallo Theor
> Du hast als Prüfsummenberechnung das Short angesehen. ...

Nein. Das habe ich nicht getan. Das Short-Protokoll verwendet eine 
CRC-Prüfsumme. Das Small-Protkoll die einfache Summe über die Bytes 
Modula 2^8. Schaue bitte nochmal nach.


> ...Leider ist im (vorläufigen) Datenblatt des Herstellers
nichts konkretes drin.

Also das von Dir verlinkte ist in dieser Hinsicht äusserst konkret. Was 
vermisst Du denn da?

> Das gleich Smart Ptotokoll wird auch für das E DIP TFT 32 verwendet.

Was denn nun? Small, Smart oder Short?


Mir ist noch eine Sache eingefallen, die ich zwar gesehen, aber 
vergessen habe zu schreiben.

Du verwendest zum Senden von Zeichen und int16 und int32. Das sollte 
auch Warnungen ergeben und ggf. nicht funktionieren. Denn, falls das C 
ist, gibt es keine Mehrfachdefinitionen von Funktionen mit verschiedenen 
Parametertypen (es sei denn ich habe mal wieder einen Punkt der neueren 
Standards nicht gesehen).

[Theor (Gast)]

Es ist natürlich überflüssig, aber es fuchst mich doch ein wenig:

Ich habe Dir geschrieben "Seite 40". Das erste was da unterhalb des 
Seitenkopfes steht ist: "SMALL PROTOKOLL BEFEHLE".
Ebenso habe ich auf "Seite 42" verwiesen. Das erste was da unterhalb des 
Seitenkopfes steht, ist: "SMALL PROTOKOLL". Wie kommst Du darauf, das 
ich unter "Short" nachgesehen habe?

Ein überflüssiges und etwas ärgerliches Mißverständnis, finde ich.

[Theor (Gast)]

Naja. Ich will noch anfügen, das mir sowas auch schon passiert ist. 
Also, soooo ernsthaft bin ich auch nicht ärgerlich.

Aber noch folgendes:

Du schreibst:
> Die Wanungen habe ich nicht abgeschaltet. Bekomme keine dazu. Sobald
> ich etwas falsch eingebe bekomme ich eine Warnung oder Fehler angezeigt

Dann solltest Du mal genaueres über Deine Entwicklungsumgebung, den 
Compiler und die Sprache und ihre Version erzählen.

Das ist nämlich nicht plausibel wenn ich normales ANSI-C annehme. Dort 
gibt es keine Polymorphie - also gleichnamige Funktionen mit 
unterschiedlichen Parametertypen oder Anzahlen. Du MUSST unter den von 
mir angenommen Voraussetzungen Warnungen oder gar Fehler bekommen, oder 
irgendwas läuft grundsätzlich schief.

[Paul (Gast)]

Hallo
Auf Seite 42 steht im obereb Drittel ein kleines C Programm, fast ohne 
jede Erklärung. Vergleiche diese mal mit meiner Routine
Habe dir mal das Datenblatt zum TFT32 angehängt. Steht etwas mehr drin, 
auf Seite 7 und 10. Mit dieser Erklärung bin ich soweit klar gekommen.
Verwende einen Atmega 128 und Arbeite mit dem Atmel (AVR) Studio 7. Beim 
I2C Bus verwende ich die Datein von Peter.Im Programm verwende ich die 
uniTFT5.c und .C im die Prototyphen zu deklarieren und die Funktion zu 
programmieren. Im Programm selber kommt nur der Aufruf mit übergabe der 
Parameter. Teilweise können das bis zu 20 Daten zur übergabe sein. Es 
erfolgt noch eine überprüfung der Parameter und wenn nötig werden sie 
zerlegt und auf die Grösse angepasst. Diese Teile sind sehr gut aber 
leider nicht billig. Es gibt auch kaum Literatur dazu. Sie haben aber 
sehr grossen Vorteil, sie sind schnell. Sollen so um die 8 Mikrosekunden 
Reaktionszeit haben. Teilweise baue ich ein zusätzliche Verzögerung von 
100 Mikrosekunden ein um sicher auszulesen. Da eine SD Karte an Board 
ist, kann ich verschiedene Bilder über USB laden und wenn nötig 
aufrufen. Ansonsten habe ich sehr viele Graphik Befehle mit der ich viel 
machen kann.
Das mit den 32 und 8 kommt aus der übergabe der Farbe. Für die Farbe 
muss ich FFFFFF übergeben. Jeweils 2 FF stehen für eine Grundfarbe, kann 
also die 3 Grundfarben jeweils von 0-255 angeben und entsprechende 
Farben erzeugen. Das ist die Stelle die nicht funktioniert. Wollte einen 
farbigen Hintergrund erzeugen und die Schrift oder andere Objekte in 
anderer Farbe darstellen. Diese Funktion wir z.B. auch für farbige 
Striche oder Ränder verwendet.

LG Paul

[Theor (Gast)]

Naja. Ich wünsche noch viel Erfolg.

[Theor (Gast)]

Hach. Seufz. Ich sollte mich lieber jetzt endgültig verabschieden. Habe 
heute nicht so viel Geduld mit sowas. Oder ich mache gerade einen ganz 
dummen Fehler. Kann auch sein.


Jetzt schau DU Dir mal den Code an und vergleiche ihn.

Was ist der Unterschied zwischen:

void Graphik_EA5_Schriftfarbe1_definieren(int32_t f1, int16_t f2, 
int32_t f3, int16_t f4)
  {
  int8_t bcc;
  bcc = DC1 + 0x09 + ESC + END + 'Y' + 'D' + 'C' + f1 + f2 + f3 + f4;
  ...

und

UBYTE buffer2bcc(UBYTE *dat, UBYTE anz)
{
UBYTE bcc = 0;
while(anz--)
      bcc += *dat++;
return bcc;
}

?

Den Grund, warum das NICHT identische Wirkung hat, habe ich hier 
Beitrag "Re: Probleme mit übertragung" schon beschrieben. 
(Habe aber noch vergessen, das int8_t und UBYTE natürlich auch noch 
einen Unterschied machen.

Aber, - verzeih bitte, wenn ich das so unverblümt sage -, das sind 
Grundlagen und keine subtilen Probleme.

So. Bin dann jetzt mal raus. Viel Erfolg noch.

[Paul (Gast)]

Dann meinst du sicher diese Stelle:

UBYTE buffer2bcc(UBYTE *dat, UBYTE anz)
{
UBYTE bcc = 0;
while(anz--)
bcc += *dat++;
return bcc;
}

Leider erschliest sich die Fuktion nicht so richtig. Sehe das ein 
Schleife den Wert der bcc hoch zählt.
Doch wo muss ich meine Daten einsetzen. UBYTE ?

Vielleicht känntest du mir zum Abschied noch mal helfen

LG Paul

[Theor (Gast)]

Lieber Paul.

Das wird zu umfangreich - jedenfalls für mich heute Abend.

Schon die Beschreibung der Wirkung ist falsch. Nicht die Schleife zählt 
etwas hoch, sondern im Schleifenkörper steht eine Anweisung die zu bcc 
die Datenbytes addiert.
Und UBYTE ist ein Datentyp des Parameters nicht der Parameter. Dafür 
kannst Du keine Daten einsetzen.

Da schnappst Du Dir mal ein C-Buch und liest ganz in Ruhe die Kapitel 
über Funktionen und Datentypen und implizite Datentypumwandlungen bei 
Operationen durch.

Danke.

[Alex G. (dragongamer)]

Das ist ja auch mal ne beknackte Code-Formatierung ala Spagetticode aus 
dem Lehrbuch wie man es nicht machen sollte (wenn sich jemand anderes 
auser man selbst, den Code ansehen muss) >_>

So ist das erheblich weniger verwirrend und sollte das selbe tun:

UBYTE buffer2bcc(UBYTE *dat, UBYTE anz)
{
  UBYTE bcc = 0;

  while(anz)
  {
    anz--;
    bcc += *dat;
    dat++;
  }

  return bcc;
}

Nach dem Kompilieren wird das auch fast identische 
Maschinen-Instruktionen ergeben und nicht langsamer laufen.

Und achso - deine Daten müssen wohl hintereinander an die Adressen nach 
"dat" stehen. Was diese Schleife tut, ist "dat" als Pointer zu verstehen 
(das Stern Symbol ist der "dereferenzierer") und somit den Inhalt der 
aufeinanderfolgenden Adressen ('anz' Stück davon) zu summieren.

[Theor (Gast)]

Es ist alles gesagt, nur noch nicht von jedem. (Karl Valentin)

[Paul (Gast)]

Meinst du vielleicht das hier:

void Graphik_Text_ausgabe_L(int8_t x1, int8_t y1, char * Text)
    {    
    int8_t bcc,i;
    bcc = DC1 + 0x06 + ESC + 'Z' + 'L' + x1 + y1 + strlen(Text);
    for (i=0; i<=strlen(Text); i++)
    bcc += Text[i];
    i2c_start(slave_adresse_1);
    i2c_write(DC1);
    i2c_write(0x06 + strlen(Text));  // len 0x06+Text 
    i2c_write(ESC);
    i2c_write('Z');    // Z
    i2c_write('L');    // L
    i2c_write(x1);
    i2c_write(y1);
    for (i=0; i<=strlen(Text); i++)
    i2c_write(Text[i]);
    i2c_write(bcc);
    i2c_stop();
    _delay_us(10);
    i2c_start(slave_adresse_2);
    e = i2c_readAck();
    i2c_stop();
    _delay_us(10);    
    }

Diesen Code verwende ich zur Ausgabe von Text, wobei die Länge des 
Textes ermittelt wird und zur Länge addiert wird.

LG Paul