LCD Display trotz Initialisierung schwarz

Gast #3936483
Ich habe die lcd-routines.c und lcd-routines.h zusammen mit einer main.c 
das erste Beispiel alle samt vom AVR-GCC-Turoial um allgemein mein LCD 
Display zu testen.
1
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung

Nun zeigt das Display nach der Initialisierung immer noch schwarze 
Balken.
Den Kontrast kann ich mit einem Poti ändern.
Meine Vermutung ist, dass der Compiler die delay Zeiten nicht richtig 
übersetzt:

"Wichtig ist außerdem, dass die Optimierung bei der Compilierung 
eingeschaltet ist, sonst stimmen die Zeiten der Funktionen _delay_us() 
und _delay_ms() nicht und der Code wird wesentlich länger (Siehe 
Dokumentation der libc im WinAVR)."

Wo kann ich dies einschalten oder wo lieht der Fehler?
Habe alles an PORTA. PA0 bis PA3 sind D4 bis D7.
PA4 RS und PA5 E. Dies habe ich in der Header Datei auch angepasst.
1
#ifndef F_CPU
2
#define F_CPU 7372800
3
#endif
4
 
5
////////////////////////////////////////////////////////////////////////////////
6
// Pinbelegung für das LCD, an verwendete Pins anpassen
7
// Alle LCD Pins müssen an einem Port angeschlossen sein und die 4
8
// Datenleitungen müssen auf aufeinanderfolgenden Pins liegen
9
 
10
//  LCD DB4-DB7 <-->  PORTD Bit PD0-PD3
11
#define LCD_PORT      PORTA
12
#define LCD_DDR       DDRA
13
#define LCD_DB        PA0
14
 
15
//  LCD RS      <-->  PORTD Bit PD4     (RS: 1=Data, 0=Command)
16
#define LCD_RS        PA4
17
 
18
//  LCD EN      <-->  PORTD Bit PD5     (EN: 1-Impuls für Daten)
19
#define LCD_EN        PA5

Ich benutze den Atmega16
Gast
> Wo kann ich dies einschalten oder wo lieht der Fehler?

Im makefile:

OPTIMIZE       = -O0

Ansonsten ist das ansteuern mit Delays ziemlicher Mist. Besser ist es 
das Busyflag des Controllers auszuwerten.

Ansonsten: alle Quellen posten, eventuell einen Schaltplan und ein Bild 
vom Aufbau.
@ Elektrotiger (Gast)

>Nun zeigt das Display nach der Initialisierung immer noch schwarze
>Balken.

Dann stimmt was nicht. Prüfe ALLE Verbindungen.

>"Wichtig ist außerdem, dass die Optimierung bei der Compilierung
>eingeschaltet ist, sonst stimmen die Zeiten der Funktionen _delay_us()
>und _delay_ms() nicht und der Code wird wesentlich länger (Siehe
>Dokumentation der libc im WinAVR)."

>Wo kann ich dies einschalten

In den Projektoptionen im AVR Studio.
Gast
1
# Optimization level, can be [0, 1, 2, 3, s]. 
2
#     0 = turn off optimization. s = optimize for size.
3
#     (Note: 3 is not always the best optimization level. See avr-libc FAQ.)
4
OPT = s

Ist dies nicht standardmäßig auf s also an?
Was würde: OPTIMIZE       = -O0
bedeuten?

Bolivar schrieb:
> Ansonsten: alle Quellen posten, eventuell einen Schaltplan und ein Bild
> vom Aufbau.

Quellen sind angegeben, Aufbau sollte richtig sein, kann ich erst nach 
Weihnachten posten.
Elektrotiger schrieb:

> Meine Vermutung ist, dass der Compiler die delay Zeiten nicht richtig
> übersetzt:

Dann solltest du das testen.

Häng an einen Portpin eine LED drann und schreib dir ein Testprogramm
1
#define F_CPU ..... dein tatsächlicher Wert
2

3
#include <avr/io.h>
4
#include <util/delay.h>
5

6
#define LED_DDR  DDRB
7
#define LED_PORT PORTB
8
#define LED_BIT  PB3
9

10
int main()
11
{
12
  LED_DDR |= ( 1 << LED_BIT );
13

14
  while( 1 )
15
  {
16
    LED_PORT |= ( 1 << LED_BIT );
17
    _delay_ms( 1000 );
18
    LED_PORT &= ~( 1 << LED_BIT );
19
    _delay_ms( 1000 );
20
  }
21
}

setz für F_CPU den bei dir relevanten Wert ein, setz die Makros auf Port 
und Bit an dem du tatsächlich eine LED drann hängen hast und wenn alles 
richtig ist, dann blinkt die LED im Sekundentakt. Ist die LED NICHT 1 
Sekunde an bzw. 1 Sekunde aus, dann hast du Grund zur Fehlersuche. 
Stimmen die Zeiten aber, dann ist soweit mit den _delays erst mal alles 
korrekt.
Und nur zur Klarheit: Wenn da was schief geht, sei es zb, dass der 
Prozessor gar nicht mit der in F_CPU angegebenen Taktfrequenz läuft 
und/oder die Optimierung nicht eingeschaltet ist, dann sind die Zeiten 
so grob daneben, dass man das leicht mit freiem Auge erkennen kann.
Bolivar schrieb:
> Ansonsten ist das ansteuern mit Delays ziemlicher Mist. Besser ist es
> das Busyflag des Controllers auszuwerten.

Nö.
Eine solche Behautung unbegründet in den Raum stellen, ist ziemlicher 
Mist.

Ich benutze immer Delay und hatte noch nie Probleme damit. Wozu unnütz 
einen zusätzlichen IO-Pin opfern.
Gast
Peter Dannegger schrieb:
> Ich benutze immer Delay und hatte noch nie Probleme damit. Wozu unnütz
> einen zusätzlichen IO-Pin opfern.

Naja ganz unrecht hat er nicht ;). Wenn ich ADC Werte am Mikrocontroller 
auslese und diese stets am Display aktualisieren möchte brauche ich eine 
Abfrage ob das LCD Display bereit für einen weiteren Befehl ist.

Meine Frage dazu: Was genau ist mein Busy Flag beim 162CBCBC.
Da ist im Datenblatt nichts von einem Busyflag die Rede...
Elektrotiger schrieb:
> Peter Dannegger schrieb:
>> Ich benutze immer Delay und hatte noch nie Probleme damit. Wozu unnütz
>> einen zusätzlichen IO-Pin opfern.
>
> Naja ganz unrecht hat er nicht ;). Wenn ich ADC Werte am Mikrocontroller
> auslese und diese stets am Display aktualisieren möchte brauche ich eine
> Abfrage ob das LCD Display bereit für einen weiteren Befehl ist.

Ja. Im Prinzip.

Frage: wie schnell kannst du lesen?
Wie schnell ist dagegen das Schreiben auf das LCD, selbst wenn man nach 
jedem Zeichen 1ms wartet?

In der Theorie hast du recht: man verschenkt damit ein bischen Zeit. In 
der Praxis spielt das aber keine Rolle, weil sowieso kein vernünftiger 
Mensch pro Sekunde 1000 Zeichen auf ein 4 zeiliges LCD mit je 20 Zeichen 
pro Zeile schaufelt. Weil man dann nämlich erst recht nichts lesen kann, 
wenn alles ständig nur flackert.
Elektrotiger schrieb:
> Da der Mensch nicht mehr als 30 Frames pro Sekunde wahrnehmen kann, hast
> du wohl recht ;).

Du kannst da getrost noch einen Zehner wegnehmen. Mehr als 3 bis 4 
Updates eines Wertes pro Sekunde machen keinen Sinn, weil das sowieso 
keiner mehr lesen kann. Und wenn sich der Wert nicht verändert weil er 
eh schon am LCD steht, braucht man auch nichts ausgeben.
Insbesonders letzteres bringt viel mehr Zeit rein, als bei jeder Ausgabe 
ein paar Mykrosekunden einsparen.
Elektrotiger schrieb:
> Wäre mal interessant zu wissen wie oft die Werte pro Sekunde z.B. an
> Multimeter aktuualisiert werden.

Kannst es ja mal versuchen :-)
Häng ein Voltmeter an einen Ausgangspin, lad obiges Blinkprogramm zum 
Delay-Test und verringere sukzessive die Zeit, bis das Voltmeter nicht 
mehr erkennbar zwischen 0 und 5 hin und herspringt, sondern nur noch 
wahllos Anzeigen ohne erkennbaren Rhythmus bringt.
Gast
Karl Heinz schrieb:
> Häng ein Voltmeter an einen Ausgangspin, lad obiges Blinkprogramm zum
> Delay-Test und verringere sukzessive die Zeit, bis das Voltmeter nicht
> mehr erkennbar zwischen 0 und 5 hin und herspringt, sondern nur noch
> wahllos Anzeigen ohne erkennbaren Rhythmus bringt.

Elektro-Sadist!
;-)

MfG Paul

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 11 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.