DOG-M 162 will nichts anzeigen

[Michael (Gast)]

Hallo,

ich habe mit dem Display DOG-M 16x2 Zeichen so meine Probleme. Habe nun 
schon viel gesucht und hier ist auch viel zu finden, aber vieles eben 
nur zum Anschluss mit SPI.

Ich betreibe das Display an einem Atmega8 mit 5V über 4 Bit.

Angeschlossen ist es dabei wie folgt:

PDO = D7
PD1 = D6
PD2 = D5
PD3 = D4
PD4 = RS
PD5 = E



Zuerst habe ich probiert die init selber zu schreiben aber das wollte 
auch nicht so recht. Dann habe ich hier im Forum eine Codeschnipsel 
gefunden und diese zusammengefügt. Leider zeigt mir das Display nichts 
an! :(

Ich weiß das Programm ist sicherlich nicht hübsch, aber ich möchte auch 
erst einmal nur sehen ob das Display etwas anzeigt und mein Aufbau etc 
alles richtig ist. Mehrfach durchgemessen und überprüft habe ich alles 
aber man weiß ja nie...


Was ich auch im Datenblatt nicht verstehe ist, wie der Contrast 
eingestellt werden kann. Eventuell liegt es bei mir auch daran?!

Wäre dankbar für jeden Ratschlag und HIlfe.

Ich habe mal das Projekt angehangen.


mfg Michael

[Michael (Gast)]

achso, das Display ist wie nach dem beiliegenden Plan verdrahtet.

[Mike J. (emjey)]

Sobald du es mit 5V versorgt hast (genau 5V nicht weniger sonst geht das 
Display nicht an)

Sobald es mit 5V versorgt wurde siehst du einen schwarzen Balken und 
erst dann kannst du das Display mit dem ATmega8 initialisieren.

[Spess53 (Gast)]

Hi

>void lcd_enab(void) {
>  PORTD |= 0x10;
>  _delay_us(100);
>  PORTD = 0x00;
>}

Die Daten werden mit der fallenden Flanke von E übernommen. Du löscht 
aber zum gleichen Zeitpunkt die Datenleitungen.

Außerdem weiß ich nicht so richtig, wo du die Initialisierungswerte her 
hast.

MfG Spess

[PaulMichael (Gast)]

Also ich habe genau 5 V an den benötigten Pin`s anliegen. 
(Konstantspannungsquelle) Davon wird auch der Atmega gespeist.

Wie gesagt den Code habe ich hier aus dem Forum (Dieser Beitrag recht 
weit untern: http://embdev.net/topic/126291#new)


Einen schwarzen Balken sehe ich jedoch nicht? Habe aber auch gelesen das 
man bei dem Display mit dem Controller nur ein leeres LCD vorfindet!

[Stefan B. (stefan)]

> PDO = D7
> PD1 = D6
> PD2 = D5
> PD3 = D4
> PD4 = RS
> PD5 = E

Das ist aber sehr ungeschickt, weil du dann per Software die 
Datenleitungen umknoten musst. Üblicher ist auf jeden Fall

PD3 = D7
PD2 = D6
PD1 = D5
PD0 = D4
PD4 = RS
PD5 = E

RW hast du auf GND gelegt?

[Michael (Gast)]

dann löte ich die fix um oder ist das mit ein paar Zeilen getan die in 
der Software zu drehen?

Ja RW ist auf GND

[Michael (Gast)]

hat sich nichts geändert nach dem umlöten..Display bleibt noch immer 
leer :(

[Mike J. (emjey)]

PaulMichael schrieb:
> Einen schwarzen Balken sehe ich jedoch nicht? Habe aber auch gelesen das
> man bei dem Display mit dem Controller nur ein leeres LCD vorfindet!

Habe auch solche Displays verbaut und man sieht einen schwarzen Balken!

Also wenn du den nicht siehst brauchst du nicht mit initialisieren 
anzufangen.

[Michael (Gast)]

Aber sicher das es auch bei den invertierten zutrift?! Da müsste es ja 
genau anders herum sein?!

Ich habe noch mal nachgemessen, ich habe es exakt so verkabelt wie es 
auf der Internetseite des Herstellers beschrieben ist :(

[Stefan B. (stefan)]

Mit dem geänderten Pinout habe ich Chancen deinen Sourcecode auf meinem 
Testboard laufen zu lassen. Aber heute nicht mehr, ist schon zu spät.

Bei einem inversen LCD sollte nach meiner Spekulation (habe kein 
inverses) über die Funktionsweise (Polarisation) statt schwarzer Balken 
helle Balken sichtbar sein.

[Michael (Gast)]

Hallo Stefan,

das wäre super, dann komme ich vielleicht irgendwie weiter!

Oder hat jemand vielleicht eine routine für den Atmega8 mit 4 Bit, damit 
ich testen kann?!

[Stefan B. (stefan)]

So, habe jetzt deine Beschreibung der Schaltung mit dem Quellcode 
verglichen:

> PD4 = RS
> PD5 = E

Passt auch nicht zum Quellcode.

> void lcd_enab(void) {
>   PORTD |= 0x10;
>   _delay_us(100);
>   PORTD = 0x00;
> }

E wird mit 0x10 geschaltet, also PD4 = E

> void lcd_putc(char c) {
>   PORTD |= ((c>>4) | 0x40);
>   lcd_enab();
>   PORTD |= ((c&0x0F) | 0x40);
>   lcd_enab();
> }

RS wird mit 0x40 geschaltet also PD6 = RS

Steht aber auch beides so in http://embdev.net/topic/126291#1154285 und 
dem Folgepost mit der Umverdrahtung von PORTC nach PORTD.

Dem Hinweis in http://embdev.net/topic/126291#1154251 auf PSB bist du 
mit dem Datenblatt des Displays 
(http://www.lcd-module.de/eng/pdf/doma/dog-me.pdf) nachgegangen?

[Karl H. (kbuchegg)]

Stefan B. schrieb:

...
> E wird mit 0x10 geschaltet, also PD4 = E
...
> RS wird mit 0x40 geschaltet also PD6 = RS

UNd nur so als Hinweis an den TO.
Beide Fehler hätten sich ganz leicht vermeiden lassen, wenn man den 
üblichen C Gepflogenheiten folgt und keine magischen Konstanten direkt 
in den Code schreibt.

Du schrubst weiter oben

> Angeschlossen ist es dabei wie folgt:
>
> PDO = D7
> PD1 = D6
> PD2 = D5
> PD3 = D4
> PD4 = RS
> PD5 = E

Ergo:

#define PIN_E   PD5
#define PIN_RS  PD4


...

void lcd_enab(void) {
  PORTD |= ( 1 << PIN_E );
  _delay_us(100);
  PORTD &= ~( 1 << PIN_E );
}

für RS dann genau dasselbe in grün in der anderen Funktion.
Das bischen Mehrarbeit gleich von Anfang an, lohnt sich allemal. Und von 
der besseren Lesbarkeit und Verständlichkeit der lcd_enab Funktion reden 
wir erst mal gar nicht.

[Stefan B. (stefan)]

Der Vollständigkeit halber:

Der vom TO oben gepostete Code ist für

PD3 = D7
PD2 = D6
PD1 = D5
PD0 = D4
PD6 = RS  <===
PD4 = E   <===

Der TO hat derzeit gelötet (1x umgelötet)

PD3 = D7
PD2 = D6
PD1 = D5
PD0 = D4
PD4 = RS
PD5 = E

Die (begrüßenswerte) Änderung des Codes mit Makros von Karl-Heinz kann 
mit der derzeitigen Verkabelung betrieben werden. Der Originalcode des 
TO nicht.

[Michael (Gast)]

Hallo,
ich danke euch für die schnellen und informativen Antworten!

Das mit dem PSB(23) habe ich befolgt und der liegt auf High.
Ebenso die 24,25,26,32,33,34,35 und 40

Auf Low liegt 27,37,38.

Ich habe jetzt die Anmerkungen noch mal in den Code eingepflegt aber es 
tut sich noch immer nichts :( Das Display bleibt komplett leer!



Ich hänge das aktuelle Projekt nochmal an. Ich kann mir nicht wirklich 
vorstellen, dass das Display defekt ist?!

Kann den Code im Anhang jemand testen und sagen ob er bei sich 
funktioniert und "hello" auf dem LCD erscheint?!

vielen dank

[Stefan B. (stefan)]

Der v2 Code kann nicht funktionieren. Offentsichtlichster Fehler ist

> void lcd_putc(char c) {
>   PORTD |= ( 1 << PIN_RS );
>   _delay_us(100);
>   PORTD &= ~( 1 << PIN_RS );
> }

Da ist überhaupt keine Anweisung zur Ausgabe des Zeichens c vorhanden!

Den Rest habe ich nicht kontrolliert, weil deine Änderungen nicht so ins 
Auge springen.

[Stefan B. (stefan)]

Dann habe ich die Änderungen nach Vorschlag von Karl-Heinz in der v1 
Source selbst gemacht (siehe Anhang).

Der Lauftest mit meinem LCD (kein EA DOGM! sondern ein Data Vision 
DV20208 von Pollin zeigt ein "test" auf der Ausgabe.

Ich habe allerdings ein Board mit 1 MHz intern benutzt (den AVR 
Transitortester aus der Codesammlung) und die fix eingestellten 4 MHz 
aus der lcd.h auskommentiert. Die 4 MHz in der lcd.h passen bei deiner 
Hardware?

Die weiteren Änderungen sind:

1. Nur die Pins manipulieren, die für 4-Bit LCD nötig sind. Auf meinem 
Board ist noch andere Hardware, deshalb kein pauschales Manipulieren 
aller Pins an PORTD

2. Zu Beginn der lcd_init nach dem Hochfahren _delay_ms(200) warten 
bevor das LCD angesprochen wird.

[Stefan B. (stefan)]

3. Änderung noch die lcd_goto_xy() für mein LCD...

Der Code ist der lcd_setcursor() aus 
AVR-GCC-Tutorial/LCD-Ansteuerung entnommen.

void lcd_goto_xy(uint8_t x, uint8_t y) {
#if 0
  PORTD |= y | 0x08; 
  lcd_enab();
  PORTD |= x; 
  lcd_enab();  
#else
#define LCD_SET_DDADR   0x80
#define LCD_DDADR_LINE1 0x00
#define LCD_DDADR_LINE2 0x40

    uint8_t data;
 
    switch (y)
    {
        case 1:    // 1. Zeile
            data = LCD_SET_DDADR + LCD_DDADR_LINE1 + x;
            break;
 
        case 2:    // 2. Zeile
            data = LCD_SET_DDADR + LCD_DDADR_LINE2 + x;
            break;
 
        default:
            return;                                   // für den Fall einer falschen Zeile
    }

  PORTD |= (data>>4);
  lcd_enab();
  PORTD |= (data&0x0F);
  lcd_enab();
#endif
}

[Stefan B. (stefan)]

Spess53 schrieb:

>>void lcd_enab(void) {
>>  PORTD |= 0x10;
>>  _delay_us(100);
>>  PORTD = 0x00;
>>}
>
> Die Daten werden mit der fallenden Flanke von E übernommen. Du löscht
> aber zum gleichen Zeitpunkt die Datenleitungen.

Stimmt, überraschenderweise funktioniert das (bei F_CPU 1 MHz. je 
schneller desto kritischer...). Sauber programmieren sollte man das aber 
z.B. so

void lcd_enab(void) {
  PORTD |= (1<<LCD_E);
  _delay_us(100);
  PORTD &= ~(1<<LCD_E); // fallende Flanke => Datenübernahme
  _delay_us(100); // Mindestlänge im Datenblatt nachsehen und anpassen
  PORTD &= ~LCD_PINS;
}

[Michael (Gast)]

oh wow es geht :) tausend dank :) bei mir erscheint ein test auf dem 
Bildschirm!

Da fällt mir ein Stein vom Herzen!

Vielen dank für die Mühen :)

[Sesk K. (zeborok)]

Und der schwarze Balken blieb nach wie vor fern?

[Sesk K. (zeborok)]

Ich kann es mittlerweile selbst bestätigen: Es gibt, jedenfalls wohl bei 
den neueren, keinen schwarzen Balken!