LCD 1602A an Atmega128A will nicht funktionieren

Was hast du denn im Vergleich zum Beispielcode überhaupt geändert? So 
ist die Suche recht aufwändig, da das Programm in Summe gut aussieht.

Die Pins sehen richtig gewählt aus.

Gibt es noch Warnungen, dass F_CPU irgendwo nicht definiert wurde? 
Könnte bedeuten, dass die Delay-Funktion nicht auf die 16MHz angepasst 
wurde.

Auch das Toggeln des E-Pins ist bei 16MHz vielleicht zu schnell. Das LCD 
erkennt den Puls vielleicht nicht.

Es wäre noch auszuprobieren, was passiert, wenn du die Fuse CKDIV8 setzt 
(also statt 16MHz mit 2MHz werkeln lässt).

Kann es sein das Du die OBEREN 4Bit des Ports für die Dataleitungen und 
die UNTEREN für die Steuerleitungen, nutzt?
Soweit ich das gesehen habe, gehen die von Dir benutzten Routinen davon 
aus, das es genau umgekehrt ist!

@Teo Derix

Duch LCDDB = PC4 wird ind er Datenroutine 4-4 = 0 gerechnet und die 4 
Datenbits nicht verschoben. Sie bleinben auf PC4..7

@Oliver

Tools -> Device Programming -> Programmer und Interface auswählen _> 
Apply -> Fuses

Felix A. schrieb:
> Duch LCDDB = PC4 wird ind er Datenroutine 4-4 = 0 gerechnet und die 4
> Datenbits nicht verschoben. Sie bleinben auf PC4..7

Thx.

Oliver schrieb:
> Armin schrieb:
>> Ansonsten haben LCDs hin und wieder Timing-Probleme.
>> Dann das LCD langsamer ansteuern
>
> Takt runter würde ich gerne versuchen.

Brauchst du nicht. Wenn dein µC nicht mit 16Mhz takten würde, würden die 
Pausenzeiten höchstens länger.

Setz mal die Pausenzeiten in der lcd-routines.h rauf. Sagen wir mal auf 
das doppelte.

CKOPT könnte es sein. Damals hieß die noch CKDIV8. Es müsste ein Tooltip 
geben, wenn du mit der Maus drauffährst.

Alternativ unter SUT_CKSEL den RC-Oszillator mit 1 oder 2 MHz auswählen. 
Aber Achtung: nicht verklicken auf externen Takt oder sowas, sonst 
bekommst du wahrscheinlich keinen Zugriff mehr auf das Teil.

Karl H. schrieb:

> Setz mal die Pausenzeiten in der lcd-routines.h rauf. Sagen wir mal auf
> das doppelte.

Der erste kritische ist der hier

1

#define LCD_BOOTUP_MS           15

geh da mal auf zb 50 oder 100

Felix A. schrieb:
> CKOPT könnte es sein. Damals hieß die noch CKDIV8.

Nein.
das eine hat mit dem anderen nichts zu tun

Felix A. schrieb:
> CKOPT könnte es sein. Damals hieß die noch CKDIV8. Es müsste ein Tooltip
> geben, wenn du mit der Maus drauffährst.
>
> Alternativ unter SUT_CKSEL den RC-Oszillator mit 1 oder 2 MHz auswählen.

Lass doch den Quatsch.
Er hat in den Routinen 16Mhz eingetragen.
D.h. der Compiler bemisst alle delays auf einen schnellen Prozessor. 
Sollte der tatsächlich langsamer sein als angegeben, dann werden die 
delays höchstens länger, aber nicht kürzer.

Einfach den Takt runterstellen und dafür F_CPU entsprechend kleiner 
stellen bringt genau gar nichts.

Oliver schrieb:

> Leider bekomme ich weder mit dem auf der Olimex Seite bereitgestellten
> Beispielprogramm

hast du das selbst compiliert oder hast du dir von dort das Hex-File 
geholt und gebrannt?

Ich hatte neulich ein ähnliches Problem, daher habe ich eingangs 
geschrieben, er möfge mal nach Warnungen diesbezüglich schauen. Bitte 
genauer lesen.

Hier im Bild markiert die Einstellung, um den Takt auf 1 MHz zu setzen.

Felix A. schrieb:

> Hier im Bild markiert die Einstellung, um den Takt auf 1 MHz zu setzen.

Was soll das beringen?
15ms sind 15ms

Egal ob er das mit einem realen CPU Takt von 16Mhz und einem F_CPU von 
16Mhz erreicht oder ob er das mit realen 1Mhz und einem F_CPU von 1Mhz 
macht.

Das ändert nur Zahlenwerte, die der Compiler errechnet. Aber in dem 
einen wie im anderen Fall kommen reale 15ms raus.

Deshalb schrieb ich ja, dass diese F_CPU-Konstante vielleicht nicht in 
der delay.h ankommt -> daher bitte beim Compilieren mal nach Warnungen 
schauen.

Das zu verstehen, kann nicht so schwer sein, Herr Karl Heinz

Oliver schrieb:
> Karl H. schrieb:
>> Setz mal die Pausenzeiten in der lcd-routines.h rauf. Sagen wir mal auf
>> das doppelte.
>
> Habe jetzt das 2-4 fache aller Zeiten ausprobiert. Leider keinerlei
> Erfolg.

Blöde Frage:
läuft der µC überhaupt?

Musst du irgendwelche Brücken setzen, um das LCD an den Prozessor zu 
koppeln?

Felix A. schrieb:
> Deshalb schrieb ich ja, dass diese F_CPU-Konstante vielleicht nicht in
> der delay.h ankommt -> daher bitte beim Compilieren mal nach Warnungen
> schauen.

ja, ok. Das ist sinnvoll.
Aber der Rest ist es nicht

Karl H. schrieb:

> ja, ok. Das ist sinnvoll.
> Aber der Rest ist es nicht

Im übrigen würde er da keine Warnung kriegen.

Daher in lcd_routines.h so abändern

1

#ifndef LCD_ROUTINES_H_

2

#define LCD_ROUTINES_H_

3

4

////////////////////////////////////////////////////////////////////////////////

5

// Hier die verwendete Taktfrequenz in Hz eintragen, wichtig!

6

7

// #ifndef F_CPU    <---- Kommentar davor

8

#define F_CPU 16000000UL

9

// #endif           <---- Kommentar davor

10

11

12

....

(der ifndef sollte da überhaupt nicht sein)

Oliver schrieb:
> Karl H. schrieb:
>> hast du das selbst compiliert oder hast du dir von dort das Hex-File
>> geholt und gebrannt
>
> Sowohl als auch. Wenn ich das c file selbst compiliere erhalte ich wirre
> Zeichen auf dem Display. Wenn ich die fertige .elf-Datei direkt brenne,
> läuft es tadellos.

Das ist doch schon mal was!
Oben sagtest du noch, das die Demo nicht läuft.

Wirre Zeichen ist schon mal besser als nichts.

Karl H. schrieb:

>> Sowohl als auch. Wenn ich das c file selbst compiliere

Womit compilierst du?
Atmel Studio?

Hast du den Mega128A am Anfang ausgewählt?

Ansonsten poste mal deine Projektdatei. Da scheint etwas in den 
Einstellungen nicht zu stimmen.

Der TE am Anfang:
> (nur schwarzer Balken).

und 1:30h später:
>Wenn ich das c file selbst compiliere erhalte ich wirre
>Zeichen auf dem Display. Wenn ich die fertige .elf-Datei direkt brenne,
>läuft es tadellos.

Ja was denn nun, wann und wie genau?

Du könntest im gesamten Projekt in allen Dateien mal nach der Konstanten 
F_CPU suchen. Irgendwo muss diese stehen.

Wenn diese nicht zu finden ist, dann F_CPU in deiner lcd_routines.h 
definieren ohne das #ifdef. Gibt es beim Compilieren jetzt Warnungen, 
dass diese doppelt definiert wurde?
Über die fehlermeldung findet sich dann vielleicht der zweite eintrag.

Mit WinAVR wurde die Konstante meiner Erinnerung nach sogar in der IDE 
festgelegt, also nicht im Code. Passiert vielleicht auch im AVR Studio, 
das weiß ich aber nicht. Auf die Schnelle konnte ich das nicht finden.

Wenn diese definiert ist und nicht gefunden werden kann, könnte der 
Standardwert 1MHz drin stehen. In dem Fall müsstest du alle Zeiten 16mal 
so groß machen.

Und deshalb macht das Reduzieren der Taktfrequenz auch Sinn. Das F_CPU 
angepasst werden soll, habe ich nämlich NICHT geschrieben, werter Karl 
Heinz

Ich kann deine Projekt-Datei in meinem Atmel_Studio nicht öffnen. Das 
muss aber nichts heissen. Auf dem Rechner, auf dem ich zur Zeit bin, ist 
eine ziemlich alte Version installiert und ich will da jetzt auch nicht 
updaten.

Ich hab ein neues Projekt gemacht und dein Dateien eingefügt.
Das HEX-File, welches jetzt hier beiliegt, läuft das so wie es soll?

Felix A. schrieb:

> Mit WinAVR wurde die Konstante meiner Erinnerung nach sogar in der IDE
> festgelegt, also nicht im Code. Passiert vielleicht auch im AVR Studio,
> das weiß ich aber nicht. Auf die Schnelle konnte ich das nicht finden.

Es wurde da wie dort nicht defaultmässig eingefügt.
Im alten AVR Studio gab es eine Combo-Box zur Auswahl, wenn man da aber 
bei der Projekt-Generierung nichts unternahm, stand kein Wert drinnen. 
Im neuen Atmel Studio wird kein Preprozessor-Symbol vorbelegt.

>
> Wenn diese definiert ist

Wenn er es nicht gemacht hat, dann ist es nicht vorbelegt.

Das stimmt so nicht, siehe delay.h

1

#ifndef F_CPU

2

/* prevent compiler error by supplying a default */

3

# warning "F_CPU not defined for <util/delay.h>"

4

# define F_CPU 1000000UL

5

#endif

Felix A. schrieb:
> Das stimmt so nicht, siehe delay.h
>

1

> #ifndef F_CPU

2

> /* prevent compiler error by supplying a default */

3

> # warning "F_CPU not defined for <util/delay.h>"

4

> # define F_CPU 1000000UL

5

> #endif

6

>

Schön.
Nur das die #include Reihenfolge lautet

1

#include <avr/io.h>

2

#include "lcd-routines.h"

3

#include <util/delay.h>

das F_CPU aus delay.h kommt nie zum Zug

Es sei denn, es wäre vorher schon definiert. Und das lässt sich gut 
testen, indem F_CPU in der lcd-routines.h definiert und dann compiliert 
wird. Erscheint eine Warnung der Redefinition, kann man hier sicher 
sein.

Es ist leider nunmal so, dass Code, den man nicht komplett geschrieben 
hat, machmal etwas "unpraktisch" ist.

Irgendein Weg muss der TE zum Findes Fehlers nunmal auf sich nehmen. 
Genügend Vorschläge gibt es, diese ausprobieren dauert nicht lange.

Felix A. schrieb:
> Es sei denn, es wäre vorher schon definiert.

Das kann wiederrum nur sein, wenn es in Atmel-Studio bei den vorbelegten 
Präprozessor-Defines angegeben ist.
Da das Atmel Studio keine derartige Vorbelegung macht, müsste er es 
eingefügt haben.

Aber seis drumm. Soll er halt mal den Prozessor auf 1Mhz umstellen, 
damit du beruhigt bist. Erwarten tu ich mir davon nichts.

> Es ist leider nunmal so, dass Code, den man nicht komplett geschrieben
> hat, machmal etwas "unpraktisch" ist.

Er hat den kompletten Code gepostet. Keine Spur von F_CPU ausser im 
lcd_routines.h

Und die delay.h hat er auch selbst geschrieben?

Er greift auf Headerfiles zu, die es gibt, die aber nicht gepostet 
wurden. Diese habe ich selber nicht gelesen. Er wahrscheinlich auch 
nicht. Du denn?

Ist letztendlich egal.

@Oliver

Gibt es mittlerweile neue Erkenntnisse?

Felix
rede ihn da durch, dass er auf 1Mhz umstellt.
Dann soll er testen
Es wird genausowenig funktionieren
Dann soll er wieder auf Quarz zurückfusen.

Damit da endlich mal Ruhe ist und wir uns dem eigentlichen Problem 
widmen können.

Hier prallen zwei Gewalten aufeinander, was den TE wohl eher 
verunsichert.
Ich überlasse euch das Feld.

Ich schaue entweder spät abends nochmal rein oder morgen früh.

Oliver schrieb:
> Karl H. schrieb:
>> Damit da endlich mal Ruhe ist und wir uns dem eigentlichen Problem
>> widmen können.
>
> Gesagt getan. Auf 1MHZ gefuset. Gleiches Ergebnis.
> Also noch kein Fortschritt.

Was ist mit dem Hex-File welches ich gepostet habe?
Hast du das mal probiert?

Oliver schrieb:
> Karl H. schrieb:
>> Ich hab ein neues Projekt gemacht und dein Dateien eingefügt.
>> Das HEX-File, welches jetzt hier beiliegt, läuft das so wie es soll?
>
> Dumme Frage: Wie genau finde ich das heraus? D.h. wie bekomme ich dein
> hex-file in meinen Controller?

?
Du hast doch auch das Olimex-Hex File gebrannt.

Gibt es in deinen Brennprogramm keine Möglichkeit, wo du das zu 
brennende Hex-File auswählen kannst?
(Ich arbeite normal nicht mit dem Atmel Studio, drumm ist das hier alles 
nicht eingerichtet)

Tools -> Device Programming -> Memories

Pfad zur HEX-Datei wählen und "Program" klicken.

Mir kam gerade ein Gedanke, nachdem ich in EIN Displaydatenblatt 
geschaut habe:

1

static void lcd_enable( void )

2

{

3

  LCD_PORT |= (1<<LCD_EN);     // Enable auf 1 setzen

4

  _delay_us( LCD_ENABLE_US );  // kurze Pause

5

  LCD_PORT &= ~(1<<LCD_EN);    // Enable auf 0 setzen

6

}

Da immer zweimal 4 Bits geschrieben werden, könnte die Zweit zwischen 
fallender Flanke und nächster steigender Flanke zu kurz sein.
Ich würde ein delay vor dem "LCD_PORT |= (1<<..." einfügen, probeweise.

Bei diesem Displaydatenblatt steht 800ns lowtime und 800ns Hightime für 
den Takt, der hier per E-Signal gemacht wird.

Felix A. schrieb:

> Da immer zweimal 4 Bits geschrieben werden, könnte die Zweit zwischen
> fallender Flanke und nächster steigender Flanke zu kurz sein.
> Ich würde ein delay vor dem "LCD_PORT |= (1<<..." einfügen, probeweise.

gute Idee. Einen Versuch ist es auf jeden Fall wert.

Hier als Bild.

Ich habe mir nicht jeden einzelnen Beitrag gelesen und daher kann ich 
ganz daneben liegen.
Du hast R/W auf PC1 gelegt, aber nirgendwo definiert auf GND gelegt. 
Also direkt auf GND legen oder den PC1-Ausgang auf low schalten.

1

void lcd_init( void )

2

{

3

  // verwendete Pins auf Ausgang schalten

4

  uint8_t pins = (0x0F << LCD_DB) |           // 4 Datenleitungen

5

  (1<<LCD_RS) |                // R/S Leitung

6

  (1<<LCD_EN);                 // Enable Leitung

7

  LCD_DDR |= pins;

8

9

  // initial alle Ausgänge auf Null

10

  LCD_PORT &= ~pins;

Letzte Zeile.

Diese Thema lässt mich irgendwie nicht los :-(

Oliver schrieb:
> Karl H. schrieb:
>> Was ist mit dem Hex-File welches ich gepostet habe?
>> Hast du das mal probiert?
>
> Ergebnis: Schwarzer Balken...

hmm.
normalerweise würde ich jetzt schön langsam in die Richtung tendieren, 
die Verkabelung noch mal zu kontrollieren. Da du aber sagst, das 
original Hex-File funktioniert ....

Kopfkratz.

Ändere mal dein LCD.c so um

1

#

2

...

3

4

int main(void)

5

{

6

  DDRA = ( 1 << PA6 );

7

  _delay_ms( 500 );

8

  PORTA |= ( 1 << PA5 );

9

  _delay_ms( 500 );

10

  PORTA &= ~( 1 << PA5 );

11

12

  // Initialisierung des LCD

13

  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken

14

  // verschwunden sein

15

  lcd_init();  

16

17

...

das ist jetzt mehr so ein Verzweiflungsschlag. Auf dem Board ist ein 
Relais samt LED verbaut. Nach dem Einschalten solltest du einmalif die 
LED aufblinken sehen und das Relais schalten hören. Aber das darf nur 
ein einziges mal nach dem Programmieren passieren.

Es wird dein Problem nicht lösen. Aber es gibt erst mal Rückmeldung, ob 
das programmieren geklappt hat oder nicht.

Doch, RW fehlt. Hubert hatte recht, glatt übersehen.

Wenn der floatet, könnte das diese Probleme machen.

Felix A. schrieb:
>

1

> void lcd_init( void )

2

> {

3

>   // verwendete Pins auf Ausgang schalten

4

>   uint8_t pins = (0x0F << LCD_DB) |           // 4 Datenleitungen

5

>   (1<<LCD_RS) |                // R/S Leitung

6

>   (1<<LCD_EN);                 // Enable Leitung

7

>   LCD_DDR |= pins;

8

> 

9

>   // initial alle Ausgänge auf Null

10

>   LCD_PORT &= ~pins;

11

>

>
> Letzte Zeile.
>
> Diese Thema lässt mich irgendwie nicht los :-(

Autsch.
Das haben wir alle übersehen.
AUf dem LCD ist die R/W nicht auf GND verkabelt, sondern geht an den 
Prozessor.

Das könnte es wirklich sein!

Schnellschuss zum Testen:

1

void lcd_init( void )

2

{

3

4

  LCD_DDR = 0xFF;

5

  LCD_PORT = 0x00;

6

7

8

...

Hast du den RW-Pin jetzt auch auf low gesetzt?

1

uint8_t pins = (0x0F << LCD_DB) |           // 4 Datenleitungen

2

  (1<<LCD_RS) |                // R/S Leitung

3

  (1<<LCD_RW) |

4

  (1<<LCD_EN);                 // Enable Leitung

5

  LCD_DDR |= pins;

Der muss auch noch in der h-Datei definiert werden.

Oliver schrieb:

> Vielleicht ist der Fehler bei dem von Olimex bereitgestellten Code
> einfacher zu identifizieren. Hier erhalte ich ja immerhin schon wirre
> Zeichen auf dem Display.

Der entscheidende Unterschied dürfte wirklich sein, dass der Olimex Code 
am PortC alle 7 LCD Leitungen auf Ausgang und 0 setzt.

Dass der nur wirre Zeichen bringt, das kann jetzt an vielem liegen. 
Unter andermm daran

1

void Delay(unsigned int a)

2

{

3

  while (a) 

4

  {

5

    a--;

6

  }

7

}

das ist ziemlicher Müll. Damit hat man kein reproduzierbares Timing.

-> so, wie Felix das sagt: Erweitere um den R/W Pin. Aber schreib dir 
einen Kommentar dazu, dass der Pin nicht benutzt wird!

Oliver schrieb:
> Karl H. schrieb:
>> Das könnte es wirklich sein!
>
> Das wars. Vielen vielen Dank an alle Beteiligten.

Hubert gebührt die Ehre