ATmega8 + LCD-Probleme

[Boon (Gast)]

Als ob die schon vorhandenen Threats nicht ausreichen würden -.-

Auf jeden Fall: Problem mit der Darstellung auf einem HD44780-bestückten 
LCD im Verbund mit ATmega8. Verwendet wird der Header lcd-routines.h.
Poti ist korrekt angeschlossen, Alle Kästchen können von komlett aus bis 
sehr gut erkennbar manipuliert werden.
Gearbeitet wird mit PORTD, PD0...PD3 für die oberen Datenbits. PD5 für 
RS, PD6 für EN.
Zusätzlich ist ein kleiner Resistor für die Hintergrundbeleuchtung 
integriert.
Problem: Kann keine Zeichen darstellen - absolut nichts zu sehen!

#define F_CPU 8000000
#include <avr/io.h>
#include "lcd-routines.h"



int main(void)
{
  
  lcd_init();          // Initialisierung des LCD
  lcd_clear();        // LCD löschen
  
  lcd_home();    
  
  lcd_string("Hallo Welt");
  
  lcd_setcursor( 1, 2 );    //  2te Zeile, 1.Zeichen setzen
  
  lcd_string("Test");
  

return 0;
}

die .c-Datei in Makefile implementiert, die Zugriffszeiten sind mit dem 
Datenblatt verglichen. Das LC-Display ist erst vor Kurzem gekauft 
worden...

Irgendwer irgendwelche Ideen?

[g457 (Gast)]

> Irgendwer irgendwelche Ideen?

Ja. Wo ist der Rest vom Quellcode? Wie sieht der Aufbau aus?

[Boon (Gast)]

Der Rest in den angehängten ofiziellen Bibliotheken für LCD.

Die Beschaltung ist oben genannt.

[Christian B. (chbalnuweit)]

ich konnte so auf anhieb nix fehlerhafte erkennen.
Ich vermute den Fehler woanders.
Wird sauber kompiliert?
Wie sehen die Fusebits aus?
Lass mal eine LED mit 1 Hz toggeln und guck ob das delay_ms() richtig 
arbeitet.

Gruß,
Christian

[Chris (Gast)]

Boon schrieb:
> return 0;


Das sollte da besser nicht stehen ;)
mein() darf nicht verlassen werden, sonst treibt dein µC irgendwas.
Möglicherweise rennt er durch den leeren Speicherbereich und fängt 
main() wieder von vorne an --> Display wird dauernd gelöscht so dass man 
nichts erkennt.

Versuchs mal so:

int main(void)
{

  lcd_init();          // Initialisierung des LCD
  lcd_clear();        // LCD löschen

  lcd_home();

  lcd_string("Hallo Welt");

  lcd_setcursor( 1, 2 );    //  2te Zeile, 1.Zeichen setzen

  lcd_string("Test");

while(1)    // Endlosschleife wird nie verlassen
{
    ;
}

}

[Oliver (Gast)]

Chris schrieb:
> Das sollte da besser nicht stehen ;)
> mein() darf nicht verlassen werden, sonst treibt dein µC irgendwas.

Das ist zwar richtig, das "irgendwas" ist aber bei einer einigermassen 
aktuellen avr-gcc/avr-libc-Kombination als Endlosschleife implementiert.

Oliver

[Hubert G. (hubertg)]

Du hast sicher ein Hardwareproblem. Die Software habe ich 
vorsichtshalber getestet, funktioniert einwandfrei.
Hast du R/W auf GND gelegt?

[Boon (Gast)]

Du hast sicher ein Hardwareproblem. Die Software habe ich 
vorsichtshalber getestet, funktioniert einwandfrei.
Hast du R/W auf GND gelegt?

R/W auf GND gelegt, sowie die ersten Datenbits des LCD.

Wird sauber kompiliert?
Wie sehen die Fusebits aus?
Lass mal eine LED mit 1 Hz toggeln und guck ob das delay_ms() richtig 
arbeitet.

Ich bekomme nicht einmal eine Warnung. Das delay funktioniert tadellos - 
habe beim LCD aber auch schon 1,8 MHz int und 16MHzext. ausprobiert.
Die FuseBits...sidn im Ursprungszustand - für den extenen Quarz ändere 
ich die eben inkl. des CKOPT.

[Boon (Gast)]

Edit: @Chris: deinen Code habe ich ausprobiert - leider ohne Erfolg.

[Boon (Gast)]

Edit2: Wenn ich die ersten Datenbits nicht auf Masse lege, bekomme ich 
ein Paar falsch dargestellter Zeichen zu sehen. Kann ich in diesem Fall 
davon ausgehen, dass das LCD funktioniert?

[Hubert G. (hubertg)]

Kannst du ein Bild von deinem Aufbau hier hereinstellen. Es kann nur was 
hardwaremässiges sein wenn der Code richtig kompiliert und übertragen 
wird.
Das der µC oder LCD defekt sind, ist doch eher unwahrscheinlich, wenn 
auch nicht auszuschließen.
Die ersten Datebits braucht man nicht auf GND legen, es sind intern 
PullUp drinnen.

[Dietrich L. (dietrichl)]

@Boon
Hast Du in lcd-routines.h auch die richtige Taktfrequenz eingetragen?

Siehe bei

#define F_CPU 8000000

[Boon (Gast)]

Hast Du in lcd-routines.h auch die richtige Taktfrequenz eingetragen?

Jup, alles aktualisiert. Aber wenn nicht - ist das in der .c-Datei 
geschehen. Dann gibt es eine Warnung, funktionieren tut es aber 
trotzdem.

Anbei ein Foto vom Aufbau - das LCD ist jetzt mal auf max.Kontrast 
eingestellt, um die weißen Kästchen zu sehen - selbstverständlich zu für 
das Foto.

Ich gehe davon aus, dass es irgendein dumemr Fehler ist, da alle 
"klugen" bereits behoben sind :D

[Hubert G. (hubertg)]

Recht viel erkennt man auf dem Bild nicht.
Ist auf dem Controllerboard ein MAX232 oder dergleichen drauf und RX und 
TX nicht abgetrennt. Das könnte stören.

[Boon (Gast)]

Recht viel erkennt man auf dem Bild nicht.
Ist auf dem Controllerboard ein MAX232 oder dergleichen drauf und RX und 
TX nicht abgetrennt. Das könnte stören.

OMFG, das war der Gedanke! Abtrennen muss man den Quatsch nicht - aber 
zumindest die richtige Abzweigung vom Port nutzen. Auf dem Board ist 
eine hinter den MAX232 geschaltet und eine davor. Ratet mal, welche ich 
angesteckt habe ;)

Ich danke euch allen, habt 'nen schönen Tag :)

[Peter D. (peda)]

Boon schrieb:
> Abtrennen muss man den Quatsch nicht

Warum nicht, ist denn ein Schutzwiderstand in Reihe?
Ansonsten muß der arme MAX gegen den AVR kämpfen.
Könnte sein, er nimmt es bald übel.

[Boon (Gast)]

dem TxD-Eingang wird nichts passieren - er wird eben irgendein Signal 
ausgeben. Natürlich Vorsicht geboten, wenn man die RS232-Schnittstelle 
nutzen möchte.
Beim RxD müsste ich diese..ähm.. reverse supply nachschauen - aber danke 
für die Warnung :)

[Hubert G. (hubertg)]

Auf der RS232 (PC) Seite des MAX sind am TX +-12V drauf, da ist dein LCD 
auch ganz schnell hinüber.

[Boon (Gast)]

Wie es aussieht, hat mein LCD doch noh überlebt :D
Aber ehrlich, einfach solche dummen Fehler... Schon an alles gedacht, 
Zugriffszeiten, Beschaltung, Widerstände, Code... Und dann liegt es an 
dem falschen( aber gleichgenannten) Port ;)