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
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?
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:
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
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.
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
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).
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.
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.
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
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:
?
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.
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
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.
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.
Thread beobachten
Seitenaufteilung abschalten