C Display EA DOG XL 160

achim S.

Mitglied
16. Jan. 2010
704
13
18
Berlin Biesdorf
Sprachen
  1. ANSI C
Hallo Gemeinde
such in verschiedenen Foren nach dem Display DOG XL160 von EA. Ist ein Display (Graphik) mit dem I2C Bus und wird mit 3,3V betrieben. Habe verschiedene Codes und Anleitungen für SPI gefunden. Da ich es aber mit I2C ansteuere passt das nicht. Leider scheint kaum jemand mit dem Bus zu arbeiten. Da ich verschiedene Displays von EA kenne und nutze, müsste es doch möglich sein. Leider ist die Beschreibung beim Hersteller sehr kurz geraten. Es wird der IC UC1610 verwendet.
Kann mir jemand helfen das Teil zu verstehen?
Die Hardware läuft korrekt, kann die Adresse 0x7e und 0x7a auslesen. Beim Rest gibt es noch grosse Proleme.

achim
 
Hallo Achim,

wenn du bereits ein SPI-Beispiel für die Initialisierung der Register für das LCD hast, solltest du diese eigentlich einfach für I2C verwenden können.

(Mit dem Display kenne ich mich nicht aus und das Datenblatt habe ich nur überflogen)

Zuerst sendest du ein Kommando SYSTEM RESET, danach die einzelnen Register initialisieren. Danach Daten in das Grafikram schreiben.

upload_2018-7-8_7-8-56.png

upload_2018-7-8_7-16-18.png



upload_2018-7-8_7-27-18.png
 
Hallo Dirk
genau dort fängt mein Problem an. Habe danach schon einiges geschrieben. Das init klappt aber nicht. Dann hat das Teil ja 2 Adressen und 2 Leseadressen, sind aber scheinbar anders. Ist denn beim SPI auch so ein init drin wie beim I2C Bus?
achim
 
Bei deinem Display ist die I2C Adresse abhängig vom logischen Zustand des Pin A2. Du kannst somit zwei Displays am selben Bus betreiben.
Bei dem EA Datenblatt ist ja beschrieben, welche Adressen in Abhängigkeit von A2 verwendet werden, und zwar das komplette Byte (mit I2C Adresse + A3 + A2+ C/D, R/W)

Der LCD Controller hat noch einen weiteren Adresspin A3, der ist aber bei dem LCD immer auf high.

Ich gehe davon aus, dass Register und deren Initialisierung unabhängig non der Hardwareschnittstelle sind. Du hast ja Codes und Anleitungen für SPI gefunden, da ist sicherlich auch eine Initialisierung vorhanden.
 
Hallo Gemeinde
bin immer noch an dem Display dran. Habe das init in den Griff bekommen. Leider fehlen noch alle Sachen zum schreiben oder Löschen. Habe mal geschaut wie es andere machen. Andere ist stark übertrieben. Es scheint nichts zu geben was mit dem i2C Bus läuft.
Das init und die ersten Daten zum Display:


CodeBox C
void wahl_display()
     {
        #define LCD_COL_ADDRESS_LSB   0x00  // 4: column address
        #define LCD_COL_ADDRESS_MSB   0x10  // 4: column address
        #define LCD_TEMP_COMP         0x24  // 5: Set Temperature Compensation
        #define LCD_PANEL_LOAD        0x28  // 6: Set Panel loading
        #define LCD_PUMP_CTRL         0x2C  // 7: Set pump control
        #define LCD_POWER_LOW_VOLTAGE 0x2B  // 7: Power controll set
        #define LCD_ADV_PROG_CTRL     0x30  // 8: advanced program control first word
        #define LCD_START_LINE        0x40  // 9: display scroll line set LSB
        #define LCD_START_LINE2       0x50  // 9: display scroll line set MSB
        #define LCD_PAGE_ADDRESS      0x60  // 10: Page address set
        #define LCD_VOLTAGE_BIAS      0x81  // 11: Bias set
        #define LCD_PARTIAL_CTRL      0x84  // 12: Set partial display control
        #define LCD_RAM_ADDR_CTRL     0x88  // 13: Set RAM address control
        #define LCD_FIXED_LINES       0x90  // 14: Set display fixed lines
        #define LCD_LINE_RATE         0xA0  // 15: Set line rate
        #define LCD_ALL_PIXEL         0xA4  // 16: show all points
        #define LCD_DISPLAY_POSITIV   0xA6  // 17: display positiv  ist neu
        #define LCD_DISPLAY_INVERTED  0xA7  // 17: display invertiert  ist neu
        #define LCD_DISPLAY_ON        0xAF  // 18: Display on   ist neu
        #define LCD_DISPLAY_OFF       0xAE  // 18: Display off  ist neu
        #define LCD_MAPPING_CTRL_6    0xC0  // 19: LCD mapping control 6:00
        #define LCD_MAPPING_CTRL_12   0xC6  // 19: LCD mapping control verdreht um 180°
        #define LCD_GRAY_SHADE        0xD0  // 20: LCD gray shade
        #define LCD_RESET_CMD         0xE2  // 21: System reset
        #define LCD_NO_OP             0xE3  // 22: NOP
        #define LCD_BIAS_RATIO        0xE8  // 24: Bias Ratio
        #define LCD_CURSOR_MODE_RESET 0xEE  // 25: Reset cursor update mode
        #define LCD_CURSOR_MODE_SET   0xEF  // 26: Set cursor update mode
        #define LCD_COM_END           0xF1  // 27: Set COM End
        #define LCD_PARTIAL_START     0xF2  // 28: Set partial display start
        #define LCD_PARTIAL_END       0xF3  // 29: Set partial display end
        #define LCD_WINDOW_START_COL  0xF4  // 30: Window program start column
        #define LCD_WINDOW_START_PAGE 0xF5  // 31: Window program start column
        #define LCD_WINDOW_END_COL    0xF6  // 32: Window program start column
        #define LCD_WINDOW_END_PAGE   0xF7  // 33: Window program start column
        #define LCD_WINDOW_PROGRAM    0xF8  // 34: Enable window programming
       
         #define LCD_WIDTH            160   // Breite LCD
         #define LCD_HEIGHT           104   // Höhe LCD
         #define LCD_RAM_PAGES        26       // size of LCD RAM
         #define LCD_PIXEL_PER_BYTE   4       // using double pixels
         #define LCD_DOUBLE_PIXEL     1
         #define SHIFT_ADDR_NORMAL    0       // column offset for normal orientation
         #define SHIFT_ADDR_TOPVIEW   0       // column offset for bottom view orientation   
     }

void lcd_init()
     {
         i2c_start(Write_Command);               // set device address and write mode
         i2c_write(LCD_COM_END);                        // Set last COM electrode to 103  F1  
         i2c_write(0x67);                        // number of COM electrodes - 1   67  
         i2c_write(LCD_MAPPING_CTRL_6);            // SEG (column) and COM (row) normal   C0   
         i2c_write(LCD_START_LINE);                        // Set Display Startline to 0   40   
         i2c_write(LCD_START_LINE2);                        // Set Display Startline to 0   50   
         i2c_write(LCD_POWER_LOW_VOLTAGE);                        // Set Panelloading to 28..38nF   2B  
         i2c_write(0xEB);                        // Set Bias to 1/12   EB   
         i2c_write(LCD_VOLTAGE_BIAS);                        // Set Contrast   81  
         i2c_write(0x5F);                        // Set Contrast   5F 
         i2c_write(0x89);                        // Set Auto-Increment     89   
         i2c_write(LCD_DISPLAY_ON);                        // Display on    AF   
         i2c_stop();                             // set stop bus
     }

vielleicht kann mir jemand dabei helfen

achim
 
Versuche das Display zu löschen (Inhalt). Dazu muss ich den Speicher mit 0 beschreiben. Bisher habe ich so versucht. Leider ohne Erfolg.


CodeBox C
void lcd_clear_all()
     {
         
       int16_t Page;
       //int8_t Col;  
       //#define Page
       //#define Col   
       for(Page=0; Page<=16640; Page ++)
         {
           //for(Col=0; Col<=159; Col++)
            {
              i2c_start(Write_Command);  
              //i2c_write(0x78);
              i2c_write(0x00);
              //i2c_write(0x60 | Page);
              //i2c_write((Col & 0x0F));           // LSB
              //i2c_write(((Col >> 4) | 0x10));    // MSB
               i2c_stop();   
            //I2C_Write(0x7A);
            //I2C_Write(0xCC);
            }
         }
     }

Was nicht funktioniert (vielleicht habe ich auskommentiert. Das Display hat 160 x 104
Hat jemand eine Idee dazu?
achim
 
Hallo Achim,

leider konnte bisher niemand helfen. :(

Bist du inzwischen weiter gekommen, benötigtst du noch Tipps oder Hilfe?

Dirk :ciao:
 
Hallo Dirk
danke für deine Frage
komme sehr langsam vorwärts. Habe oben bereist einige Teile vom Code eingetragen. Damit kann ich das Display init machen, auch der Invers Betrieb geht. Kann das Display löschen. Löschen ist wohl zu viel gesagt. überschreibe den Speicher mit 0x00. Damit kann ich aber nur alles löschen und keine Teile. Mit dem Invers kann ich vielleicht was darstellen. Habe die Datein von Jan gefunden. Es macht es mit SPI. Er unterschied ist aber grösser dabei als ich dachte. Bin dabei seine Sachen zu verstehen. Ist nicht so leicht das er z.B. für verschiedene Displays es macht.
Da mit kann ich löschen, normal oder invers, aber alles.


CodeBox C
void lcd_clear()    //  Das bedeutet 160 Spalten x 26 Spalten (1 Spalte hat 4 Pixel).
     {
        uint8_t i, j;
        for(j=0; j<LCD_HEIGHT; j++)
        //for(j=0; j<26; j++)       //26
          {
           for(i=0; i<LCD_WIDTH; i++)
           //for(i=0; i<160; i++)       //160
             {
               i2c_start(Write_Command);   
               //i2c_write(LCD_DISPLAY_INVERTED);
               i2c_write(0x00+j);   //0x00 +j
               i2c_write(0x00+i);   //0x00 +i
               i2c_stop();
             }
          }
     }


achim
 
Hallo Achim,

eigentlich sollte es vom Prinzip ähnlich wie bei SPI funktionieren. Im Moment habe ich nicht so die Zeit, ich schau mir das aber am Wochenende mal näher an. Der Beispielcode mit SPI von Jan ist für dieses Display geeignet und du möchtest es nur über I2C ansteuern?

Dirk :ciao:
 
Hallo Dirk
so ist es. EA produziert die verschiedensten Displays und haben dabei verschiedene Möglichkeiten zur Ansteuerung. Das wichtigste für mich ist allerdings die Schnelligkeit. Habe ja bereits verschiedene Displays von EA angesteuert. Sie sind wirklich sehr schnell. Denke z.B. an die Farbdisplays von 3,2 Zoll. Da muss sich Chinamann ganz schän anstrengen. Leider gibt es nicht sehr viele Beispiele für die Ansteuerung. Das habe ich bereits für einige geändet. Bei diesem Display will es aber nicht so klappen. Ausser den Beispielen von Jan habe ich kaum was gefunden. Hänge seine Datein mit ran. Kannst ja mal vergleichen. Er hat es für verschiedne Displays gemacht. Möchte es nur mit I2C ansteuern.

achim
 

Anhänge

  • dogm-graphic.c
    13,3 KB · Aufrufe: 2
  • dogm-graphic.h
    25,4 KB · Aufrufe: 1
Mit Schnelligkeit meine ich nicht den Bus ansich, sondern die Anwendung. Das Farbdisplay hat z.B. eine Verzögerung von 6 Mikrosekunden (TFT 3,2 Zoll bei I2C Bus von 100kHz). Habe mitlerweile viele Anwendungen zum Bus gebaut und Programme erstellt. Wenn der SPI so gut ist, dann kannst du mir sicher einen Tip geben wie ich 1024 LEDs ansteuern kann. Dabei sollen alle LEDs mit verschieden Zeiten geschaltet werden oder als Matrix eine Laufschrift bilden mit links oder rechts oder von oben oder von unten laufen. Geht das überhaupt mit SPI?
achim
 
Du vergleichst Äpfel mit Birnen. Ein TFT-Display mit einem sogenannten »intelligenten« Controller ist was ganz anderes als ein einfaches LCD, bei dem man jeden Punkt »von Hand« setzen oder löschen muß.

Beim TFT-Display kann man über I2C mit wenigen Bytes komplexe Grafiken zeichnen lassen, wohingegen man beim LCD die Grafik vorher berechnet und in Form von vielen Bytes an das Display schickt. Das dauert mit I2C viel länger als mit SPI. Das TFT ist wegen der eingebauten »Intelligenz« von sich aus schneller.

Für eine 32 x 32 LED-Matrix brauchst Du entweder 64 Transistoren oder entsprechend 8 ICs mit je 8 Treiberausgängen. (Vorausgesetzt, Du meinst eine einfarbige LED-Matrix und nicht was ganz anderes.(Wenn es nicht genauer spezifiziert ist, nehme ich immer den einfachsten Fall an.)) Es gibt viele Möglichkeiten, das Ganze anzusteuern. Vielleicht gibt es auch schon intelligente Treiber, die man mit I2C oder SPI ansteuern kann, da bin ich nicht so auf dem Laufenden.

Bei 20 mA für Standard-LEDs brauchst Du für 1024 Stück schon über 20 Ampere, wenn alle an sind.
Wenn Du multiplexen willst, bräuchtest Du, um die gleiche Helligkeit zu erreichen, für ein 32stel der Zeit den 32fachen Strom, was die LEDs nicht aushalten würden.
Man könnt das also in 4 Matrizen zu je 32 x 8 LEDs aufteilen, dann braucht man für ein 8tel der Zeit nur noch den 8fachen Strom. Bei 160 mA pro LED müßten dann die Spaltentransistoren ca. 5 A schalten können.
Aber ich spinne hier bloß rum, ich weiß ja noch nicht mal was Du bauen willst…

µ
 
Wenn der SPI so gut ist
Wenn ich mich recht erinner, kann ein AVR die I²C-Clock maximal auf ein sechzehntel des Systemtaktes setzen. Beim SPI wäre es der halbe Systemtakt.
Als etwa der angedeutete Faktor 10.
In der Theorie - SPI verwendet unidirektionale Signalleitungen mit Push-Pull-Ausgängen, beim I²C sinds bidirektionale Leitungen, folglich muß die Leitung (üblicherweise über einen passiven Widerstand) auf den rezessiven High-Pegel gezogen werden. Je höher die Frequenz, desto steiler müssen die Flanken sein. Desto stärker wirken sich aber auch induktive und/oder kapazitiver Leitungswiderstand aus. Der Widerstand kann aber auch nicht beliebig klen werden, da jeder Teilnehmer die Leitung ja Low ziehen können muß.

Hinzu kommt beim I²C noch mehr protokollarischer Overhead - SPI nutzt seperate Leitungen für beide Datenrichtungen, beim I²C wird die Richtung der einen Datenleitung zu Begin eines jeden Telegramms neu festgelegt (bzw nach jedem repeated Start). Außerdem nach jedem Byte ein (N)ACK-Bit. Zusammen mit der Datenrichtung die Slave Adressierung.

Dafür hast Du beim I²C eben auch nur die beiden Leitungen (und Gnd). Beim SPI wären es drei (und Gnd) sowie eine /CS pro anzusteuernden Slave.

Noch schneller wäre ein paralleler Bus (nochmal etwa Faktor 10), aber natürlich nochmal deutlich mehr Strippen...

Die Frage ist eher, wie schnell der Slave selbst ist, und ggf welche(s) Bussystem(e) in der eigentlichen Applikation bereits genutzt wird(werden)/genutzt werden soll(en). Mit welchen Prioritäten und wievielen Slaves...
Vielleicht gibt es auch schon intelligente Treiber, die man mit I2C
Ich hab hier in meinem Datenblatt-Archiv (=recht alt) den PCA9634, den TLC59108. Inwiefern Dirks Holtek (ht16K33v110) individuelles Dimming unterstützt, weiß ich grad nicht.
Wie's bei SPI aussieht, hab ich nicht gesucht. WS2811 (?) vielleicht oder gleich die LEDs wo der IC mit drin ist. Da gabs AFAIR auch 'ne 2te Serie zu...
 
etwa der angedeutete Faktor 10
Auf Faktoren über 100 kommt man, wenn man annimmt, daß I2C mit 100 kHz läuft und die Hälfte davon nochmal für's Protokoll draufgeht und SPI-Empfänger nicht selten mit Frequenzen von 12 oder mehr MHz angesteuert werden können (und die Xmegas können SPI mit 16 MHz, wenn ich mich recht erinnere).
Es gibt auch I2C-Empfänger,die ein oder mehrere MHz können, dafür muß der Pullup dann aber gegen 1 kOhm gehen. Geht auch, wenn man keinen Strom sparen will (oder muß), dann bleibt der Faktor immer noch bei 10...
WS2811 (?) vielleicht oder gleich die LEDs wo der IC mit drin ist.
Die, die ich kenne haben alle ein sehr eigenes Protokoll, das nichts mit SPI oder I2C zu tun hat...
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)