myAVR-LCD-Fragen

> Verschwimmt die Schrift oder wie meinst du ?
So ähnlich - es ist der selbe Effekt wie bei trägen TFT-Monitoren; für 
den Bruchteil einer Sekunde ist noch die alte Schrift lesbar ... sieht 
sehr unschön aus

> Bin mir nicht sicher ob in dem zusätzlichen Handbuch (Lehrheft LCD
> Programmierung)
> auf dieses Problem näher eingegangen wird.
Ich auch nicht - ich hab einfach mal den Beispiel-ASM-Code in C 
übersetzt :-); ich muss sagen dass man dabei recht viel versteht, 
zusammen mit der Displaykommando-Tabelle des LCD-AddOns kann ich 
(hoffentlich) jedes Problem lösen

> enige Nanosekunden klingt natürlich recht kurz,
ich muss sogar in den MILLIsekunden-Bereich gehen. Genauer gesagt: 5 ms 
vor jedem Displaykommando, bei weniger wird Müll angezeigt. Naja, das 
muss wohl ein SEHR träger µC sein.
(An dieser Stelle bitte ein LCD-verachtendes "Pfff" denken)

Hallo,

Daten zum LCD-Display stehen im Datenblatt des LCD-Displays und dessen 
Controller, da hilft es wenig, wenn Du das Mega8/16 Datenblatt fast 
auswendig kannst...

Die Display sind dazu da, um Text anzuzeigen. Einfach so, statisch.
Shift geht durchaus auch, mehr als so ca. 2-3 Zeichen/s schieben macht 
aber eben wenig Sinn, weil die Dinger sehr lahm sind.

Soll ja auch kein Film drauf lasufen... ;-)

Zum verschwindenden Text kam ja schon der Hinweis auf die Organisation 
des Display-Rams. Steht auch im Datenblatt. Des Displays, nicht des 
ATMega.

Gruß aus Berlin
Michael

spess53 wrote:

> Brauchst du ja nicht. Einfach Status des LCD auswerten.

Wie?

Hier mal der bisherige Quelltext, vielleicht hat ja jemand 
Optmierungsvorschläge ...

Alexander Haas wrote:
> WOW du wartest 500ms bevor du weitershiftest..puh klingt viel

Naja, ich will den Text ja noch lesen können :-)

spess53 wrote:
> Hi
>
>>Wie?
>
> Es gibt einen Befehl 'Read busy flag & address'. Damit wird ein Byte vom

Ah .. ich hab zuerst das Datenblatt des HD4470 gelesen, sah das 
Busy-Flag und konnte aber keine Umsetzung in dem LCD-Datenblatt erkennen 
- die letzte Zeile hab ich wohl übersehen. Danke!

Hat noch jemand Vorschläge für das Schlierenproblem?

So, dank der grandiosen Hilfe von spess konnte ich den Code nun 
wunderschön an den LCD-Controller anpassen, mit einer Ausnahme: nach dem 
schreiben von Display-Zeichen ist das Busy-Flag scheinbar dauerhaft auf 
1 (also "Busy"). Kann mir jemand erklären warum?

gemeint ist in meinem Code die Funktion "lcdout_single" --> wenn man 
"waitForBusyFlag()" wieder aktiviert rödelt der Atmel ständig in der 
Schleife herum, wie ich mir bereits durch die Ausgabe an PortC.0 selbst 
bestätigt habe (is ne LED dran).

holger wrote:
>>  while((PORTD & 0x80) == 0x80)
>
> Wie wärs mit PIND?
Richtig. Ergebnis ist trotzdem das selbe.

spess53 wrote:
> Vor jedem Lesen muss E geschaltet werden.
>
> MfG Spess

1

void lcdout_single(char zeichen)

2

{

3

  unsigned char temp = zeichen;

4

  temp = temp << 4;          //Low-Nibble nach links schieben

5

  PORTD = (zeichen & 0xF0) | rs;    //Maskieren und rauskloppen, aber RS erhalten

6

  enable();

7

  //_delay_ms(5);

8

  waitForBusyFlag();

9

  PORTD = temp | rs;          //Dasselbe in Grün

10

  enable();

11

  //_delay_ms(5);

12

  waitForBusyFlag();

13

}

14

void waitForBusyFlag()

15

{

16

  enable();

17

  DDRC |= (1<<PC0);

18

  PORTB |= (1<<PB0);

19

  while((PIND & 0x80) == 0x80)

20

  {

21

    PORTC |= (1<<PC0);

22

    asm volatile("nop");

23

    enable();

24

  }

25

  DDRC = 0;

26

  PORTB &= ~(1<<PB0);

27

  PORTC &= ~(1<<PC0);

28

}

funktioniert leider immernoch nicht. PortB.0 ist übrigens R/W

holger wrote:
>>>>  waitForBusyFlag();
> Löschen!

done. Jetzt zeigt das Display nur abwechselnd Datenmüll und schwarze 
Kästchen an. Und die LED leuchtet (--> Schleife).

Immernoch Datenmüll, mit oder ohne dem ersten waitFor... in  lcdout. 
Leider.

1

void enable()

2

{

3

  PORTD |= (1 << PD3);

4

  _delay_us(1);

5

  PORTD &= ~(1 << PD3);

6

}

7

8

void lcdout_single(char zeichen)

9

{

10

  unsigned char temp = zeichen;

11

  temp = temp << 4;          //Low-Nibble nach links schieben

12

  PORTD = (zeichen & 0xF0) | rs;    //Maskieren und rauskloppen, aber RS erhalten

13

  enable();

14

  //_delay_ms(5);

15

  //waitForBusyFlag();

16

  PORTD = temp | rs;          //Dasselbe in Grün

17

  enable();

18

  //_delay_ms(5);

19

  waitForBusyFlag();

20

}

21

void waitForBusyFlag()

22

{

23

  PORTD |= (1 << PD3);

24

25

  DDRC |= (1<<PC0);

26

  PORTB |= (1<<PB0);

27

  while((PIND & 0x80) == 0x80)

28

  {

29

    PORTC |= (1<<PC0);

30

    asm volatile("nop");

31

  }

32

33

  PORTD &= ~(1 << PD3);

34

35

  DDRC = 0;

36

  PORTB &= ~(1<<PB0);

37

  PORTC &= ~(1<<PC0);

38

}

Hallo,

  DDRC |= (1<<PC0);
  PORTB |= (1<<PB0);
  while((PIND & 0x80) == 0x80)
  {
    PORTC |= (1<<PC0);
    asm volatile("nop");
  }

Du schaltest hier die Datenrichtung von PC0 um?
Du liest in der Schleife PIND ein?
Die Daten vom Display sind gültig während! E auf H ist, nach der 
H/L-Flanke ist das Display wieder im TriState...

Warum gibst Du den Bits nicht ein paar sprechende Namen?
  PORTB |= (1<<LCD_RS) (oder was am Bit auch immer dranhängt)
liest sich besser als
  PORTB |= (1<<PB0);

Oder gegt das in C nicht (bin immernoch ASM-Programmierer...)?

Gruß aus Berlin
Michael

Michael U. wrote:

> Du schaltest hier die Datenrichtung von PC0 um?
> Du liest in der Schleife PIND ein?
Ja, an PortC liegt eine LED. PortD ist das eigentliche Datenbyte für das 
LCD ...

> Die Daten vom Display sind gültig während! E auf H ist, nach der
> H/L-Flanke ist das Display wieder im TriState...
Jap. Und genau das nutze ich doch aus ... ?

> Warum gibst Du den Bits nicht ein paar sprechende Namen?
Weil ich Redundanz verabscheue ... in meinem Berufsalltag erhöht das 
regelmässig den "WTFs/min"-Index

Hallo,

Vorname Nachname wrote:
> Michael U. wrote:
>
>> Du schaltest hier die Datenrichtung von PC0 um?
>> Du liest in der Schleife PIND ein?
> Ja, an PortC liegt eine LED. PortD ist das eigentliche Datenbyte für das
> LCD ...
Gut, ich muß jetzt nicht verstehen, warum man die Datenrichtung ändert, 
wenn eine LED dran hängt. Ich schalte LEDs mit dem Portzustand ein und 
aus.

Ich suche die Stelle, wo Du zum Lesen des Busybits die Datenleitungen 
des LCD am AVR auf Eingang umschaltest. Wie willst Di sonst da was lesen 
können?
>
>> Die Daten vom Display sind gültig während! E auf H ist, nach der
>> H/L-Flanke ist das Display wieder im TriState...
> Jap. Und genau das nutze ich doch aus ... ?

Naja, hätte das Bit PD3 LCD_E oder so geheissen, wäre es wohl sogar mir 
aufgefallen......

>> Warum gibst Du den Bits nicht ein paar sprechende Namen?
> Weil ich Redundanz verabscheue ... in meinem Berufsalltag erhöht das
> regelmässig den "WTFs/min"-Index

Ich wümsche Dir mit solchen Quellen viel Spaß, wenn Du die in ein paar 
Monaten mal wieder anfäßt...

Gruß aus Berlin
Michael

Michael U. wrote:
> Ich suche die Stelle, wo Du zum Lesen des Busybits die Datenleitungen
> des LCD am AVR auf Eingang umschaltest. Wie willst Di sonst da was lesen
> können?

1

PORTB |= (1<<PB0);

> Ich wümsche Dir mit solchen Quellen viel Spaß, wenn Du die in ein paar
> Monaten mal wieder anfäßt...
so etwas trainiert und fördert Kompetenz. Wenn man etwas immer wieder 
überdenken oder gar neu lernen muss fliesst es garantiert mit der Zeit 
ins Langzeitgedächtnis und ist somit sehr schnell abrufbar

dummy wrote:
> zu kämpfen haben. Aber ich bin mir sicher das genau das
> dein Ziel ist.
Und ich bin mir sicher dass du nur ein Troll bist und nicht die 
geringste Ahnung von professioneller Programmierung hast.
Deine scheinbare "Unübersichtlichkeit" wandelt sich ganz schnell zu 
"logischer Ordnung" sobald man mal die Funktionsweise des Programms 
verstanden hat. Wenn man eben noch nicht einmal die Grundzüge versteht 
... tja.

Ich muss mich täglich mit kryptischen Namen auseinandersetzen, die aber 
genauer betrachtet mehr als logisch und durchgehend statisch sind, dies 
garantiert bei grösseren Projekten die 
Nachvollziehbarkeit/Erweiterbarkeit - aber ich will dich jetzt nicht mit 
OOA-Prinzipien überfordern.

Hat jemand was Sinnvolles beizutragen? Vorzugsweise spess oder gar 
holger?

Vorsicht Offtopic!

>> Warum gibst Du den Bits nicht ein paar sprechende Namen?
> Weil ich Redundanz verabscheue ... in meinem Berufsalltag erhöht das
> regelmässig den "WTFs/min"-Index

Stimmt, das erhöht die "WhatTheF*ckIsThis/min"-Index der QS-Kollegen 
beim Peer Code Review. Die zwingst du, die ansonsten an der Stelle 
redundanten Datenblätter auch wirklich mal zu benutzen, um zu verstehen, 
was deine magische 42 an der Stelle bedeutet.

Blablub ... ich geh dann mal Werte in mein nicht funktionierendes 
Display kloppen, da ja ausser den Hobby-Experten keiner mehr weiter 
weiss. Spess/holger? Habt ihr noch nen Tip? Das wäre schön ..

spess53 wrote:
>                       cbr r17,1<<lc_e            ; Disable Anzeige
>                       out lc_ctl_out,r17
>
>                       andi r16,$80               ; BIT7=0
>                       breq wrdat20               ; wenn ja weiter
>                       nop
>                       nop                        ; etwas zeit lassen
>                       rjmp wrdat10
>
> MfG Spess
Ganz genau so mach ich das ja auch. Führst du diese Überprüfung auch 
beim schreiben von Zeichen durch?

dummy wrote:
> Wer wartet schon aufs Display?
> Ein bißchen Shadow-RAM für das Display reservieren.
> Interruptausgabe 1ms pro Zeichen und gut is ;)

Dem ist eigentlich nichts mehr hinzuzufügen, weil das mit Abstand die 
effektivste Lösung ist. Keinerlei Wartezeiten oder Busy-Polling nötig.


Ich hab mir auch ganz schnell angewöhnt, den IO-Pins Namen zu geben. Der 
Code wird dadurch wesentlich besser lesbarer und modularer.

Oftmals haben IO-Pins Spezialfunktionen und wenn man diese benötigt, muß 
man das LCD dann an andere Pins legen.
Die mühseligen Namenlosen müssen dann ihren LCD-Treiber komplett neu 
schreiben.
Aber die cleveren Namenbenutzer ändern einfach nur die Pin-Definitionen 
im h-File und alles läuft wieder:

http://www.mikrocontroller.net/attachment/30300/lcd_drv.zip


Peter

Peter Dannegger wrote:
> Die mühseligen Namenlosen müssen dann ihren LCD-Treiber komplett neu
Falsch. Stichwort "Search & Replace". Jeder noch so schlechte Texteditor 
kann das. Statt sich dann mit den eigenwilligen Bezeichnungen anderer 
rumzuquälen gewöhnt man sich ein einziges Mal (!) an standardisierte (!) 
Bezeichnungen und liegt immer richtig.

Im Übrigen ist

1

PORTD |= (1<<PD3)

 nicht wirklich eine Magic Number,

1

PORTD |= 8

 dafür aber sehr, schliesslich steht PD3 logischerweise für Port D, Pin 
3 -- das ist mehr als nachvollziehbar.

Genau das war wohl auch der einzigste Kritikpunkt an meinem Code: in 
meinen Kommando-Funktionen verwende ich nur hexadezimale Angaben ... 
aber das war ja auch nur ein Test-Konstrukt und wird für meine 
dauerhaften Aufgaben auch nicht so bleiben.
Wenn man nun die Standard-Bezeichnungen verwendet genügt Jahre danach 
ein schlichter Blick in das Datenblatt und der grobe Überblick über 
"Werkstück" um alles zu verstehen, bei diesen tollen Substitutionen ist 
erstmal ein Verständnis vom kompletten (!) Code nötig - im grösseren 
Umfeld ist das ein Killer.

Vorname Nachname wrote:
> Peter Dannegger wrote:
>> Die mühseligen Namenlosen müssen dann ihren LCD-Treiber komplett neu
> Falsch. Stichwort "Search & Replace".

Ja, das ist ein sehr schönes Werkzeug, um viel Unheil anzurichten.
Es ist nämlich ein strohdummes Werkzeug, das nicht wissen kann, ob eine 
richtige Stelle zuwenig oder eine falsche Stelle zuviel replaced wurde.


Frag dochmal nen professionellen Programmierer. Wenn immer möglich, sind 
Hardwareanpassungen nur im h-File vorzunehmen, das c-File bleibt 
unangetastet.



> Im Übrigen ist
>

1

PORTD |= (1<<PD3)

> nicht wirklich eine Magic
> Number

Für jeden, der Deinen Schaltplan nicht kennt, ist sowas völlig 
unverständlich.


Peter

Sacht ma kann dat sein dass der LCD-Controller n bischen verbugt is? Ich 
erhalte hier zufällige (!) Funktion bei ein und demselben Quelltext, 
manchmal ist das Busy-Bit endlos auf HIGH und manchmal zeigt es absolut 
korrekt an, direkt nach LCD-Kommandos ist es schon garnicht zu 
gebrauchen und zudem bleibt es auch zufällig lange an/aus. Hat jemand 
schonmal gute (!) Erfahrungen mit dem BF unter avr-gcc auf einem 
myAVR-Board gemacht?

Hallo,

naja, die "Kleinigkeit", daß er ein Bit auf Eingang setzt beim Busy 
lesen, das Display aber seinen ganzen Port auf Ausgang, stört ihn ja 
auch nicht.
Vielleicht stört es aber irgendwann den AVR- oder Displayport wenn die 
restlichen Pins gegeneinander kämpfen...
Naja, Datenblatt lesen will eben auch gelernt sein.

Aber er weiß und kann doch ohnehin alles besser.

Was solls also...

Gruß aus Berlin
Michael

spess53 wrote:
> Tausende Programmierer haben dieses Problem schon (ohne dieses
> Forum)erfolgreich erfolgreich gelöst. Wer kann dann von dann sagen, dass
> (s)eine Methode die effektivste ist.

Die reine Logik.
Eine Methode ohne Wartezeiten oder Busypolling ist nunmal effektiver als 
jede andere mit. Da beißt die Maus keinen Faden ab.

In der Regel sind die Wartezeiten für das LCD aber tolerierbar, da ja 
Ausgaben erstmal gelesen werden müssen.

Es gibt allerdings auch Anwendungen, wo die CPU schon gut ausgelastet 
ist oder die Mainloop möglichst kurz sein muß. Da ist dann die 
Interruptmethode das Mittel der Wahl.


Peter

Michael U. wrote:
> Hallo,
>
> naja, die "Kleinigkeit", daß er ein Bit auf Eingang setzt beim Busy
> lesen, das Display aber seinen ganzen Port auf Ausgang, stört ihn ja

Naja, die "Kleinigkeit" dass du nichtmal weisst wie ein myAVR-Board
aufgebaut ist ODER gar Quelltext lesen kannst ...

das LCD selbst bzw. dessen Datenbits/-Pins haben rein GARNICHTS mit
PORTB zu tun, dort sitzt nämlich das Busyflag und ihr Kind.

> das Display aber seinen ganzen Port auf Ausgang
Das DISPLAY hat schonmal garkeinen Port, höchstens
Ausgangspins/Datenleitungen und einstellen liesse sich an dem
zuständigen, mit nem Silikattropfen bedeckten µC auch nichts.