Hallo,
ich habe ein EDIPTFT70 ATP, hier mal das Datenblatt:
http://www.lcd-module.de/fileadmin/pdf/grafik/ediptft70-a.pdf
Auf Seite 10 ist das übertragungsprotokoll beschrieben. Ich kapiere es
aber einfach nicht. Kann mir da mal jemand helfen?
Als Code müsste z.b. gesendet werden: #DL
Das würde den Displayinhalt löschen.
Die Adresse zum schreiben lautet $DE und zum lesen $DF (Datenblatt Seite
7, alle PINs offen)
Ich bekomme einfach keine komunikation hin.
Hier mal mein I2C Code.
Nunja, das ist ja auch nur mein I2C Code also die funktionen Start, Stop
usw.
Ich verstehe halt den Punkt von EA nicht. Ich muss das ja in dieses
Protokoll verpacken aber da scheitert es dann.
$DE <-- was ist das für eine Adresse? und dann mit diesem len und bcc,
ich muss die länge bestimmen, die prüfsumme, das verstehe ich alles
nicht
Also um die Adresse zusenden müsste es ja dann so sein:
i2c_start();
i2c_send($DE | TW_WRITE);
aber da fängt es dann schon an, $DE ist hier schon ein fehler. Und wie
berechne ich die länge und die Prüfsumme? wie kriege ich aus dem
SmartProtokoll daten, die immer mit einem # beginnen und dann der Code,
also z.b. #DL nun das ich das senden kann, also die länge, die prüfsumme
usw?
$DE ist ja laut datenblatt die adresse des Displays zum senden und $DF
die Adresse des Displays zum lesen, nunja, EA macht es da nicht gerade
einfach.
Was heisst ich kann C grundsätzlich? Also sagen wir mal so, ich komme
klar mit dem was ich bisher so brauchte.
Coder schrieb:> $de ist wohl eine hex-Zahl.
Ich weiss das wohl, aber weiss das der Compiler?
Tobias N. schrieb:> Was heisst ich kann C grundsätzlich? Also sagen wir mal so, ich komme> klar mit dem was ich bisher so brauchte.
Nicht böse sein, aber: offensichtlich nicht.
eine hex-Konstante schreibt man 0xde, aber nicht $de
Hallo,
Bzgl. dem Small-Protokoll kann Ich Dir weiterhelfen. Ich habe mit diesem
am Anfang auch meine Probleme gehabt. Die Prüfsumme "bcc" wird auf der
Seite 10 erläutert. Dort wird zwar die Übertragung als Funktion
aufgeführt. dein $ gibt ja an, wie bereits erwähnt, dass dieses ein
HEX-Wert ist. Wenn Du das EDIPTFT mit der Demoplatine hast, dann kannst
Du über einen Jumper das Small-Protokoll zu testzwecken abschalten und
erst einmal die Übertragung probieren. Wenn dieses funktioniert, dann
versuche das Protokoll zu verwenden.
Ich habe hier auch das 70'er Display und steuere dieses via UART an.
Hier habe Ich auch als erstes das Protokoll abgeschaltet und nach
erfolgreichen Ansprechen, dieses nach der Vorlage im Datenblatt
eingepflegt.
nunja, ich habe halt das prob das ich es nicht hinbekomme die länge und
die prüfsumme zu errechnen etc. pp.
$DE wäre ja 11011110, bzw 1101111 und die 0 als "write" $DF = 11011111
bzw. 1101111 und die 1 also read, also wäre die 7 Bit Adresse des
Displays 1101111 ok, soweit so gut aber es geht ja um das genaue Senden
da EA ja auf seine Prüfsumme etc. besteht.
Tobias N. schrieb:> nunja, ich habe halt das prob das ich es nicht hinbekomme die> länge und> die prüfsumme zu errechnen etc. pp.>> $DE wäre ja 11011110, bzw 1101111 und die 0 als "write" $DF = 11011111> bzw. 1101111 und die 1 also read, also wäre die 7 Bit Adresse des> Displays 1101111 ok, soweit so gut aber es geht ja um das genaue Senden> da EA ja auf seine Prüfsumme etc. besteht.
Bekonnst Du denn überhaupt eine Übertragung zum Display hin, denn Seite
10 steht ja: "Für Tests kann das Protokoll durch L-Pegel an
Pin17(DPROT) abgeschaltet werden"
Für das Small-Protokoll wird dann folgendes gemacht:
<DC1> + Länge des gesendeten Befehls + Byte-Wert des jeweiligen
ASCII-Zeichens modulo 256
Bedeutet für "#DL," (Mit Komma):
<DC1> = 11h = 17d
Länge des Befehls "#DL," = 4
# = 23h = 35d
D = 44h = 68d
L = 4Ch = 76d
, = 2Ch = 44d
Insgesamt: F4h = 244d
Wieso mit komma? In dem programm von ea für das Display schreibe ich es
auch ohne komma.
Woran soll ich denn erkennen ob ich eine verbindung bekomme?
i2c_start();
i2c_send(11011110);
Nur ob das display nun antwortet, kA.
Tobias N. schrieb:> Wieso mit komma? In dem programm von ea für das Display schreibe> ich es> auch ohne komma.>> Woran soll ich denn erkennen ob ich eine verbindung bekomme?>> i2c_start();> i2c_send(11011110);
Indem du die Antwort ausliest?
Tobias N. schrieb:> $DE <-- was ist das für eine Adresse? und dann mit diesem len und bcc,> ich muss die länge bestimmen, die prüfsumme, das verstehe ich alles> nicht
Ist zwar kein I2C-Bus, sondern UART, vielleicht hilft dir das:
Hallo,
wie oben schon beschrieben #DL entspricht in C: 0x1B 0x44 0x4C.
Dann klappt es auch mit deinem Display. Ich habe es allerdings auch mit
der seriellen Schnittstelle angesprochen, weil es einfacher ist.
Bernd
Hallo Tobias,
was ist eigentlich Deine Frage?
Daß Du "es" nicht hinbekommst, hab ich verstanden, aber sonst?
Hast Du schon mal eine I2C-Kommunikation aufgebaut, oder ist es die
erste?
Welche Hardware verwendest Du? Ist die wenigstens in Ordnung?
Deine C-Kenntnisse, gehen die über zusammenkopieren von anderen
Programmteilen hinaus?
Hast Du schon selbsständig lauffähige C-Programme geschrieben?
Drehen sich die Fragen von Dir nur um das Protokoll? Oder uach um C?
Ich blick noch nicht so ganz.
gcc -o test test.c && ./test
00010001- 0x11 - ''
00000011- 0x3 - ''
00100011- 0x23 - '#'
01000100- 0x44 - 'D'
01001100- 0x4c - 'L'
11000111- 0xc7 - '�'
Ich habe so ein kleines c programm bekommen das gibt mir diese ausgabe.
also das ist das ganze programm. das gibt mir halt das was ich da rein
schreibe in binär hex etc aus.
was stimmt denn nun? was muss ich dem display nun senden?
Tobias N. schrieb:> was stimmt denn nun? was muss ich dem display nun senden?
Das ist eigentlich die falsche Frage.
Die eigentliche Frage lautet doch "Wie sag ichs meinem C-Compiler"
Denn wenn du eine Binärzahl hast, dann schreibt sich das im gcc nun mal
als
1
i2c_send(0b11011110);
und nicht als
1
i2c_send(11011110);
Aber:
warum schreibst du es denn nicht als
1
i2c_send(0xDE);
ist doch viel einfacher zu lesen und stimmt dann auch beiläufig auch
noch mit dem $DE aus dem Datenblatt überein.
Wenn deine I2C Routinen funktionieren und die Busanbindung korrekt ist,
hast du soeben "#DL' zum DIsplay übertragen.
Natürlich wird man sich dann eine Funktion schreiben (bzw. aus dem
Datenblatt übernehmen), die den Teil "String Ausgabe im Small Protokoll"
übernimmt und dazu die Länge bzw. die Prüfsumme bestimmt und die dann
aufrufen
1
i2c_start();
2
3
i2c_send(0xDE);
4
i2c_send_data("#DL");
5
6
i2c_stop();
aber im Grunde passiert da auch nichts anderes. Nur das diesmal eben die
i2c_send_data das DC1 einfügt, die Länge einfügt und die Prüfsumme
bestimmt.
na wenn das geht ist das doch tutti :)
Also übergebe ich den Code dann halt nicht als Binärzahl sondern so wie
mir das Programm das dann ausgibt mit den 0x ausgaben?
da ist ja dann die länge, die prüfsumme usw mit dabei!?
Tobias N. schrieb:> du meinst sowas in der art wie ich weiter oben schon gepostet habe, nur> nicht mit den Binärzahlen
Immer noch nicht.
Du hattest keine Binärzahlen.
Das hier
1
i2c_send(11011110);
ist keine Binärzahl. Das ist eine Dezimalzahl, die zufällig nur aus
lauter 1-en und 0-en aufgebaut ist. So wie eben 10 (zehn) aus einer 1
und einer 0 besteht oder 11 (elf) aus 2 STück 1-ern oder ein tausend
einhundert und elf sich als 1111 schreibt.
11011110 ist die Dezimalzahl 11 Millionen 11 Tausend und 1 Hundert Zehn.
Tobias N. schrieb:> was stimmt denn nun? was muss ich dem display nun senden?
steht doch im Datenblatt, ist dir eigentlich bewusst das du diese
EDIPTFT70 ohne Peripherie steuern kannst, es stehen ein Editor und
Compiler zur Verfügung, damit kannst du Menüs, Touchbars, Bilder uvm
aufbauen (es stehen glaube ich um 4MB zur Verfügung), und später über zB
µC steuern.
Du kannst auch direkt an Computer anschließen (Pegelwandler nicht
vergessen) und per UART ansprechen.
Hier mal Textausgabe für EDIPTTFT70:
Ja, ich habe ja Menüs, Bargraphen usw. Ich will ja die Werte übergeben
per UC und halt auch werte per Display ändern usw.
Das #DL will ich halt erstmal zum Testen senden um zu sehen ob überhaupt
was geht. Wenn ich den COde so sende wie von Karl Heinz dann löscht sich
das Display also muss ich jetzt halt nur noch eine Routine dafür haben.
Also ich hänge da noch bei den variablen fest.
Also wenn ich
char[25] = Buffer;
itoa(fototrans,Buffer,10);
SendDisplayData("#ZF8,0,ADC-Wert: Buffer,");
sende dann schreibt der mir auf das Display "Buffer" aber nicht den wert
von fototrans. fototrans ist der ADC Wert von einem Fotowiderstand.
Wie kriege ich denn nun einen variablen Wert darein?
Tobias N. schrieb:> Also ich hänge da noch bei den variablen fest.>> Also wenn ich>> char[25] = Buffer;> itoa(fototrans,Buffer,10);>> SendDisplayData("#ZF8,0,ADC-Wert: Buffer,");>> sende dann schreibt der mir auf das Display "Buffer"
Logisch.
Nur weil du einen String hast
1
"#ZF8,0,ADC-Wert: Buffer,"
in dem ein Wort vorkommt, das gleichlautend mit einer deiner Variablen
ist, wird ja nicht im String dieses Wort durch den Inhalt der Variablen
ersetzt. String ist String und der Compiler vergreift sich nicht daran.
Wenn du den Text "Buffer" aufs LCD schreiben willst, dann hindert dich
nichts und niemand daran.
> aber nicht den wert> von fototrans. fototrans ist der ADC Wert von einem Fotowiderstand.>> Wie kriege ich denn nun einen variablen Wert darein?
Du könntest zum Beispiel deine Ausgabe auf 2 oder 3 mal machen. Sagt ja
keiner, dass du nicht mehrere Texte hintereinander ausgeben darfst.
Einmal schickst du per SendDisplayData den Fixtext und beim 2.ten Aufruf
schiebst du den von dir ermittelten String vom Zahlenwert hinten nach
1
itoa(fototrans,Buffer,10);
2
3
SendDisplayData("#ZF8,0,ADC-Wert: ");
4
SendDisplayData(Buffer);
5
SendDisplayData(",");
du kannst auch alles in einem Aufwasch machen, indem du den String
gleich komplett richtig erzeugst
1
sprintf(Buffer,"#ZF8,0,ADC-Wert: %d,",fototrans);
2
SendDisplayData(Buffer);
sprintf bietet sich zb dann an, wenn Speicherverbrauch keine Rolle
spielt und man von den Formatiermöglichkeiten der printf Funktionen
Gebrauch machen kann.
Karl Heinz schrieb:> Du könntest zum Beispiel deine Ausgabe auf 2 oder 3 mal machen. Sagt ja> keiner, dass du nicht mehrere Texte hintereinander ausgeben darfst.
(*)
wobei.
Da bin ich mir jetzt nicht sicher, wie das LCD die Sache da sieht, bzw.
was die Bedeutung von #ZF8,0 ist.
Im schlimmsten Fall muss man dann eben tatsächlich 2 Textausgaben
anleiern, wenn das LCD das nicht akzeptiert, dass es einen Text in 2
Happen bekommt.
so wie das mit dem sprintf habe ich es gesucht. Mehrfach schieben geht
nicht bzw nicht so da durch die funktion immer ein kompletter befehl
gesendet werden muss da ja in der funktion i2c gestartet und gestopt
wird. Würde ich das so schreiben, also das buffer versuchen
nachzuschieben sendet das display mir einen nack dann müsste ich die
funktion wohl umbasteln. Wiederrum könnte ich das sprintf ja in die
funktion bauen, oder?
In wieweit ich speicher brauche weiss ich erst wenn alles fertig ist.
Karl Heinz schrieb:> Karl Heinz schrieb:>>> Du könntest zum Beispiel deine Ausgabe auf 2 oder 3 mal machen. Sagt ja>> keiner, dass du nicht mehrere Texte hintereinander ausgeben darfst.>> (*)> wobei.> Da bin ich mir jetzt nicht sicher, wie das LCD die Sache da sieht, bzw.> was die Bedeutung von #ZF8,0 ist.> Im schlimmsten Fall muss man dann eben tatsächlich 2 Textausgaben> anleiern, wenn das LCD das nicht akzeptiert, dass es einen Text in 2> Happen bekommt.
Max 256byte danach muss der string geteilt werden. Dem display kann man
schieben und schieben (laut datenblatt). Nur schicke ich lieber befehl
nach befehl und bin mir da auf der sicheren seite bei meinem derzeitigen
kenntnis stand.
Tobias N. schrieb:> nicht bzw nicht so da durch die funktion immer ein kompletter befehl> gesendet werden muss
Das ist mir etwas zu spät geschwant :-)
Wenn du auf itoa stehst, dann kannst du natürlich auch vorher den String
komplett zusammensetzen. strcat und strcpy sind deine Freunde.
1
charbuffer[15];
2
chartotal[40];
3
4
itoa(fototrans,Buffer,10);
5
6
strcpy(total,"#ZF8,0,ADC-Wert: ");
7
strcat(total,Buffer),
8
strcat(total,",");
9
10
SendDisplayData(total);
> funktion wohl umbasteln. Wiederrum könnte ich das sprintf ja in die> funktion bauen, oder?
Wer oder was sollte dich daran hindern?
Du bist der Programmierer. Auf deinem µC bist du Gott und machst dir die
Welt, so wie sie dir gefällt und du sie für richtig hältst.