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); }
> 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.
...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>
>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)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.