Hallo gemeinde
Habe ein Display DOG XL160 zum Gebustag geschenk bekommen. Da ich einige
Teile mit dem i2C Bus betreibe möchte ich auch dieses Display mit dem
Bus betreiben. Habe nach dem DB es so aufgebaut, wie es der Hersteller
vorgibt. Kann auch die Adresse 0x7e auslesen. Mehr kommt leider nicht.
Das DB des Herstellers ist für mich seht kurz geraten und geht wenig auf
die Programmierung ein. Nach einer längeren Suche im Netz mit Tante
google habe ich kaum was zum i2C Bus gefunden. SPI scheint es weit mehr
zu geben. Kann mir dabei jemand auf die Sprünge helfen?
Arbeite mit C und einem Atmega 128
LG Klars
Habe mir das Datenblatt des UC1610 angesehen und auch im Netz nach Infos
gesucht. Steht einiges dazu drin. Leider komme ich damit nicht klar. Das
beginnt schon mit der init.
Hast du ein parr Infos für mich?
Hi
>Leider komme ich damit nicht klar. Das beginnt schon mit der init.
Die funtioniert so, wie im Datenblatt beschrieben. Was verstehst du
daran nicht?
MfG Spess
Im Datenblatt ist die Reihenfolge beschrieben, bei mir Seite 31. Danach
erfolgt der Anschluss an den Prozessor mit I2C und andere Anschlüsse.
Scheint verschiedene DB zu geben. Es sind Register beschrieben. Leider
komme ich mit dem Aufruf wann welches nicht klar und welche Daten.
Etwas mehr Quelltext wäre ganz nett. U.U. auch wie das LCD bzw. ob es so
wie im DB auf Seite 5 verschaltet ist (ein Kondensator 100nF oder 1uF
zw. VDD und VSS nah an den Pins 23/24 bzw. 25/26 kann u.U. nützlich
sein)
Initialisierung nach DB sollte funktionieren bzw. die Sequenz wäre:
Reset auf Low, 1 ms warten, Reset auf High, danach die Werte wie im DB
schreiben, dann Set Display Enable. Danach läuft die Programmierung
recht simpel: Spalte festlegen (Set Column Address LSB und MSB), Zeile
festlegen (Set Page Address) und dann die Daten mit Write Data hinterher
(hab die Teile hier allerdings nur im SPI-Modus in etlichen Geräten in
Betrieb)
Edith: Datenblatt =
https://www.lcd-module.com/eng/pdf/grafik/dogxl160-7e.pdf
Habe es genau wie auf Seite 5 beschrieben ist verdrahtet. Habe auch den
Kondensator mit 100nF eingesetzt, fast direkt an den Pins. Es sind auch
beiden Bus Widerstände drin. Display geht ohne Problem da ich die
Adresse auslesen kann.
Mit SPI finde ich einiges im Netz. Leider kaum was zu I2C. Habe auch
andere Displays von EA in Nutzung, alles mit I2C, keine Probleme
Klars schrieb:> Mit SPI finde ich einiges im Netz. Leider kaum was zu I2C.
Meinst Du denn, daß das Display andere Daten sehen will, nur weil es an
einer anderen Schnittstelle hängt?
" Display geht ohne Problem da ich die Adresse auslesen kann."
Hallo,
Das Display hat vier Adressen, zwei zum Lesen und zwei zum Schreiben,
oder vier andere, wenn A2 high ist.
Bekommst Du ACK beim Schreiben?
MfG
Beim auslesen der Adresse bekomme ich ACK. Ist so in diesem Programm.
Wenn ich die Adressenwahl umstecke bekomme ich die 2 Adesse. Ist die
0x7e und 0x7a. Etwas auf Display habe ich nocht nicht geschrieben.
Verstehe das init nicht
OK, das ist "write data".
Ich beziehe mich auf Seiten 5 und 6 aus dem Link oben. Das Datenblatt
zum Controller habe ich NICHT ausführlich gelesen.
Es scheint Befehle zu geben, die mehr als ein Byte lang sind, siehe
Seite 5 unten. Kommandos sollen auf die Kommandoadresse geschrieben
werden als ein I2C-Zugriff mit Start und Stop. Dann das nächste Kommando
auf diese Art, bis die Initialisierung laut Plan durchlaufen ist. Du
wendest hierfür nur das Schema "write mode" an.
Die Umschaltung zwischen Kommando und Daten macht das Bit CD auf Seite 5
unten. Dieser Trick wird als neue Adresse verkauft.
So ein kompliziertes Datenblatt versteht man eigentlich nur dann, wenn
man es bereits versteht oder mit ähnlichen heimlich vorher geübt hat.
Das ist wie mit dem Ei und der Henne, wobei ebenso ein Krokodil dafür in
Frage kommen könnte.
Hier habe ich das Spiel mal für ein anderes Display gemacht:
https://www.mikrocontroller.net/attachment/308034/Sanbum_LBL-11337-1-01.zip
Du kannst ja mal die Initialisierung schreiben und hier rein stellen,
dann werden die Experten schon finden, woran es liegt.
MfG
Da kann ich dir nur Rechtr geben. Habe das Datenblatt teilweise
übersetzt und versucht zu verstehen. Habe beim Hersteller nach Infos
gesucht und im Netz dazu. Leider gibt es kaum was dazu. Das Datenblatt
verstehe ich auch nicht in DE. Ist so ein schönes Display ...
Dann lies mal das Dabla zum Sanbum durch und vergleiche mit dem Code aus
dem ZIP. Das kann durchaus ein paar Tage dauern, aber das Sanbum ist
deutlich einfacher und dann klappts auch mit dem Krokodil.
Beim RFM70 habe ich mich auch mal für Übersetzen entschieden.
MfG
Hi
>Das Datenblatt verstehe ich auch nicht in DE.
Was verstehst du da eigentlich nicht? Ist es die Befehlsfolge oder hast
du Probleme mit I2C.
Ich habe das DOGXL160 (mit der angegebenen Initialisierung) mit SPI
getestet. Das hat ohne Probleme sofort funktioniert.
Allerdings verstehe ich eigentlich nicht, warum man bis zu 12MHz
Ubertragungs takt bei SPI gegen I2C mit zweifelhaften Eigenschaften
eintauschen sollte.
MfG Spess
Hallo Spess
mit dem I2C Bus habe ich keine Probleme. Betreibe auch andere Displays
und ICs am Bus. Habe Probleme mit der Befehlsfolge des displays. Bei
meinen Teilen funktioniert der Bus ohne jede Probleme. Habe teilweise
ca. 5 verschiedene Teile am Bus. Leider ist für mich die Reihenfolge und
was ich zum Display übertragen soll das Problem.
LG Klars
Klars schrieb:> Habe Probleme mit der Befehlsfolge des displays.> Leider ist für mich die Reihenfolge und> was ich zum Display übertragen soll das Problem.Klars schrieb:> Mit SPI finde ich einiges im Netz.
Was verstehst Du an:
Rufus Τ. F. schrieb:> Meinst Du denn, daß das Display andere Daten sehen will, nur weil es an> einer anderen Schnittstelle hängt?
nicht?
Klars schrieb:> Du meinst also das SPI und I2C beim init gleich ist?
Ja, Initialisierung ist identisch. In beiden Fällen ist/sollte(s.o.) die
Abfolge identisch sein:
Reset auf low, warten, Reset auf high (kann zwar laut Datenblatt
weggelassen werden bzw. auf VDD gelegt werden, ist aber nicht verkehrt
den Reset auch manuell durchführen zu können...).
Danach die Sequenz aus dem Datenblatt übertragen (Initialisation
example).
Rest besteht, falls das Display nicht mehr an/aus geschaltet werden
soll, nur noch aus Set Column und Set Page Address und Write Data.
i2c_start(Write_Command);// set device address and write mode
2
i2c_write(0xF1);// Set last COM electrode to 103 (number of COM electrodes - 1)
3
i2c_write(0x67);//
4
i2c_write(0xC0);// SEG (column) and COM (row) normal
5
i2c_write(0x40);// Set Display Startline to 0
6
i2c_write(0x50);//
7
i2c_write(0x2B);// Set Panelloading
8
i2c_write(0xEB);// Set Bias to 1/12
9
i2c_write(0x81);// Set Contrast
10
i2c_write(0x5F);//
11
i2c_write(0x89);// Set Auto-Increment
12
i2c_write(0xAF);// Display on
13
i2c_stop();// set stop conditon = release bus
Damit kann ich die INI Exampel übertragen.
Das Teil des Codes steht bei mir schon drin. Die Adresse von
Write-Command ist damit 0x7e oder 0x7a.
Bleibt noch die Frage nach den UC1610 Programming Commandes. Was muss
ich damit übertragen?
Soll nur für das DOG XL160 passen. Im Netz habe ich auch die LIB von Jan
gefunden. Das hat ja die verschiedensten Display drin. Bin gerade beim
durcharbeiten
spess53 schrieb:> Hi>> Also es muß sich wirklich niemand damit beschäftigen:>> Und du meinst das passt für alle Displays?>> MfG Spess
Nein, aber ich hoffte, er würde zu Übungszwecken erst mal mit einem
einfacheren Dabla beginnen, dieses zu verstehen und hätte anhand des
Programmschipsels einen Anhaltspunkt, worum es geht. Dann hätte er den
Transfer machen können und die neu sich selbst beigebrachten Fähigkeiten
auf sein favorisiertes Display anwenden können und hätte die Aufgabe
ohne fremde Hilfe lösen können.
Aber ich glaube, diesen Weg wollte er nicht gehn. Es gibt andere Wege...
Diese GLCD-Datenblätter sind nichts für ungeübte, finde ich. Nur wenn
man mehrere bereits verstanden hat, kann man auf Bekanntem aufbauen und
Lücken im Verständnis schließen.
MfG
