DOG-M 162 will nichts anzeigen

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.

> 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?

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.

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.

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?

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:

1

#define PIN_E   PD5

2

#define PIN_RS  PD4

3

4

5

...

6

7

void lcd_enab(void) {

8

  PORTD |= ( 1 << PIN_E );

9

  _delay_us(100);

10

  PORTD &= ~( 1 << PIN_E );

11

}

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.

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.

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.

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.

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

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

1

void lcd_goto_xy(uint8_t x, uint8_t y) {

2

#if 0

3

  PORTD |= y | 0x08; 

4

  lcd_enab();

5

  PORTD |= x; 

6

  lcd_enab();  

7

#else

8

#define LCD_SET_DDADR   0x80

9

#define LCD_DDADR_LINE1 0x00

10

#define LCD_DDADR_LINE2 0x40

11

12

    uint8_t data;

13

14

    switch (y)

15

    {

16

        case 1:    // 1. Zeile

17

            data = LCD_SET_DDADR + LCD_DDADR_LINE1 + x;

18

            break;

19

20

        case 2:    // 2. Zeile

21

            data = LCD_SET_DDADR + LCD_DDADR_LINE2 + x;

22

            break;

23

24

        default:

25

            return;                                   // für den Fall einer falschen Zeile

26

    }

27

28

  PORTD |= (data>>4);

29

  lcd_enab();

30

  PORTD |= (data&0x0F);

31

  lcd_enab();

32

#endif

33

}

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

1

void lcd_enab(void) {

2

  PORTD |= (1<<LCD_E);

3

  _delay_us(100);

4

  PORTD &= ~(1<<LCD_E); // fallende Flanke => Datenübernahme

5

  _delay_us(100); // Mindestlänge im Datenblatt nachsehen und anpassen

6

  PORTD &= ~LCD_PINS;

7

}

Und der schwarze Balken blieb nach wie vor fern?

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