Hallo ich hab gesehen, dass es inzwischen auch ein Grafikdisplay der DOG serie gibt. Hat da schon jemand erfahrung gemacht oder gar schon eine library zu? http://www.lcd-module.de/deu/dog/dog.htm Gruß Frank
Ich habe schon seit einigen Wochen solch ein Teil hier zum experimentieren. Die Ansteuerung per SPI ist recht einfach, ein paar Pixel habe ich schon aktivieren können. Was mir auch jetzt fehlt, sind die passenden Grafikroutinen. Da man den Speicher des Displays nicht auslesen kann, muß man hier sicher mit einem Shadow-RAM (1 kByte) im Speicher des Controllers arbeiten. Erwin
Weiss jemand, ob die 132x32 in die Sockel der alphanumerischen Versionen passen, also identische Abmessungen und Pinbelegungen haben?
@Diego Wenn Du das DIP122x-5 Modul meinst, dann passt dieses auch auf den Sockel der Text-Module mit 2x 9poligen Steckverbinder, z.B. DIP-204x-4. Auch die Anschlüsse sind kompatibel, DIP-122x-5 Modul hat jedoch noch einen 2. Enable-Anschluß, welcher bei den Text-Module frei bleibt. Matthias
@Matthias Nein, ich meine selbstverständlich die Module der DOG-Reihe z.B. eDOG162, siehe Link des Posters. Hab's aber bereits befunden, die Teile haben dieselben Abmessungen, aber sind leider NICHT pinkompatibel. Also leider nicht variabel einsetzbar, ein Kombi-Layout für beide Versionen macht wenig Sinn.
Hallo, gibts was neues ? Hat jemand schon was aus dem Display heraus gelockt ? Bei mir liegen die beiden Dinger (128 und 132) rum und ich weiß momentan nichts damit anzufangen. Gibts schon irgendwelche Libraries oder Routinen ? Thomas
Bei mir ist ein 128x64 in einem Breadboard am Laufen. Wie schon weiter oben erwähnt, muss man einen Display-Buffer im µC vorhalten, weil man nur schreibend aufs Display zugreifen kann, deshalb ist meine Wahl auf den Mega-32 gefallen. Bin momentan dabei, eine kleine Grafik-Library zusammenzubasteln, ist nichts weltbewegendes, sobald man einen "plot" zusammen hat...
Hallo, ich hab ein 132er hier in Verbindung mit einem ARM Cortex-M3 am laufen über SPI. Klappt super und sieht gut aus. Bei Bedarf kann ich den Quelltext (in C) posten (der bedarf aber noch überarbeitung). Ich hab ein paar GLCD Libs von Atmel portiert und etwas erweitert. Grüße
Hallo, ich hab nun auch ein DOGM132, aber so wirklich hab ich es noch nicht zum Laufen bekommen. Kann jemand eine funktionstüchtige Initialisierung in C posten? Das würde mir bestimmt weiterhelfen. Danke
Genau so sieht es bei mir auch aus. Ich finde das ziemlich fies, dass man nicht vom Display lesen kann, nicht mal den Status, so weiß ich nicht einmal wo das Problem liegt. Vielleicht nur eine kleine Leitung falsch? Man weiß es leider nicht... Aber wenn ich mir wenigstens beim Code sicher sein könnte, wäre das schon mal ein Fortschritt! Meine Initialisierung: ------------------------------------------------------------------------ Reset HIGH 200ms warten Reset LOW ------------------------------------------------------------------------ spi_master_send_char(0x40); // Display start line 0 spi_master_send_char(0xA1); // ADC reverse spi_master_send_char(0xC0); // Normal COM0~COM63 spi_master_send_char(0xA6); // Display normal spi_master_send_char(0xA2); // Set bias 1/9 (Duty 1/65) spi_master_send_char(0x2F); // Booster, Regulator and Follower on spi_master_send_char(0xF8); // Set internal Booster to 4x spi_master_send_char(0x00); spi_master_send_char(0x27); // Contrast set spi_master_send_char(0x81); spi_master_send_char(0x16); spi_master_send_char(0xAC); // No indicator spi_master_send_char(0x00); spi_master_send_char(0xAF); // Display on ------------------------------------------------------------------------ Die spi_master_send_char(unsigned char) sieht so aus: void spi_master_send_char (unsigned char c) { SPDR = c; // sende Zeichen while (!(SPSR & (1<<SPIF))) // warten bis Senden moeglich { } _delay_us(100); } (vorher natürlich spi init) ------------------------------------------------------------------------ Den A0-Pin habe ich mal dauerhaft auf LOW, da man zur initialisierung keine Displaydaten benötigt. Um zu testen, ob meine Initialisierung klappt, habe ich mit dem 4. Befehl rumgespielt: 0xA6 soll alle Pixel ausschalten, 0xA5 alle an (wohl für invertierten Modus gedacht) Ist meine Initialisierung so OK? Die ist aus dem Datenblatt ("Single Supply") aber laut anderen Usern hier im Forum nimmt EA das nicht so genau mit den Beispielen (bei z.B. 2x16-Displays oder so hat das angeblich nicht 100% gestimmt...) Also der µC sendet irgendwas (eine Test-LED blitzt auf), das weiß ich, mehr weiß ich aber nicht, hab leider kein Oszi. Kann mir / uns jemand weiterhelfen? Grüße, Sebastian
Ich bin am verzweifeln! In einer Woche muss mein Display laufen, ich brauche das für ein Projekt... Ich hab einen Fehler in meiner Initialisierung gefunden und zwar hab ich aus Versehen die Invertierung des RESET-Pins nicht beachtet. Muss also erst LOW, dann HIGH sein. Wenn jemand irgend eine Idee hat, bitte sofort melden. Ich stehe unter Zeitdruck... Man findet im Internet wirklich fast gar nix zu diesem Display. Ich komme mir irgendwie verar***t vor... Grüße, Sebastian
Sebastian wrote: > Wenn jemand irgend eine Idee hat, bitte sofort melden. Ich stehe unter > Zeitdruck... Wer tut das nicht. Ausschnitt aus meiner Code für das Modul zur Initialisierung über SPI (Prinzip für Parallel identisch):
1 | void lcd_contrast_intern( uint8_t contrast ) |
2 | {
|
3 | /* "electronic volume" */
|
4 | lcd_spi_write( ST7565R_ELECTRONIC_VOLUME_MODE_SET ); |
5 | lcd_spi_write( ST7565R_ELECTRONIC_VOLUME_REGISTER_SET | ( contrast & 0x3F ) ); |
6 | }
|
7 | |
8 | void lcd_init( uint8_t options ) |
9 | {
|
10 | /* init according to the EA DOGM datasheet
|
11 | with additions from the ST7565R datasheet */
|
12 | |
13 | // Reset module (hardware)
|
14 | lcd_hw_reset( 1 ); |
15 | // Wait time power stabilize
|
16 | delay_ms( 50 ); |
17 | // Release reset
|
18 | lcd_hw_reset( 0 ); |
19 | // wait reset-circuit finished
|
20 | delay_10usec(); |
21 | |
22 | lcd_cs_select(); |
23 | lcd_rs_command(); |
24 | |
25 | // Display start line 0
|
26 | lcd_spi_write( ST7565R_DISPLAY_START_LINE | 0); |
27 | #ifdef EA_DOGM_TOPVIEW
|
28 | // ADC set normal
|
29 | lcd_spi_write( ST7565R_ADC_SELECT_NORMAL ); |
30 | // Common output mode normal COM63-COM0
|
31 | lcd_spi_write( ST7565R_COMMON_OUTPUT_MODE_REVESE | 0 ); |
32 | #else /* bottom view */ |
33 | // ADC set reverse
|
34 | lcd_spi_write( ST7565R_ADC_SELECT_REVERSE ); |
35 | // Common output mode normal COM0-COM63
|
36 | lcd_spi_write( ST7565R_COMMON_OUTPUT_MODE_NORMAL | 0 ); |
37 | #endif /* EA_DOGM_TOPVIEW */ |
38 | // Display normal
|
39 | lcd_spi_write( ST7565R_DISPLAY_NORMAL ); |
40 | // Set bias 1/9
|
41 | lcd_spi_write( ST7565R_LCD_BIAS_SET_1_9 ); |
42 | |
43 | #ifdef EA_DOGM_SINGLE_SUPPLY
|
44 | // booster, regulator, follower on
|
45 | lcd_spi_write( ST7565R_POWER_CONTROL_SET | |
46 | ST7565R_BOOSTER_MASK | ST7565R_REGULATOR_MASK | |
47 | ST7565R_FOLLOWER_MASK ); |
48 | // internal booster to 4x
|
49 | lcd_spi_write( ST7565R_BOOSTER_RADIO_SET ); |
50 | lcd_spi_write( ST7565R_BOOSTER_STEP_UP_2x3x4x ); |
51 | #else /* dual - untested */ |
52 | // booster off, regulator and follower on
|
53 | lcd_spi_write( ST7565R_POWER_CONTROL_SET | |
54 | ST7565R_REGULATOR_MASK | ST7565R_FOLLOWER_MASK ); |
55 | #endif
|
56 | |
57 | // "contrast set"
|
58 | // V0 resistor-ratio (see table 11, here 6.5 -> 0b111 = 0x07)
|
59 | lcd_spi_write( ST7565R_V0_VOLTAGE_REG_INT_RES_RAT_SET | 0x07 ); |
60 | |
61 | // Electronic volume
|
62 | lcd_contrast_intern( LCD_CONTRAST_DEFAULT ); |
63 | |
64 | // static indicator off
|
65 | lcd_spi_write( ST7565R_STATIC_INDICATOR_OFF ); |
66 | lcd_spi_write( ST7565R_STATIC_INDICATOR_REGISTER_OFF ); |
67 | // display on
|
68 | lcd_spi_write( ST7565R_DISPLAY_ON ); |
69 | |
70 | lcd_rs_data(); |
71 | lcd_cs_unselect(); |
72 | }
|
Die Werte der verwendeten "Konstanten" STR7565* entsprechen denen im Datenblatt des Controllers. > Man findet im Internet wirklich fast gar nix zu diesem > Display. Ich komme mir irgendwie verar***t vor... Gibt's eigentlich keinen Grund zu, nur weil zur Zeit vielleicht noch niemand fertig vorgekaute Routinen für Controller XY gratis bereitstellt. Das Datenblatt von Electronic-Assembly für Beschaltung und Initialisierungsbeispiel zusammen mit dem Datenblatt des ST7565R für Timing und weitere Initialisierungsmöglichkeiten reichen schon, um das Display zum "Leben" zu erwecken. Na ja, zumindest habe ich nichts vermisst (http://www.siwawi.arubi.uni-kl.de/avr_projects/glcd2/index.html unten) Hoffe, es hilft Martin Thomas
Hallo, ah ja, es tut sich was. Hat jemand das Ding auch schon mit BASCOM zum Laufen gebracht ? Ich kann leider kein ASM oder C :( Thomas
Martin, du bist genial! :D Danke für deinen Initialisierungscode, der anscheinend nicht nur mir half... Ich weiß zwar nicht was ich jetzt wirklich anders gemacht habe, aber mein DOGM scheint sich auf magische Weise initialisiert zu haben. :) Ich habe jetzt, wenn ich nach dem Initialisieren A0 auf HIGH setze, ein Standbild mit zufälligen Pixeln, wohl einfach ein zufälliger RAM-Inhalt. Immerhin! Jetzt habe ich aber noch einen kleinen Anschlag auf dich vor: Ich möchte nicht, dass jetzt der Eindruck entsteht dass ich andere für mich arbeiten lasse (du siehtst ja auch dass ich mich bemüht habe; der Code oben ist ja meiner), aber ich möchte einfach nur nichts falsch machen! Wenn das Display jetzt kaputt gehen würde wäre ich im Eimer :( weil das ganze ne Projektarbeit ist und bis übernächste Woche fertig sein muss. (Das Projekt ist ansonsten fast fertig, nur bisher läuft die Grafikausgabe über ein "virtuelles Display" am PC) Also wärst du jetzt mein Gott, wenn du mir nur noch eine Funktion posten könntest, um das Display-RAM einmal komplett zu schreiben. Sprich: Ich habe meine 1024 Bytes im RAM vom µC und möchte dieses Frame senden. Ich bin mir nur unsicher mit den Befehlen zum Starten & Beenden eines Frames und wie ich den Zeiger automatisch inkrementieren kann... das wäre es ja dann quasi auch schon. Desweiteren habe ich keinen Überblick über das Timing bzw wann es eine Rolle spielt. Ich muss gestehen, dass ich noch nie mit einem Grafikdisplay gearbeitet habe. Und nochmals vielen vielen Dank für deine Bemühungen!! Ich weiß das sehr zu schätzen. Grüße, Sebastian
Ok, ich hab mich jetzt doch getraut :) Folgender Code setzt alle Pixel. (als Beispiel) Es hat funktioniert, aber kann man das so lassen oder sollte man noch irgendetwas verändern? PB3 ist bei mir A0, ich habe (noch) keine so tollen Funktionen/Makros geschrieben :) ------------------------------------------------------------------------ uint8_t page; uint8_t column; for (page = 0; page < 8; page++) { //SPI: DISPLAY DATA PORTB &= ~(1<<PB3); // A0 = LOW (SPI: Command) spi_master_send_char(0xB0 + page); //Set page address to <page> spi_master_send_char(0x10 + 0); //Set column address to 0 (4 MSBs) spi_master_send_char(0x00 + 0); //Set column address to 0 (4 LSBs) //SPI: DISPLAY DATA PORTB |= (1<<PB3); // A0 = HIGH (SPI: Display Data) for (column = 0; column < 128; column++) spi_master_send_char(0xFF); //Set all pixels } ------------------------------------------------------------------------ Grüße, Sebastian
Juhu! Ich habs! :) Und damit ich nicht der einzige glückliche bin, hier mein Code. Ich hoffe jemand kann was damit anfangen. Ich freue mich über Feedback. ( Bitte nicht verwirren lassen durch komische Kommentare in den Quelltexten, da ich da ständig hin und her kopiert und immer wieder gelöscht und auskommentiert habe... Außerdem könnten noch ein paar kleine Schönheitsfehler drin sein... ) In der ZIP-Datei im Anhang befinden sich folgende Dateien: - driver_dogm128.h: Displayfunktionen, die die SPI-Master-Funktionen "spi_master_init()" und "spi_master_send_char()" voraussetzt. - graphics.h: Grafikfunktionen (zwar wenige aber für das meiste ausreichend): einzelne Pixel, Linien, Rechtecke und Text zeichnen (sogar variable Zeichenbreite :) ) - font.h: die Schriftart für "graphics.h" (wird im Flash gespeichert), Sonderzeichen wie Umlaute siehe Kommentare in dieser Datei. Erläuterungen: Im µC werden 1024 Bytes RAM für den Displayinhalt reserviert. (daher (meines Wissens nach) erst ab ATmega32 mit 2KB RAM möglich!) Alle Grafikfunktionen "zeichnen" in diesen RAM-Bereich. Benutzt wird das ganze so, dass einfach "graphics.h" eingebunden wird (der Displaytreiber wird von graphics.h selbst eingebunden) und mittels "g_init()" (SPI muss zuvor initialisiert sein) das Display initialisiert und dessen Displayinhalt gelöscht wird. Ein Frame wird mit "g_end_frame()" abgeschlossen, d.h. dann wird der RAM-Inhalt vom µC zum Display übertragen. Möchte man den RAM-Inhalt löschen, so ruft man "g_clear()" auf, diese sendet den leeren Displayinhalt sofort an das Display. Möchte man dies nicht, sondern möchte gleich wieder ein Frame zeichnen (ohne dass zwischendurch das Display selbst geleert wird), so verwendet man "g_clear_dont_refresh()". Alle anderen graphics-Funktionen erklären sich von selbst: g_draw_pixel(x, y); (Pixel aktivieren) g_clear_pixel(x, y); (Pixel deaktivieren) g_draw_line_h(x, y, length); (horizontale Linie) g_draw_line_v(x, y, length); (vertikale Linie) g_draw_rect(x, y, w, h); (Rechteckrahmen) g_fill_rect(x, y, w, h); (gefülltes Rechteck) g_draw_string(x, y, *s, trans); (Text, trans gibt an, ob der Hintergrund transparent sein soll (0 = alle Pixel beachten, 1 = nur Pixel setzen)) Die Variable "g_inverted" invertiert, falls sie 1 ist, alle Grafikbefehle, um z.b. weißen Text auf schwarzem Hintergrund zu schreiben, weiße Linien zu malen, usw. Nicht vergessen: in "driver_dogm128.h" sind natürlich die Präprozessor-Definitionen für die I/O-Ports A0 und RESET anzupassen. Verwendet man mehrere SPI-Slaves, so muss man noch Code für das Slave Select einfügen (in "dogm_send()"). Sollte jemand Fehler entdecken oder Verbesserungsvorschläge haben, oder sonst ein Feedback geben möchte, bitte posten. Danke! Viel Spaß! Grüße, Sebastian
Sieht doch schon ganz gut aus. Die Aufteilung des Codes in ".h" und ".c"-Dateien wäre ordentlicher. Funktioniert zwar so aber wird spätestens dann Probleme verursachen, wenn man die glcd-Routinen aus Funktionen ansprechen will, die über mehrere Quellcodedateien verteilt sind.
Reichen bei diesem Display Widerstände zur Pegelanpassung aus (5V -> 3.3V)?
Hallo Allerseits! Ich beschäftige mich seit Kurzem auch mit diesem Display. Hab mir mal das Zip-File angeschaut, jedenfalls hätte ich eine Frage dazu. In font.h sind ja die Schriftarten definiert, eine Zahl dort entspricht ja den gesetzten Pixel, vertikal gesehen. Ich habe vor einiger Zeit ein Programm gefunden, welches Schriftarten sowie BMP's in einen C-Code umwandelt. Jedenfalls wurde das Programm für ein Display mit dem T69693-Controller geschrieben. Kann es also sein, dass das DOGM128... die Daten vertikal braucht und das Teil mit dem T6963 horizontal? Das also mein Konvertierungsprog nicht für das DOGM brauchbar ist?
Hallo, hat einer das Ding auch schon mit BASCOM zum Laufen gebracht ? Verstehe leider von C nicht so viel :( Thomas
@ Philipp Putzer: Ob die Daten brauchbar sind, die du hast, hängt von deinen implementierten Grafikfunktionen ab. Ich habe meine komplett selbst geschrieben und mich an keine "Standards" gehalten. Bei Schriftarten macht es aufgrund von variablen Breiten und konstanten Höhen Sinn, diese in "Spalten" zu je 8 Pixeln Höhe zu speichern. Bitmaps speichere ich übrigens horizontal, ähnlich wie auch Windows-BMP's im 1-Bit-Modus gespeichert sind. So sieht meine Funktion zum Zeichnen von Bitmaps aus: void g_draw_bitmap_from_flash(uint8_t _x, uint8_t _y, uint16_t addr) { uint8_t w = pgm_read_byte(addr++); //width uint8_t h = pgm_read_byte(addr++); //height uint8_t s = pgm_read_byte(addr++); //scanlength uint8_t p; //position in data row (in bytes) uint8_t x; //x position of current pixel relative to _x uint8_t y; //y position of current pixel relative to _y uint8_t d; //read data for (y = 0; y < h; y++) { for (p = 0; p < s; p++) { d = pgm_read_byte(addr + (uint16_t)s*(uint16_t)y + (uint16_t)p); for (x = p*8; x < p*8+8 && x < w; x++) { if (d & 1<<(x-p*8)) g_draw_pixel(x+_x, y+_y); else g_clear_pixel(x+_x, y+_y); } } } } Ein "Bitmap" baut sich folgendermaßen auf: const uint8_t bitmap_beispiel[] PROGMEM = { // HEADER: // image width 24, // image height 8, // scanlength (in bytes): 3, // DATA (1 bit = 1 pixel): /* Hier folgen die Bitmapdaten mit 1 Byte je 8 Pixeln in Reihe. Das LSB ist der linke der 8 Pixel, das MSB der rechte. Die Breite wird auf volle 8 Pixel gerundet und eine Zeile hat soviel Bytes, wie bei <scanlength> eingestellt, die exakte Breite lässt sich dennoch bei <image width> einstellen. Die Zeilen werden sequentiell von oben nach unten gespeichert (im Gegensatz zu Windows-BMP's). Maximale Bitmapgröße: 256x256 Pixel. */ };
Dietmar E wrote: > Reichen bei diesem Display Widerstände zur Pegelanpassung aus (5V -> > 3.3V)? Wenn du einen Spannungsteiler bastelst, ja. (Auch für alle input Pins) Das Display zieht soweit ich weiß deutlich unter 1mA
@Sebastian Habe deine Funktion für die Darstellung eines bmps probiert, bekomme ein recht lustiges Ergebnis! Ich sehe zwar mein bmp, nur sind einzelne Buchstaben/Bildbereiche spiegelverkehrt, bzw bö, naja komisch. Das bmp habe ich mit zwei verschiedenen Programmen konvertiert, beides Mal das Selbe Ergebnis. Habe mein Bildchen Mal angehängt. Die ersten drei Werte habe ich zusätlich eingefügt, also 128px breit, 64px hoch und scanlenght 16. Aufrufen tue ich das ganze so: g_draw_bitmap_from_flash(0, 0, Test_bitmap); Vielen Dank nochmals!
Hi, ich würde mir auch gerne das DOGM128-Display kaufen. Aber da BASCOM anscheinend das Modul so nicht unterstützt, müsste man selber die Routinen einfügen. Hat jemand einen Tip wie das anzustellen wäre? Wie werden denn die ".lbx" erzeugt? Grüße Alex
Läuft seit einiger Zeit auch mit dem Parallax Propeller, was aber sicherlich nicht jeden interessiert.. War aber eigentlich nicht so schwer... (3 Stunden, weil ein Denkfehler dabei :-) )
Hallo. Hat noch niemand die Dinger mit BASCOM zum Laufen gebracht ? Thomas
22,60 ist ganz schön teuer für so ein kleines LCD, oder ? Natürlich nichts im Vergleich zu den viermal so großen und teuren 240x128 T6963C. Aber wieso nicht Handydisplays nehmen? Wegen sicherer Bezugsquelle?
> 22,60 ist ganz schön teuer für so ein kleines LCD
Und das ist nur der Preis ohne Beleuchtung. Die weisse Beleuchtung
kostet noch mal 20,10 EUR.
Ich hab mir das Display nur geholt weil ich dafür ein Touchfeld passend bekomme! Wenn ich natürlich ein Handydisplay irgendwoher ekomm a la iphone-display oder das große vom nokia communicator, wäre genial! Zumindest benötige ich ein Touchfeld! Und ich möchte die ganze Bild-funktionen nutzen die schon bascom bietet!
Hallo, es gibt was Neues. BASCOM 1.11.9.1 unterstützt jetzt angeblich diesen Displaytyp. Habs selbst noch nicht ausprobiert, denke aber das es funktionieren wird. Thomas
und??? ich bin verzweifel daran das DOGM128x64 ans laufen zu bekommen. hier bascom 1.11.9.2 im einsatz... ausserdem möchte ich den Controller KS0108 ans laufen bekommen...
raimund wrote: > und??? ich bin verzweifel daran das DOGM128x64 ans laufen zu bekommen. > hier bascom 1.11.9.2 im einsatz... > ausserdem möchte ich den Controller KS0108 ans laufen bekommen... --- unter BASCOM 1.11.9.3 läuft es zu mindest im text-modus
Das kann ich bestätigen, der Text Modus funktioniert, aber mehr nicht. Kann vielleicht jemand den oben angegebenen C-Code auf Bascom umstricken? ich blicke da noch nicht so richtig durch.
Servus, ich bin derzeit daran das Display auf meiner von mir entorfenen Extension-Platine einzubinden. Ich betreibe es grundlegend an einem mit 5V betriebenen AVR ohne SPI (Ports direkt, der AVR soll nur Peripherie und Display treiben, SPI habe ich für die Kopplung zu den anderen AVR's). Ist hier irgend ein Anhaltspunkt als Spannungsteiler? Habe das im im Routing in der Hitze des Gefechts total verpatzt, muß ich wohl vorerst per SMD nachrüsten. Das Display an sich wird über einen 3,3V-Regler von der 5V-Versorgung abgeleitet. Denke wenn ich dort mit 5V vom AVR an das DOGM128S gehe, wird es geschädigt werden. Ich habe das Projekt einmal online gelegt, dort sind die Schaltungen verfügbar. http://wiesolator.de/data/topics/Robotik/ACU-Cube/Board%20C/_downloads/ACU-Cube_C.zip An alle BASCOM-User (da ich es hier sehe), ich will das Grundprogramm in BASCOM entwerfen mit den Basisfunktionen, welche die Display-Ansteuerung an üblichen Pins des AVR's ermöglicht. Allerdings soll es primär nur zu Diagnose-Zwecken dienen. Also ein paar Linien, Balken, Texte zeigen können, nichts wirklich weltbewegendes. Grüße Wolfgang
Hallo Leute, hab jetzt auch so ein schönes Display, nur: Wie muss ich den SPI einstellen (für Sebastians Routine)??? Also, welchen wert muss ich in SPCR (ATMega32) schreiben, damit mich das Display versteht? Ach ja, es hat nicht zufällig jemand die Touchfolie ausprobiert? Ich meine, brauch ich zusätzlich noch irgendwelche Treiber etc.? Oder direkt wie in der App. Note 341 ? Vielen Dank, Michael EDIT: Ich arbeite mit C!
Hallo Michael, Ich zeige dir den Lösungsweg, ich sage dir aber nicht die Lösung. Du nimmst dir das Datenblatt des Display(http://www.lcd-module.de/pdf/grafik/dogm128.pdf) gehst auf die Seite 5 unten das Bild. Dann schau in des Datenblatt des Atmega32 auf Seite 139 die 2 Bilder an. Und vergleiche diese 3 Bilder und du wirst die Lösung haben. Gruß marco
Hi, danke für den Tipp, habs jetzt hingekriegt. Es hat auch einen Abend lang ganz gut getan. Hab jetzt aber ein neues Problem: Hab n bissle was an meiner Schaltung geändert (nichts, was direkt mit dem Display zu tun hätte), und seitdem ist der Schirm komplett schwarz (hab das grün/schwarze), wenn ich es einschalte. Wenns aus ist, ist es so grünlich, und an dann eben schwarz. Ich benutze die Routinen von Sebastian. Also, an der SPI kanns eigentlich nicht liegen, da das Display ja eingeschaltet wird (was nicht von alleine geschieht). Ich habe den Kontrast in Verdacht, ich hab aber leider keinen Plan welchen Wert in der Init-Routine ich wie (in welche Richtung, größer/kleiner) ich verändern muss. Was sagt ihr dazu? Vielen Dank, Michael
Zwar ASM, aber vielleicht kannst Du´s Dir ableiten:
1 | ;-------------------------------------------------------------- |
2 | EA_DOG_INIT: |
3 | sbi VPORT2_Out, DispReset |
4 | cbi VPORT2_Out, DispComDat |
5 | |
6 | ldi Temp, $40 ;Display Start Line |
7 | rcall EA_DOG_Write |
8 | |
9 | ldi Temp, $A1 ;ADC reverse |
10 | rcall EA_DOG_Write |
11 | |
12 | ldi Temp, $C0 ;Commen Output normal |
13 | rcall EA_DOG_Write |
14 | |
15 | ldi Temp, $A6 ;Display normal $A6, reverse $A7 |
16 | rcall EA_DOG_Write |
17 | |
18 | ldi Temp, $A2 ;Bias 1/9 |
19 | rcall EA_DOG_Write |
20 | |
21 | ldi Temp, $2F ;Booster, Regulator, Follower on |
22 | rcall EA_DOG_Write |
23 | |
24 | ldi Temp, $F8 ;Set Booster |
25 | rcall EA_DOG_Write |
26 | |
27 | ldi Temp, $00 ;x4 |
28 | rcall EA_DOG_Write |
29 | |
30 | ldi Temp, $27 ;Voltage Resistor ratio 23 EA_DogM132-5 / 27 EA_DogM128-6 |
31 | rcall EA_DOG_Write |
32 | |
33 | ldi Temp, $81 ;Set Contrast |
34 | rcall EA_DOG_Write |
35 | |
36 | ldi Temp, $16 ;Value $00...$63 |
37 | rcall EA_DOG_Write |
38 | |
39 | ldi Temp, $AC ;Static indicator $AC off / $AD on |
40 | rcall EA_DOG_Write |
41 | |
42 | ldi Temp, $00 ;00 no flashing / 01 flashing |
43 | rcall EA_DOG_Write |
44 | |
45 | ldi Temp, $AF ;$AF Display on / $AE off |
46 | rcall EA_DOG_Write |
47 | ret |
Danke, ich hab mal ein Paar Werte für den Kontrast ausprobiert (über den gesamten angegebenen Bereich), aber es hat sich nie etwas verändert. das ganze kommt mir etwas komisch vor. Michael
Wie sind die Spannungen am LCD, welche Schaltung aus dem Datenblatt hast Du benutzt?
Spannungen hab ich nachgemessen, VCC 3,3V, Vout 11,??V Die Obere (Single Supply). Ich habs auch noch mal mit einem anderen Display probiert, da kann man ganz schwach den Text erkennen (ich hab in Blinken lassen). Also die SPI-Übertragung an sich ist nicht das Problem. Hab schon mit Invertiert und alle Pixel an und so probiert, entweder es bleibt ganz leer oder es ist eben ganz schwarz. Danke für deine Hilfe, Michael
Bist Du mal die Werte in der Init durchgegangen, die ich geschickt habe? Und poste mal die Schaltung!
Die Werte bei mir sind aus dem Datenblatt, es sind exakt dieselben, die du hast. Die Schaltung ist auch die aus dem Datenblatt. Was mir inzwischen aufgefallen ist: Wenn ich die Schaltung einschalte, kann ich kurz den Text lesen, dann ist sofort alles schwarz. Sieht man aber nicht immer. Du hast nicht zufällig ein Hex-file für einen ATMega32, das irgendeinen Text oder so darstellen lässt? Nur damit ich weiß, ob ich bei der HW suchen muss, oder obs an meiner Software liegt. Michael
Hi ich bin neu in der Microcontroller welt und muss für ein schul projekt ein EA DOGM132-5 Grafik Display (132*32) programieren ich hab ein 1.4 RN-Controllerboard von robotikhardware mit einem mega32 währe echt froh wenn mir jemand sagen könnte an welchen pins ich des Display anschließen muss und viel mehr wie ich die pins in Bascom definiere danke
> ich bin neu in der Microcontroller welt ...
Wäre es nicht sinnvoller, erstmal ein Projekt "deutsche Rechtschreibung
und Grammatik" in dieser Schule zu machen?
Da kommt einem ja die Weihnachtsgans wieder hoch....
Hi >Wäre es nicht sinnvoller, erstmal ein Projekt "deutsche Rechtschreibung >und Grammatik" in dieser Schule zu machen? >Da kommt einem ja die Weihnachtsgans wieder hoch.... Volle Zustimmung. Aber die Ernüchterung kommt spätestens dann, wenn er merkt, das ein Compiler/Assembler sehr nachtragend auf solche Nachlässigkeiten reagiert. MfG Spess
Hallo! Ich hab eine Frage und zwar hab ich zwar nicht genau das selbe Display jedoch den selben Controllerbaustein und ich hab hier oben gelesen das Sebastian die Ausgabe über ein virtuelles Display am PC gemacht hat und wollte wissen wo ich sowas finde?? Muss ebenfalls mein Projekt machen und unbedingt programmieren, jedoch habe ich einen Fehler in der Schaltung, muss aber unbedingt programmieren bis ich die Schaltung neu machen kann und mir würde deswegen so win virtuelles Display zum testen sehr entgegenkommen!!! Bitte um rasche Hilfe!!! Danke
Hallo, zwar schon eine weile her.. aber was ist denn nun aus dem kontrastarmen Display geworden? Habe gerade exakt das gleiche Problem.. oder weis jemand was bei diesem Fehler einzustellen ist? Also verschiedene Kontrastwerte bringen keine Lösung... Mfg Tobi
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.