LCD-Ansteuerung

[ren (Gast)]

Hallo,
ich habe Probleme bei der Ansteuerung eines LCD.
LCD-Controller: SED1278F
ATMEGA16
Schalte ich den uc ein, so werden beide Zeilen komplett ausgefüllt.
Die Hardware habe ich schon x-mal überprüft.

Hier der Code:


#include <avr/io.h>
#include <util/delay.h>
#define F_CPU 16000000

void enable(void);
void init(void);


int main (void) {


    DDRC=0XFF;
    DDRA=0XFF;
    DDRB=0XFF;

    init();

    PORTA |= (1<<PA0);
    PORTC='T';
    enable();
    PORTC='E';
    enable();
    PORTC='S';
    enable();
    PORTC='T';
    enable();

    while(1) {
    }

}

void init(void){

    PORTA &= ~(1<<PA0);
    PORTA &= ~(1<<PA1);
    PORTC=0x3C;
    enable();
    PORTC=0x3C;
    enable();
    PORTC=0x3C;
    enable();
    PORTC=0xF;
    enable();
    PORTC=0x03;
    enable();
    PORTC=0x01;
    enable();
    }


void enable(void){

    PORTA |= (1<<PA2);
    _delay_us(1);
    PORTA &= ~(1<<PA2);
    _delay_ms(5);
    }

[Stefan B. (stefan)]

> Schalte ich den uc ein, so werden beide Zeilen komplett ausgefüllt.

Das ist doch schon was...

Das Display ist nicht 100% tot. Und der Kontrast ist annähernd korrekt 
eingestellt. Aber dein init-Code wird wahrscheinlich von dem LCD nicht 
beachtet. Das momentane Bild entspricht höchstwahrscheinlich der 
Selbstinitialisierung des LCD-Controllers in der Power-On Sequenz.

Wenn der init-Code nicht ausgeführt wird, kann das mehrere Ursachen 
haben.

Eine Ursache wäre eine falsche Zuordnung der µC-IO-Pins zu den 
LCD-Controller-IO-Pins. Man würde das normalerweise anhand des 
Schaltplans und und der Datenblätter vom µC und vom LCD-Display 
kontrollieren, der fehlt hier. Hier wäre auch sinnvoll anhand des µC 
Datenblatts zu prüfen, ob die benutzen µC-Pins eine Doppelfunktion haben 
und ggf. nicht oder nur nach Voreinstellung als IO-Pin zur Verfügung 
stehen.

Eine andere Ursache wäre eine falsche Bedienung der IO-Pins. Interessant 
wäre es hier zu wissen, an welchen Pins die RS, E, ggf. RW und die D0-D7 
Leitungen des Displays hängen. Mit dem Wissen, könnte man hingehen und 
den Sourcecode checken, ob richtig mit den Leitungen geklappert wird.

Eine andere Ursache wäre ein falscher Ablauf der Initialisierungssequenz 
hinsichtlich der zu sendenden Codes (Funktionsaufrufe) und deren 
Timings. Man würde das normalerweise durch einen Vergleich von 
Sourcecode und Beschreibung im LCD-Controller Datenblatt kontrollieren. 
Das Datenblatt fehlt hier.

Eine andere Ursache kann auf der µC Seite liegen. Bzgl. des Timings 
müsste man auch kontrollieren, dass der µC tatsächlich mit F_CPU 
arbeitet, d.h. wie sieht das Targetboard aus und wie sind die Fuses 
eingestellt sowie wurde der Code mit/ohne Optimierung übersetzt.

Könnte, müsste, würde...

Ohne diese Grundlagen sieht mir der init-Code bereits fischig aus. Es 
wird nicht beachtet, dass der LCD-Controller nach dem Hardwarereset eine 
Mindestwartezeit vor dem ersten Funktionsaufruf braucht und alle 
Kommandos werden mit gleichen Wartezeiten abgesetzt. Beides ist 
ungewöhnlich; sowas habe ich bisher bei keinem funktionierenden 
Sourcecode für LCD-Controller gesehen.

[Werner B. (Gast)]

...und wenn schon F_CPU im Quellcode, dann gehört er VOR den Include von 
delay.h

#define F_CPU 16000000
#include <util/delay.h>

[Martin Parr (Gast)]

>void init(void){
>
>    PORTA &= ~(1<<PA0);
>    PORTA &= ~(1<<PA1);
>    PORTC=0x3C;
>    enable();
>    PORTC=0x3C;
>    enable();
>    PORTC=0x3C;
>    enable();
>    ...
Bei den Controllern die ich kenne, die brauchen einen längeren Delay zum 
Beginn. (also jeweils nach den 3 ersten enable pulses)

[Werner B. (Gast)]

http://www.mikrocontroller.net/articles/AVR-Tutorial:_LCD