Forum: Mikrocontroller und Digitale Elektronik LCD Display trotz Initialisierung schwarz


von Elektrotiger (Gast)


Lesenswert?

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

von Bolivar (Gast)


Lesenswert?

> 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.

von Falk B. (falk)


Lesenswert?

@ 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.

von Elektrotiger (Gast)


Lesenswert?

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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Bolivar schrieb:
> Im makefile:
>
> OPTIMIZE       = -O0

Das bedeutet 'keine Optimierung' und ist unsinnig. Die _delay_XX() 
Funktionen laufen gut mit der Optimierung auf Size, also '-Os'. Man 
sollte dafür allerdings FCPU vor dem '#include util/delay.h' 
definieren.

von ?!? (Gast)


Lesenswert?

Bolivar schrieb:
> Im makefile:
>
> OPTIMIZE       = -O0

Er will die Optimierung einschalten und nicht aus!

von Bolivar (Gast)


Lesenswert?

?!? schrieb:
> Bolivar schrieb:
>> Im makefile:
>>
>> OPTIMIZE       = -O0
>
> Er will die Optimierung einschalten und nicht aus!

Du hast recht! Der Fluch von Copy & Paste.

von Elektrotiger (Gast)


Lesenswert?

Danke Allen :).
Optimize = s
und es läuft :)).

von Karl H. (kbuchegg)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Elektrotiger (Gast)


Lesenswert?

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...

von Karl H. (kbuchegg)


Lesenswert?

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.

von Elektrotiger (Gast)


Lesenswert?

Da der Mensch nicht mehr als 30 Frames pro Sekunde wahrnehmen kann, hast 
du wohl recht ;).

von Karl H. (kbuchegg)


Lesenswert?

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.

von Elektrotiger (Gast)


Lesenswert?

Wäre mal interessant zu wissen wie oft die Werte pro Sekunde z.B. an 
Multimeter aktuualisiert werden.

von Karl H. (kbuchegg)


Lesenswert?

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.

von Paul Baumann (Gast)


Lesenswert?

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

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
Noch kein Account? Hier anmelden.