Hallo
Habe ein Problem, was ich nicht verstehe
lcd_clrscr(); // Display löschen
lcd_puts("LCD Text Zeile 1\n"); //Zeile 1 mit Zeilenumbruch
lcd_puts("LCD Text Zeile 2\n"); //Zeile 2 mit Zeilenumbruch
lcd_puts("LCD Text Zeile 3\n"); //Zeile 3 mit Zeilenumbruch
lcd_puts("LCD Text Zeile 4\n"); //Zeile 4 mit Zeilenumbruch
Ich benutze dieses Stück Programm, um in den Zeilen 1 bis 4 jeweils den
Text innerhalb der Klammer ausgeben möchte. Auf dem Diplay erscheint
aber nur
LCD Text Zeile 1
LCD Text Zeile 4
Die beiden anderen Texte mit den Zeilen 2 und 3 wird nicht ausgegeben
oder überschrieben. In der ersten Zeile geht es doch, warum nicht in den
anderen?
achim
wahrscheinlich werden die Konstanten, welche den Zeilenanfang der
fraglichen Zeilen im Speicher beschreiben, nicht stimmen.
Es könnte auch eine fehlerhafte Initialisierung auf 2-Zeilen Modus sein.
Aber auch ein Fehler in der Auswertung der \n wäre denkbar.
>So der Rest, ist nicht viel
Bullshit. Wo ist lcd_puts()?
>Ein LCD kennt keinen Befehl für einen Zeilenumbruch. Wenn das nicht von>'lcd_puts' geregelt wird funktioniert das nicht.
Das wird es sein. Da wird es irgendeinen lcd_gotoxy() Befehl geben.
Habe eine Pause von 2 sek dazwischen geschrieben.
Es erscheint Zeile 1, darunter nach 2 s Zeile 2, diese wird dann von
Zeile 3 überschrieben, nach weiteren 2 s wird die Zeile 3 von der Zeile
4 überschrieben
In der erstewn Zeile geht es, dann nicht mehr?
Achim Seeger schrieb:> lcd_puts("LCD Text Zeile 4\n"); //Zeile 4 mit Zeilenumbruch..> Ich benutze dieses Stück Programm,...
Es ist immer wieder dasselbe!
Die Leute benutzen irgendwelche von irgendwo her kopierte
Treiber-Routinen OHNE sie je auch nur im Mindesten zu verstehen, vom
Verstehen der eigentlichen Hardware ganz und gar abgesehen.
Mich ärgert sowas bis zum Äußersten! Warum zum Kuckuck sind diese
grandiosen Programmiereriche bloß von solcher Geistesart heutzutage?
Eigentlich ist das Bedienen eines üblichen Alpha-LCD's eine Kleinigkeit
und überhaupt keine wirkliche Schwierigkeit. In jedem (wirklich in
JEDEM!!) Datenblatt jedes 0815-Alpha-LCD's braucht es dazu nur eine
simple Tabelle. Warum brauchen also die Leute hier fertige Routinen,
die sie nicht verstehen? Ist das dasselbe, wie die fertigen Routinen zum
Tstenentprellen, ja?
Also mein Rat: Der TO sollte sich seine LCD-Routinen besser selbst
schreiben um dadurch zu verstehen, wie denn nun genau selbiges zuwege
gebracht wird.
W.S.
spess53 schrieb:> Hi>> Wenn ich das richtig interpretiere funktioniert \n nur, wenn R/W vom> Display auch angeschlossen ist.
Die ganze Fleury Lib ist Busy-Flag orientert und funktioniert nur, wenn
R/W angeschlossen ist.
D.h. wenn er Ausgaben hat, dann ist der Teil mal korrekt.
offensichtlich positioniert ja auch das LCD immer wieder in Zeile 2,
wenn in lcd_newline() der entsprechende Umbruch angeordnet wird.
Die Frage ist eigentlich: warum immer in Zeile 2.
Alternativ könnte man natürlich auch sagen: leg den ganzen Humbug mit \n
Auswertung still. Braucht sowieso kein Mensch.
Es wird die Zeile 1,3 und 4 dargestellt, an der linken Seite. Die Zeile
wird überschrieben
Sorry, was soll das. Hersteller, Peter oder Karl Heinz schreiben sehr
gute Sache. Warum sollen wir diese nicht nutzen. Muss jeder das rad neu
erfinden. Wenn ich mir beiden Datein ansehe, so versteh ich einiges da
von, aber bei weitem nicht alles. Es muss auch nicht jeder sein eigenes
Auto bauen, bloss wenn er eins fahren will. Ich bin Anfänger, ist klar,
aber nicht verrückt, das ich alles selber machen muss ist nicht Sinn der
ganzen Sache,
Bleibe bitte bei einem Sachlichen Ton
achim
Achim Seeger schrieb:> Es wird die Zeile 1,3 und 4 dargestellt, an der linken Seite. Die Zeile> wird überschrieben
?
Das heisst, das sieht dann so aus?
>Es wird die Zeile 1,3 und 4 dargestellt, an der linken Seite. Die Zeile>wird überschrieben
Kannst Du das bitte noch einma neu formulieren? Ich verstehe es nämlich
nicht.
Es ist klar, das Zeilen dargestellt werden. Aber was konkret an Inhalt
wird auf welcher Zeile dargestellt?
Ist Dein Satz so zu interpretieren:
---------------------
1
3
4
---------------------
oder so:
---------------------
1
3
4
---------------------
oder wie?
Jedenfalls scheinen die Adressen nicht zu stimmen. Nenne doch einmal
genau das von Dir verwendete Display.
Bitkracherl schrieb:> oder wie?
Exakt, Achim.
Da darf es jetzt keine Missverständnisse geben. Zeichne die Dinge auf,
wenn es nicht anders geht, aber beschreibe nicht verbal. Denn das führt
fast immer zu MIssverständnissen.
> Jedenfalls scheinen die Adressen nicht zu stimmen.
Seh ich auch so.
> Nenne doch einmal> genau das von Dir verwendete Display.
Zur Not können wir die Adresslage auch durch Ausgabe von überlangen
Strings ermitteln.
Hallo Karl Heinz
Habe deine Test gemacht. Jetzt komme langsam dahinter
lcd_gotoxy( 0, 0 );
lcd_puts( "1" );
//lcd_gotoxy( 0, 1 );
//lcd_puts( "2" );
lcd_gotoxy( 0, 2 );
lcd_puts( "3" );
//lcd_gotoxy( 0, 3 );
//lcd_puts( "4" );
Habe ein paar Zeile Auskommentiert. Egal was ich mach, die zweite Zeile
wird nicht geschrieben, das einzigste was passiert, die Zeile 3 rutscht
in die 2 Zeile. Da ich lcd_gotoxy verwende spreche ich die zweite Zeile
direkt an. Da fällt mir nur ein Fehler am Display zu ein, ansonsten
müsste es doch mit lcd_gotoxy gehen?
Bitkracherl schrieb:>>Zur Not können wir die Adresslage auch durch Ausgabe von überlangen Strings>>ermitteln.>> Ich bin viel fauler als Du. :-)
:-)
Dafür bin ich zu faul mir das Datenblatt zu suchen und dort die Info
rauszusuchen. Da mach ich lieber ein
Wenn ich nochmal kurz helfen darf: (Zumindest ich bin immer noch im
Zweifel).
>Da darf es jetzt keine Missverständnisse geben. Zeichne die Dinge auf,>wenn es nicht anders geht, aber beschreibe nicht verbal. Denn das führt>fast immer zu MIssverständnissen.
Achim Seeger schrieb:> wird nicht geschrieben, das einzigste was passiert, die Zeile 3 rutscht> in die 2 Zeile.
Wo genau?
An den linken Rand?
> Da ich lcd_gotoxy verwende spreche ich die zweite Zeile> direkt an.
Exakt. nach einem lcd_gotoxy wird die nächste Ausgabe an dieser Stelle
begonnen.
lcd_gotoxy( spalte, zeile )
> Da fällt mir nur ein Fehler am Display zu ein, ansonsten> müsste es doch mit lcd_gotoxy gehen?
Quatsch.
Die Adresslagen stimmen einfach nicht. Dein LCD benutzt ein etwas
anderes Adressierungsschema. Das ist alles. Und das muss man halt jetzt
einmal rauskriegen, die Konstanten im lcd.h anpassen und der Teil ist
paletti.
Achim Seeger schrieb:> ansonsten> müsste es doch mit lcd_gotoxy gehen?
lcd_gotoxy ist doch kein Wunderwuzzi.
Es kriegt Spalten und zeilennummer und muss daraus jetzt die Adresse
errechnen, in der es den Cursor im linear aufgebauten Speicher
positionieren muss.
Und zwar möglichst so, dass dann auch auf dem LCD das genau der Spalte
und Zeile entspricht, die angegeben wurde.
Also: wo GENAU taucht der 3-er auf?
So, habe mal weiter getestet.
Auch mit dem lcd_gotoxy(0, 1) kann ich die erste Stelle in der zweiten
Zeile nicht beschreiben. Eine Stelle weiter geht alles. Sehr komisch
achim
>So, habe mal weiter getestet.
Grrrr.
Könntest Du BITTE mal eine Skizze machen, wo die Zeichen GENAU in dem
Display erscheinen, wenn Du die im Post von Karl Heinz hier
Beitrag "Re: Komisches Verhalten mit lcd_puts" genannten Befehle
ausführts. Bitte. Bitte. Bitte. (Ich krieg' gleich nen Krampf).
Achim Seeger schrieb:> So, habe mal weiter getestet.
Achim. Das ist sinnlos.
Deinen Helfern ist völlig klar, was das Problem ist.
Das einzige Problem dabei ist, dass wir ein paar Kennzahlen vom LCD
brauchen. Die stehen im (vernünftigen) Datenblatt oder wir müssen sie
mit dir ermitteln.
> Auch mit dem lcd_gotoxy(0, 1) kann ich die erste Stelle in der zweiten> Zeile nicht beschreiben. Eine Stelle weiter geht alles. Sehr komisch> achim
Deien Tests sind für die Würscht.
Oder wie die Amerikaner sagen: You are barking up the wrong tree.
mal ganz langsam. In dem Test von KH wir an der linken Seite von oben
links beginnend (Zeile 0,0) die Zahlen 1,2,3,4 untereinander
geschrieben. Es wird lcd_gotoxy verwendet. Auf dem Display erscheinen
die Zahlen von oben links beginnend 1,3,4 untereinander. die Zahl 2
kommt nicht.
Achim Seeger schrieb:> Das ist ein PC2004 mit einem HD44780
Also in den Datenblättern, die ich gefunden habe, ist von einem
ST7066-Controller die Rede.
Wie sieht die Ausgabe aus.
Zeichne das bitte hier ein
1
+----------------------------------+
2
| |
3
| |
4
| |
5
| |
6
+----------------------------------+
Ich brauch immer nur jeweils das erste Zeichen in einer Zeile (der Rest
ergibt sich dann von alleine).
Aber: Das muss eindeutig sein!
-> nicht irgendwie beschreiben, sondern das einzeichnen, was du siehst!
>mal ganz langsam.
Langsamer gehts wohl kaum noch.
>In dem Test von KH wir an der linken Seite von oben links beginnend (Zeile >0,0)
die Zahlen 1,2,3,4 untereinander geschrieben.
Ach was!
>Auf dem Display erscheinen die Zahlen von oben links beginnend 1,3,4 >untereinander. die Zahl 2 kommt nicht.
Schön. Was aber unklar bleibt, ist, ob nun eine Lücke, eine Leere Zeile
entsteht oder nicht und in welcher Spalte die Ziffern erscheinen.
Lass uns die Variante mit der Ausgabe von "ABCDE...." probieren.
> Auf dem Display erscheinen die Zahlen von oben links beginnend 1,3,4> untereinander. die Zahl 2 kommt nicht.
..,und wo ist die Leerzeile? scnr
..bitte aufzeichnen..
@ Karl Heinz
Hm. Das scheint möglicherweise ein etwas hartleibiges Display zu sein.
Scheint, es ist in X Varianten produziert worden.
Guck mal hier Karl Heinz:
Beitrag "PC2004-d 4*20 Display von eBay - seltsames Verhalten"
Da sind zwei verschiedene Belegungen zu sehen.
Karl Heinz schrieb:> Da mach ich lieber ein lcd_puts(> "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789" );> und seh nach, mit welchem Zeichen die 3. Zeile (2.te, 4.te) anfängt :-)
Mach halt mal das was man dir rät und poste ein Ergebnis.
:-)
das lässt sich auch noch besser machen. Knallen wir das Ding voll
1
intmain()
2
{
3
lcd_init(LCD_DISP_ON);// Display initialisieren
4
lcd_puts("ABCDEF0GHIJKL0MNOPQR0STUVW0XYZa");
5
lcd_puts("ABCDEF1GHIJKL1MNOPQR1STUVW1XYZa");
6
lcd_puts("ABCDEF2GHIJKL2MNOPQR2STUVW2XYZa");
7
lcd_puts("ABCDEF3GHIJKL3MNOPQR3STUVW3XYZa");
8
lcd_puts("ABCDEF4GHIJKL4MNOPQR4STUVW4XYZa");
9
10
while(1)
11
;
12
}
jeder String ist genau 0x20 Zeichen lang. Ins Alphabet hab ich jeweils
Zahlen eingeschmuggelt, so dass im sichtbaren Bereich Ziffern zu sehen
sein müssten, mit denen man identifizieren kann, welche Wiederholung in
jeder Zeile gerade zu sehen ist.
holger schrieb:>>Ach Mist. Verzählt :-)>> Wieso möchtest du fünf Zeilen auf das Display schreiben?
Ich möcht eigentlich den DDRAM vom LCD voll bekommen. OK, 4 mal den
String hätte es auch getan. :-) 4 * 0x20 -> 0x80
Achim! Nimm die leztzte Ausgabeanweisung raus.
1
lcd_puts("ABCDEF0GHIJKL0MNOPQR0STUVW0XYZa0");
2
lcd_puts("ABCDEF1GHIJKL1MNOPQR1STUVW1XYZa1");
3
lcd_puts("ABCDEF2GHIJKL2MNOPQR2STUVW2XYZa2");
4
lcd_puts("ABCDEF3GHIJKL3MNOPQR3STUVW3XYZa3");
holger hat recht. Wenn wir den DDRAM überlaufen - wer weiß was dann
alles passiert.
Selbe Frage:
Mit welchem Buchstaben fängt jede Zeile an, und welche Ziffer ist in
jeder Zeile das erste mal zu sehen?
Ist überhaupt in allen 4 sichtbare Zeilen irgendwas zu sehen?
>Mit welchem Buchstaben fängt jede Zeile an, und welche Ziffer ist in
jeder Zeile das erste mal zu sehen?
Abgesehen davon. Das kannst Du ja mal vorausschicken.
Bitkracherl schrieb:>>Ist überhaupt in allen 4 sichtbare Zeilen irgendwas zu sehen?>> @ Achim> Mache bitte auf jeden Fall eine Skizze. KEINE verbale Beschreibung.
Oh ja.
Oder ein Photo. Solange man die Buchstaben erkennen kann, ist alles ok.
Muss nicht scharf sein.
So, habe die Tests von KH gemacht, bei der langen Buchstabenreihe
erscheint in der ersten Zeile alles normal, in der zweiten und dritten
Zeile laufen sie ständig durch. Ist nur Mist zu erkennen
Wie sieht die Ausgabe aus.
Zeichne das bitte hier ein
+----------------------------------+
| 1 |
| 3 |
| 4 |
| |
+----------------------------------+
bei Angabe aller 4 Zeilen mit gotoxy sieht es so aus, Sieht nach einem
technischen Schaden aus. Werde den Artikel noch lesen, ansonsten den
Anbieter. Besteht die Möglichkeit, das ich in den lcd.c oder lcd.h was
falsch eingestellt habe?
Sorry, morgen ärgere ich mich weiter
achim
Bitkracherl schrieb:> Wusstet Ihr, dass der Zusatz von heissem Wasser, Tee wesentlich> bekömmlicher macht? :-)
Ach darum staubt es bei mir immer so!
Werd ich demnächst probieren.
Achim, was ist los? Das gibts doch nicht, dass ein Copy&Paste von 8
Zeilen Code so lange dauert.
Wenn mit diesem Code (unverändert, bis auf Tippfehler) das LCD
vollgeschrieben wird, dann hast du 5 Minuten später ein funktionierendes
lcd_gotoxy.
Ein Photo vom vollgeschriebenen LCD enthält alle Informationen, die wir
brauchen um die Konstanten zu ermitteln, die in lcd.h eingetragen werde
müssen.
Achim Seeger schrieb:> So, habe die Tests von KH gemacht, bei der langen Buchstabenreihe> erscheint in der ersten Zeile alles normal, in der zweiten und dritten> Zeile laufen sie ständig durch. Ist nur Mist zu erkennen>
Das läuft durch?
Das kann nicht durchlaufen. Die Textausgabe findet nur ein einziges mal
statt.
Karl Heinz schrieb:> Achim Seeger schrieb:>> So, habe die Tests von KH gemacht, bei der langen Buchstabenreihe>> erscheint in der ersten Zeile alles normal, in der zweiten und dritten>> Zeile laufen sie ständig durch. Ist nur Mist zu erkennen>>>> Das läuft durch?>> Das kann nicht durchlaufen. Die Textausgabe findet nur ein einziges mal> statt.
Oder hast du die Textausgaben in die Schleife hinein verschoben.
Das war nicht Sinn der Sache. Die Ausgabe SOLL nur einmal statt finden
und nicht öfter.
Achim Seeger schrieb:> Ist nur Mist zu erkennen
Ist der Mist eher Gülle- oder eher Jauchemäßig?
Meine Güte! Hör endlich mit Deinen verbalen Beschreibungen auf und mache
klare Angaben.
Steht bei jedem Programmstart der gleiche Mist da oder jedesmal was
anderes?
>>Sorry, morgen ärgere ich mich weiter
Du sollst das erstmal nicht bewerten was Du da siehst.
Das hält Dich und uns nur auf. Wir sind eigentlich schon seit einer
Stunde kurz vor der Lösung.
Merkst Du wie wir die ganze Zeit eigentlich nur versuchen mal überhaupt
EINE korrekte und verständliche Information von Dir zu erhalten. Aber Du
probierst ständig irgendwas herum. Das ist kontraproduktiv. Ehrlich!
Ändermich schrieb:> Läuft dein Programm etwa in einer Schleife?
sieht man doch, wenn die Befehle nicht zyklisch kommen passiert doch an
dem Display irgendwann nix mehr, oder? Dann fehlt doch der Refresh der
Daten.
MfG
Achim Seeger schrieb:> So, habe die Tests von KH gemacht, bei der langen Buchstabenreihe> erscheint in der ersten Zeile alles normal, in der zweiten und dritten> Zeile laufen sie ständig durch. Ist nur Mist zu erkennen
Ist doch logisch:
+----------------------------------+
| ABCDEF0GHIJKL0MNOPQR0STUVW0XYZa0 |
| MistMistMistMistMistMistMistMist |
| MistMistMistMistMistMistMistMist |
| |
+----------------------------------+
Karl Heinz schrieb:> Ein Photo vom vollgeschriebenen LCD enthält alle Informationen, die wir> brauchen um die Konstanten zu ermitteln, die in lcd.h eingetragen werde> müssen.
Na, na, ihr wollt doch nicht für ein fehlerhaftes LCD eine
Standardbibliothek vermurksen, vor allem wenn da noch Rückgaberecht
drauf ist. Wenn der Mist durchläuft, ist doch klar, dann helfen
natürlich nur noch Kohlebatterien ...
Manchmal überleg ich auch, mich unter einem zweiten Nick hier anzumelden
und mal ganz blöd zu stellen ...
LG, Sebastian
EGS schrieb:> Ändermich schrieb:>> Läuft dein Programm etwa in einer Schleife?>> sieht man doch, wenn die Befehle nicht zyklisch kommen passiert doch an> dem Display irgendwann nix mehr, oder? Dann fehlt doch der Refresh der> Daten.
Das LCD kann von alleine anzeigen.
genau darum geht es uns doch:
Den Speicher vom LCD einmalig vollschreiben und dann anhand der Ausgabe
identifizieren, welche sichtbare LCD-Zeile im Speicher wo anfängt.
Das ist eine Sache auf ein paar Minuten.
Und das ist das Testprogramm dazu
1
#define F_CPU 16000000UL
2
#include<stdlib.h>
3
#include<avr/io.h>
4
#include<avr/pgmspace.h>
5
#include<util/delay.h>
6
#include"lcd.h"
7
8
intmain(void)
9
{
10
lcd_init(LCD_DISP_ON);// Display initialisieren
11
12
lcd_puts("ABCDEF0GHIJKL0MNOPQR0STUVW0XYZa0");
13
lcd_puts("ABCDEF1GHIJKL1MNOPQR1STUVW1XYZa1");
14
lcd_puts("ABCDEF2GHIJKL2MNOPQR2STUVW2XYZa2");
15
lcd_puts("ABCDEF3GHIJKL3MNOPQR3STUVW3XYZa3");
16
17
for(;;)
18
{
19
}
20
}
so wie es ist, unverändert übernehmen, compilieren, brennen, laufen
lassen und Photo vom LCD machen.
> so wie es ist, unverändert übernehmen, compilieren, brennen, laufen> lassen und Photo vom LCD machen.
Beim TO brennt offensichtlich nur noch die Nachttischlampe und laufen
lässt er den Fernseher ;-)
katastrophenheinz schrieb:>> so wie es ist, unverändert übernehmen, compilieren, brennen, laufen>> lassen und Photo vom LCD machen.>> Beim TO brennt offensichtlich nur noch die Nachttischlampe und laufen> lässt er den Fernseher ;-)
Er wird doch nicht ...?
Was'n das für eine Einstellung!
>Was'n das für eine Einstellung?
Um die Zeit werden wir gerade erst warm. Und das vor 30 Jahren schon so.
Mein Gott. Haben wir die Nächte durchgehackt und diskutiert und
rumphantasiert was man alles anstellen könnte.
Bitkracherl schrieb:>>Was'n das für eine Einstellung?>> Um die Zeit werden wir gerade erst warm. Und das vor 30 Jahren schon so.> Mein Gott. Haben wir die Nächte durchgehackt und diskutiert und> rumphantasiert was man alles anstellen könnte.
Also ich geh um diese Zeit bald schlafen, weil für Arbeit um diese Zeit
nix mehr passiert. Privat hab ich mir auch gesagt, lieber 2 Tage länger
brauchen als noch nen Auto den Sekundenschlaf opfern.
Manchmal haste aber recht, dann gehts echt bis 1-2 Uhr nachts...privat
;-)
MfG, der verwendete Displaytyp wurde mich aber doch interessieren
(Zwecks Datenblatt)
Guten Morgen an alle.
Bin zwar auf Arbeit und komme nicht ans Display, versuche aber einiges
zu klären.
Das Programm läuft nicht in einer Schleife und wird nur einmal
dargestellt.
Als Mist bezeichen die Ausgabe, in der 2 und 3 Zeile des Displays. In
der 1 Zeile sind die ersten 20 Zeichen dargestellt aus dem Programm,
klar und ohne flackern. in den beiden anderen Zeilen laufen die Zeichen
so schnell durch, das nur ein wildes flackern zu sehen ist, keine klaren
Zeichen erkennbar.
Noch was zu der Quelle von lcd.h und lcd.c, nach dem Hinweis von KH habe
ich es von der offiziellen Seite geladen, zusammen mit einem
Testprogramm. Die anpassungen an den Port C und anderes habe ich nach
Angabe des Herstellers gemacht.
achim
Achim Seeger schrieb:> Noch was zu der Quelle von lcd.h und lcd.c, nach dem Hinweis von KH habe> ich es von der offiziellen Seite geladen
ist schon ok.
Nur muss dieses LCD_WRAP_LINES ausgeschaltet werden, sonst pfuscht
lcd_string in die Ausgabe rein, indem es selbst Zeilenumbrüche
generiert, wenn die Zeile voll ist. Da dieser Mechanismus noch nicht
richtig funktioniert, ist das kontrapoduktiv. Daher abschalten.
Das könnte auch das durchlaufen erklären. So gesehen macht mir das im
Moment weniger Sorgen. Der erste Schritt ist jetzt die Adresskonstanten
für die einzelnen Zeilen zu bestimmen. Normalerweise liest man die aus
dem Datenblatt aus, aber so wie es aussieht, finden wir kein Datenblatt,
das mehr als ein paar Jubel-Verkaufsmeldungen enthält. Also machen wirs
durch Versuch und Irrtum. Ist nicht so schlimm, das dauert normalerweise
ein paar Minuten (wenn ich nicht diese WRAP Funktionalität übersehen
hätte. Könnte mich in den Arsch beissen deswegen)
Ein mögliches Problem lauert noch in der Initialisierung. So kompatibel
scheint das LCD nicht zu sein. D.h. so ganz traue ich der
Initialisierung noch nicht, wo die Anzahl der Zeilen eingestellt wird.
Aber, wir werden sehen.
Tja. So ist das nun mal. Die Zeiten von Plug&Play sind vorbei. Auch
Treiber müssen unter Umständen konfiguriert werden.
@ Karl Heinz
Nur zwei Bemerkungen, wenn Du erlaubst:
>Das könnte auch das durchlaufen erklären.
Falls es zutrifft, was Du vermutest, so würde ich erwarten, das das
"durchlaufen" irgendwann, d.h. kurz nach dem Ende der Ausgabe, aufhört.
Noch eins: Falls das "durchlaufen" wirklich real ist und nicht auf einer
Schleife beruht, so erinnert mich das an ganz frühe Experimente, in
denen man den Inhalt des Videospeichers wieder auf dem Bildschirm
ausgegeben hat, d.h. binäre Pixeldaten wieder als Zeichen ausgab. Das es
sich um einen solchen Fall handelt, damit sollte man, so glaube ich,
rechnen.
>Das es sich um einen solchen Fall handelt, damit sollte man, so glaube ich,>rechnen.
Das sollte ich, glaube ich, etwas klarer beschreiben:
Es kann doch sein, das wir in das Display, ab einer bestimmten Adresse,
Daten schreiben, die wiederrum die Ausgabe an anderer Stelle
beeinflussen.
Wie gesagt, das ist nur Spekulation.
Bitkracherl schrieb:>>Das es sich um einen solchen Fall handelt, damit sollte man, so glaube ich,>>rechnen.>> Das sollte ich, glaube ich, etwas klarer beschreiben:> Es kann doch sein, das wir in das Display, ab einer bestimmten Adresse,> Daten schreiben, die wiederrum die Ausgabe an anderer Stelle> beeinflussen.>> Wie gesagt, das ist nur Spekulation.
Möglich ist alles.
Aber das wichtigste ist, dass da nicht immer lang gefackelt wird. Ich
bereite ihm die Testprogramme ohnehin schon so auf, dass er sie nur mit
Copy&Paste übernehmen muss.
Klar geht da auch schon mal was schief. Immerhin ist diese Form vom
Debugging nicht so einfach: wir sitzen hier auf der einen Seite vom
Bildschirm, er auf der anderen. Wir sehen nicht, was passiert, sondern
sind darauf angewiesen, dass er das so gut und präzise wie möglich
beschreibt. Woraufhin wir unsere Schlüsse ziehen und die Testprogramme
entsprechend modifizieren.
Wenn ich die Hardware vor mir habe, dann geht das ratz-fatz. So aber
sind wir darauf angewiesen, long-range-debugging unter erschwerten
Bedingungen zu machen.
>So aber sind wir darauf angewiesen, long-range-debugging unter erschwerten>Bedingungen zu machen.
Glaub mir, ich bin gewiss ein Mitglied der Gruppe die sich dessen
bewusst ist. Allein mein Blutdruck weist mich darauf hin. :-)
Ich versuche den Fehler mit einfachen Worten so genau wie möglich zu
beschreiben. Eine Schleife kann ich ausschliessen. Habe viele
einstellungen in meinem Prg geändert und Versucht etwas zu bekommen.
z.B. den Ort der Ausgabe, die Länge einzelnener Zeichen, mehrfache
Zeichen in verschiedenen Zeilen. Das Ergebnis war immer das selbe. Bin
gestern abend leider nicht dazu gekommen, die Datein lcd.c (h) zu
kontrollieren. Habe es jetzt gemacht. Die genannte Einstellung steht auf
1. Kann die Aenderung erst heute abend machen. Werde dann sofort darüber
berichten.
Sorry für das frühe schlafen. Muss leider ca 4:00 raus aus dem warmen
Nest.
Noch was, KH lass das mit dem Arsch be.., man kommt so schlecht ran oder
man holt sich einen Hexenschuss, wenn man sich so verdreht, oder wie das
immer sich nennt.
achim
@ Achim
Ich bitte Dich höflich auf die Situation Rücksicht zu nehmen.
Insbesondere darauf, dass Du uns um Hilfe gebeten hast. Daraus folgt
sinnvoller Weise das Du unseren Anweisungen folgst.
Bitte probiere nicht zwischendurch irgendwas herum. Das hält auf.
Gestern haben wir fast eine Stunde darauf gewartet, das Du einer
einfachen Anweisung folgst, die in 5 Minuten hätte erledigt werden
können. Das ist sehr frustrierend.
Und bitte, wenn wir Dich mehrfach auffordern die Ergebnisse nicht verbal
zu beschreiben, sondern in Form einer Skizze, dann tue das auch.
Du musst Dich entscheiden ob Du mehr Deinem Urteilsvermögen vertraust
oder unserem. Im Grunde hast Du das schon getan, in dem Du hier fragst.
Bitte bleibe dann auch konsequent bei dieser Entscheidung. Bedenke
bitte, dass wir Dir hier kostenlos und freiwillig helfen. Es ist
frustrierend, dass Du einerseits nach Hilfe fragst, dann aber doch Deine
eigenen Versuche machst und Anweisungen nicht folgst.
Diese Wünsche haben ihre guten Gründe: Die meisten hier, und
insbesondere Karl Heinz helfen seit Jahren. Die Dinge, zu denen Du hier
aufgefordert wirst, sind genau die, die wir auch selbst unternehmen
würden, um Probleme einzukreisen.
Da Du selbst Dir nicht allein helfen kannst ist es unlogisch, irgendwas
selbst herumzuprobieren, das den Ablauf der Fehlersuche dann
kompliziert. Oft stellt sich heraus, das ein eigener Versuch sich mit
einer Anweisung von uns beisst und die Resultate dann nicht verwertbar
gewesen sind. In diesem Fall hat das die Angelegenheit so sehr
verzögert, dass sie nicht mehr gestern Abend erledig werden konnte.
Und wenn wir Dich auffordern Quellcode zu posten, dann tue das bitte
auch. Das gibt uns eine wertvolle Information, eine Rückkopplung darüber
was bei Dir genau geschieht. Bedenke, das wir sonst keinerlei
Möglichkeit haben, zu sehen was geschieht, ausser dem was Du uns gibst.
Wir arbeiten blind.
Manche Anweisungen mögen Dir sinnlos vorkommen. Du wirst manchmal
meinen, dass Du eine Frage selbst beantworten kannst und es nicht
notwendig ist, Quellcode zu posten. (In diesem Fall, das Problem mit der
Schleife). Es ist aber wesentlich einfach für uns, einfach selbst einen
Blick auf den Code zu werfen, als Dir erst lang und breit sämtliche
Möglichkeiten aufzuzählen, was alles falsch gemacht werden kann; z.B.
wieviele Arten es gibt, unabsichtlich eine Schleife zu bauen.
Also, bis heute abend dann.
> Es ist aber wesentlich einfach für uns, einfach selbst einen Blick auf den Code
zu werfen
Vor allen Dingen kommt der entscheidende Geistesblitz oft erst dann,
wenn man den Code vor sich sieht. Auf die Sache mit dem #define bin ich
auch erst gekommen, nachdem ich ein wenig im Code rumgescrollt habe. Ich
hatte zwar vor Jahren ein ähnliches Problem mit dem Fleury Code, aber
das hab ich längst wieder verdrängt.
> Wir arbeiten blind.
Das ist der entscheidende Punkt. Wir können nichts bei uns ausprobieren
(wir haben ja nicht exakt die gleiche Hardware). Alles was wir haben ist
die Vorstellungskraft und Ideen, die sich in Form von Code ausdrücken
und dessen Ergebnisse wir wiederrum selbst nicht sehen können.
Sorry, den Code habe ich gepostet. Mehr war es nicht. Nach einigen
längeren Austausch mit Karl-heinz, hat er mich ermutigt, nicht nur
fertigen Code zu nehmen, sondern auch was selber zu machen. Wer nur
fertigen Code nimmt verlässt sich blind auf andere. wer selber etwas
macht, auch mit Fehlern, zeigt seine creativität. Wichtig ist dabei der
Mut zu fehlern. Keiner ist fehlerfrei. So genug dazu. Mache das heute
abend, und dann werden wir sehen ob das der Fehler war
achim
>So genug dazu.
Nein. Nicht wenn Du keine Einsicht zeigst.
>Sorry, den Code habe ich gepostet.
Nein. Das hast Du nicht.
Ich habe Dich hier Beitrag "Re: Komisches Verhalten mit lcd_puts"
aufgefordert den Code zu posten. Das hast Du NICHT getan.
>Nach einigen längeren Austausch mit Karl-heinz, hat er mich ermutigt, nicht >nur
fertigen Code zu nehmen, sondern auch was selber zu machen. Wer nur
>fertigen Code nimmt verlässt sich blind auf andere. wer selber etwas>macht, auch mit Fehlern, zeigt seine creativität. Wichtig ist dabei der>Mut zu fehlern. Keiner ist fehlerfrei. So genug dazu.
Das sind zwei völlig verschiedene Situationen. Wenn Du für Dich alleine
arbeitest, dann gilt das wohl. Aber NICHT wenn Du uns hier um Hilfe
bittest.
Ich nehme Dir nicht ab, das Dir der Unterschied in den Situationen nicht
bewusst ist. Ich halte das für einen, allerdings untauglichen,
Rechtfertigungsversuch.
Lass gut sein.
Ich hab heute Abend sowieso keine Zeit - kriege Besuch.
Gestern wärs gegangen - aber da haben wir ja getrödelt.
Bitkracherl. Falls ich heute am Abend nicht ins Forum komme, könntest du
das weiter treiben? Die Grundidee kennst du ja. LCD-Bild stabil
bekommen. Aus der Anzeige die Position des ersten sichtbaren Zeichens
pro Zeile auszählen und ins lcd.h bei den #define eintragen.
> Bitkracherl. Falls ich heute am Abend nicht ins Forum komme, ...
Mach' ich. Bin jetzt dann auch eine Weile unterwegs, aber so ab ca. 19
Uhr wieder da.
Hallo
Den Code habe ich gepostet, steht ziemlich weit oben. Habe ihn noch mal
eingetragen:
1
SoderRest,istnichtviel
2
3
#define F_CPU 16000000UL
4
#include<stdlib.h>
5
#include<avr/io.h>
6
#include<avr/pgmspace.h>
7
#include<util/delay.h>
8
#include"lcd.h"
9
10
intmain(void)
11
{
12
lcd_init(LCD_DISP_ON);// Display initialisieren
13
for(;;)
14
{
15
/* Text in jede Zeile schreiben */
16
lcd_clrscr();// Display löschen
17
lcd_puts("LCD Text Zeile 1\n");// Zeile 1
18
lcd_puts("LCD Text Zeile 2\n");// Zeile 2
19
lcd_puts("LCD Text Zeile 3\n");// Zeile 3
20
lcd_puts("LCD Text Zeile 4\n");// Zeile 4
21
_delay_ms(5000);// kurz warten
22
}
Es ist keine Rechtfertigung.
Genug dazu, möchte nicht vom 100 ins 1000 kommen. Habe Fehler gemacht,
Asche aufs Haupt, schäme mich, trotzdem möchte ich wissen wo mein Fehler
liegt.
achim
Achim Seeger schrieb:> Den Code habe ich gepostet, steht ziemlich weit oben. Habe ihn noch mal> eingetragen:
Es wird immer grotesker. Es geht um den Code, der "durchlaufenden Mist"
zur Folge hat. Genau darum hat "Bitkracherl" gestern Abend (und vorhin
nochmal) gebeten.
Achim Seeger schrieb:> Hallo> Den Code habe ich gepostet, steht ziemlich weit oben. Habe ihn noch mal> eingetragen:
Dieser Code ist mittlerweile sowas von uninteressant.
> trotzdem möchte ich wissen wo mein Fehler liegt.
Das LCD hat, so wie alle Computer, einen linearen Speicher.
D.h. da liegt Speicherzelle an Speicherzelle. Und zwar als eine lange
Wurscht.
1
+---+---+---+---+---+---+---+---+---+---+---+...
2
| | | | | | | | | | | |
3
+---+---+---+---+---+---+---+---+---+---+---+...
Schreibt man in eine Speicherzelle was rein ...
1
+---+---+---+---+---+---+---+---+---+---+---+...
2
| | |'H'| | | | | | | | |
3
+---+---+---+---+---+---+---+---+---+---+---+...
dann taucht das am Display auf.
Schön.
Nur wird das nicht so dargestellt. Denn schliesslich ist ja deine
Glasfläche nicht eine lange Wurscht, sondern in 4 Zeilen organisiert.
D.h. es gibt eine logische Aufteilung des Speichers ...
1
|<------------ Zeile 1 ---->|<--- Zeile 2 ------
2
+---+---+---+---+---+---+---+---+---+---+---+...
3
| | | | | | | | | | | |
4
+---+---+---+---+---+---+---+---+---+---+---+...
in die physikalischen Zeilen. Schreibt man an diese Position das 'H' in
den Speicher
1
|<------------ Zeile 1 ---->|<--- Zeile 2 ------
2
+---+---+---+---+---+---+---+---+---+---+---+...
3
| | | | | | | |'H'| | | |
4
+---+---+---+---+---+---+---+---+---+---+---+...
dann taucht das als erstes Zeichen in der zweiten Zeile auf.
Genau diese Umrechnung macht zb lcd_gotoxy. Es errechnet wo, beginnend
ab dem Anfang des kompletten Speichers, die Speicherzelle ist, die der
angegebenen Spalten/Zeilenposition entspricht.
Nur muss lcd_gotoxy dazu natürlich wissen, wo im Speicher die Zeile 2
anfängt. In der Zeichnung hier ist es die Speicheradresse ...
1
|<------------ Zeile 1 ---->|<--- Zeile 2 ------
2
+---+---+---+---+---+---+---+---+---+---+---+...
3
| | | | | | | |'H'| | | |
4
+---+---+---+---+---+---+---+---+---+---+---+...
5
0 1 2 3 4 5 6 7 8 9
... 7
Soll die Ausgabe also in der Zeile 2, Spalte 3 anfangen, dann ist die
zugehörige Speicheradresse 7 + 3 gleich 10. Dorthin setzt lcd_gotoxy den
Cursor und dort landet dann die nächste Ausgabe. Im Speicher ist es die
Adresse 10, auf dem LCD-Glas ist es die Zeile 2, Spalte 3
Jetzt kommt das Problem:
Man muss wissen, wo genau im Speicher dieser Punkt ist. An welcher
Adresse die Zeile 2, die Zeile 3 bzw. die Zeile 4 anfangen.
Dsa sind diese Konstanten
1
#define LCD_START_LINE1 0x00 /**< DDRAM address of first char of line 1 */
2
#define LCD_START_LINE2 0x40 /**< DDRAM address of first char of line 2 */
3
#define LCD_START_LINE3 0x14 /**< DDRAM address of first char of line 3 */
4
#define LCD_START_LINE4 0x54 /**< DDRAM address of first char of line 4 */
normalerweise passen die auch für die meisten LCD. Nur bei deinem passen
diese Werte eben anscheinend nicht. Also müssen wir sie ermitteln.
Die Grafik zeigt auch schon die prinzipielle Idee, die benutzt wird. Wir
schreiben den Speicher einfach voll
1
+---+---+---+---+---+---+---+---+---+---+---+...
2
| A | B | C | D | E | F | G | H | I | J | K |
3
+---+---+---+---+---+---+---+---+---+---+---+...
4
0 1 2 3 4 5 6 7 8 9
Beginnend ganz vorne einfach einen Buchstaben nach dem anderen in den
Speicher. Das können wir, weil sich das LCD an dieser Stelle nicht darum
kümmert, wo die Zeilengrenzen sind, sondern einfach Buchstabe für
Buchstabe in den Speicher schreibt.
Gut. Nachdem der Speicher so angefüllt wurde, schaut man aufs Display
und sieht
1
+-------+
2
| ABCDE |
3
| HIJKL |
4
| |
5
| |
6
+-------+
Da das erste sichtbare Zeichen in der zweiten Zeile das 'H' ist, weiß
ich damit, dass in
1
+---+---+---+---+---+---+---+---+---+---+---+...
2
| A | B | C | D | E | F | G | H | I | J | K |
3
+---+---+---+---+---+---+---+---+---+---+---+...
4
0 1 2 3 4 5 6 7 8 9
hier
1
|
2
v
3
+---+---+---+---+---+---+---+---+---+---+---+...
4
| A | B | C | D | E | F | G | H | I | J | K |
5
+---+---+---+---+---+---+---+---+---+---+---+...
6
0 1 2 3 4 5 6 7 8 9
die Startadresse der zweiten Zeile im LCD_Speicher ist. Nämlich die 7.
Die trag ich ins lcd.h für die zweite Zeile ein und fortan weiss dann
auch lcd_gotoxy, dass es in die zweite Zeile kommt, wenn es bei 7
beginnend die Spalten weiter zählt.
Erst mal wieder Danke für KH, jetzt ist es klar was du machen willst,
sorry, war mir unklar. Mache es sofort, wenn ich am teilsitze.
Auch der Code von KH steht drin. meine diesen
ok, danke.
Lass uns mal Plan B probieren
int main()
{
lcd_init(LCD_DISP_ON); // Display initialisieren
lcd_puts(
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789" );
while( 1 )
;
}
Danach kam diese Ergebis:
+----------------------------------+
| ABCDEF0GHIJKL0MNOPQR0STUVW0XYZa0 |
| MistMistMistMistMistMistMistMist |
| MistMistMistMistMistMistMistMist |
| |
+----------------------------------+
Die erste Zeile wurde ganz korrekt dargestellt. In der 2. und 3. Zeile
nur Mist. Muss nach dem letzten korrekten Buchstaben schauen.
achim
http://www.farnell.com/datasheets/50586.pdf
Seite 43 :
When 1-line display mode (N = 0), DDRAM address is from "00H" to "4FH".
In 2-line display mode (N = 1), DDRAM address in the 1st line is from
"00H" to "27H", and
DDRAM address in the 2nd line is from "40H" to "67H".
Nur mal so aus Interesse, wenn man nun ein Datenblatt zu einem Display
hat,
wie rechnet man dann die Adressen aus ?
(1 Line Mode)
MaxAdresse / AnzahlLines = Schritte
0x4F (+1) / 0x04 = 0x14
1. 0x00
2. 0x14
3. 0x28
4. 0x3C
Wäre das so richtig oder ist das Mist ?
Hi
>Wäre das so richtig oder ist das Mist ?
Mist.
Den Bereich 0x00 bis 0x27 teilen sich Displayzeile 1 und 3. Der Inhalt
von 0x40 bis 0x67 wird in Displayzeile 2 und 4 dargestellt. Damit kommt
man auf die o.g. Anfangsadressen:
>#define LCD_START_LINE1 0x00>#define LCD_START_LINE2 0x40>#define LCD_START_LINE3 0x14>#define LCD_START_LINE4 0x54
MfG Spess
Ich meinte den 1 Line Mode "00H" to "4FH" und nicht den 2 Line "00H" to
"27H" + "40H" to "67H".
Gut gut, also die Berechnung an und für sich war richtig.
Tschuldigung für's stören.
Achim Seeger schrieb:> Danach kam diese Ergebis:
Ja.
Da war aber der Fehler noch enthalten, dass
#define LCD_WRAP_LINES 1
noch auf 1 stand. Damit war der Test unbrauchbar, weil lcd_puts nicht
einfach nur die Character ausgegeben hat, sondern sich in diese Ausgabe
mit dazwischen gestreuten lcd_gotoxy eingemischt hat. Das können wir
aber nicht brauchen. Daher
#define LCD_WRAP_LINES 0
> Die erste Zeile wurde ganz korrekt dargestellt. In der 2. und 3. Zeile> nur Mist. Muss nach dem letzten korrekten Buchstaben schauen.
Die Information, die jetzt als erstes wichtig ist:
Hat mit dem umstellen dieses #define diese Durchlauferei aufgehört oder
nicht.
Ich hoffe mal, dass es aufgehört hat.
Hallo
auf ein neues. Habe die entsprechenden Sachen geändert. Stelle die sache
mit rein.
1
#define LCD_START_LINE1 0x00 /**< DDRAM address of first char of line 1 */
2
#define LCD_START_LINE2 0x40 /**< DDRAM address of first char of line 2 */
3
#define LCD_START_LINE3 0x14 /**< DDRAM address of first char of line 3 */
4
#define LCD_START_LINE4 0x54 /**< DDRAM address of first char of line 4 */
5
#define LCD_WRAP_LINES 0 /**< 0: no wrap, 1: wrap at end of visibile line */
Wenn ich diese Sache eingebe erscheint die nachfolgende Ausgabe
1
lcd_gotoxy(0,0);
2
lcd_puts("1-1-1-1-1");
3
4
lcd_gotoxy(0,1);
5
lcd_puts("2");
6
7
lcd_gotoxy(0,2);
8
lcd_puts("3");
9
10
lcd_gotoxy(0,3);
11
lcd_puts("4-4-4-4-4");
+----------------------------------+
| 1-1-1-1-1 |
| 2 |
| 3 |
| 4-4-4-4-4 |
+----------------------------------+
Mit dieser Ausgabe sind die Zeichen korrekt
Gebe ich aber den Text ein
wird das ganze Display damit gefüllt, aber anders als erwartet
+----------------------------------+
| ABC ... ... RST | Zeile 1
| opq ... ... 90A | Zeile 2
| UVW ... ... lmn | Zeile 3
| 1A2 ... ... B1V | Zeile 4
+----------------------------------+
Mit dieser Ausgabe sind die zeilen 2 und 3 vertauscht
Zwei verschiedene Ausgaben? Sorry, jetzt passe ich langsam
achim
> wird das ganze Display damit gefüllt, aber anders als erwartet
Von dir vielleicht.
Ich hab genau das erwartet.
Denn kein Mensch sagt, dass im Speicher hinter der Zeile 1 die Zeile 2
anfangen muss.
Und das tut es auch nicht, wie das Testprogramm eindrucksvoll beweist.
> Mit dieser Ausgabe
Mit dieser Ausgabe ist vor allen Dingen eines dokumentiert: Das sich das
Programm an der Zeilensteuerung vorbeimogelt und uns den internen
Speicheraufbau so zeigt, wie er wirklich ist. Dieses Programm weiß
nichts von Zeilen.
Lass die Wrap-Steuerung abgeschaltet.
In Wirklichkeit ist die nämlich sowieso zu nichts nütze. Das sieht nur
auf den ersten Blick so aus, als ob ein automatischer Zeilenumbruch eine
tolle Sache wäre. Tatsächlich braucht das aber auf so kleinen LCD
keiner, weil keiner derartige lange Texte (und auch wieder kurz, denn
länger als 4 Zeilen darfs nicht sein) ausgibt.
Der normale Weg ist: lcd_gotoxy um den Cursor an eine Position zu
schicken und dann dort den Messwert ausgeben. Cursor mit lcd_gotoxy an
eine andere Position und dort dann einen anderen Messwert ausgeben. usw.
usw.
Bitwackler schrieb:> Huch! Mach ich gerade einen Denkfehler, Karl Heinz?
Nein, ich rechne auch grad nach.
Seine ausgabe ist
1
0123456789ABCDEF
2
3
0 ABCDEFGHIJKLMNOP
4
1 QRSTUVWXYZabcdef
5
2 ghijklmnopqrstuv
6
3 w1234567890A1A2A
7
4 3A4A5A6A7A8A9B1V
Der Umbruch von T auf U findet bei Adresse 0x14 statt. Soweit passt das.
Das war zu erwarten (Zeile 3)
Aber der Umbruch von n auf 0, also in die Zeile 2, wäre an Adresse 0x28.
Und das ist eigentlich unlogisch.
Auf der anderen Seite ist das Testprogramm
1
lcd_gotoxy(0,0);
2
lcd_puts("1-1-1-1-1");
3
4
lcd_gotoxy(0,1);
5
lcd_puts("2");
6
7
lcd_gotoxy(0,2);
8
lcd_puts("3");
9
10
lcd_gotoxy(0,3);
11
lcd_puts("4-4-4-4-4");
eigentlich recht eindeutig. Wenn gotoxy( 0, 1 ) korrekt in Zeile 2
positioniert, dann sollte 0x40 eigentlich stimmen (zumal das ja auch der
Normalfall ist).
Bitwackler schrieb:> Aber wie gesagt. Entweder das erste ist korrekt ODER das zweite.> Irgendwas ist da faul:
Vielleicht sind auch IC-intern die Adressen nicht sauber auskodiert.
Obwohl: wie das bei 0x28 und 0x40 gehen soll, ist mir nicht ganz klar
:-)
Wie sind eigentlich LCD_LINES und KS0073_4LINES_MODE definiert bei Dir,
Achim?
@ Karl Heinz
Im Code wird mit dem Wrap eigentlich nur das neusetzen des der DRAM
adresse gesteuert. Das newline aber trotzdem ausgewertet und die Adresse
neu gesetzt. Bin noch beim gucken.
Habe die Lines geändert in
L1 0x00
L2 0x28
L3 0x14
L4 0x3c
Anzeige bei beiden Version gleich, Reihenfoge nicht geändert.schicke dir
die lcd.h sofort, steht auch oben im Text. Unterschid zur jetzigen nur
warp =0
achim
>Anzeige bei beiden Version gleich, Reihenfoge nicht geändert.
Das kann nicht sein. Das zweite Programm sollte eigentlich dann eine
andere Ausgabe liefern.
Wir haben also insgesamt einen vierfachen Widerspruch.
Nur eine von den vier Aussagen kann stimmen.
1. Das hier Beitrag "Re: Komisches Verhalten mit lcd_puts" liefert
eine fehlerhafte Ausgabe
2. Das erste Programm hier
Beitrag "Re: Komisches Verhalten mit lcd_puts" liefert eine
korrekte Ausgabe
3. Das zweite Programm hier liefert die angegebene Ausgabe
4. Das hier Beitrag "Re: Komisches Verhalten mit lcd_puts" liefert
eine die Ausgabe wie unter 3. für das zweite Programm angegeben.
Das deutet darauf hin, das Du nicht immer das HEX-File programmierst,
das Du annimmst.
Führe den Test von Beitrag "Re: Komisches Verhalten mit lcd_puts"
noch einmal durch. Lösche aber bevor Du beginnst im Explorer das HEX
File. Versichere Dich das es tatsächlich weg ist und nicht versehentlich
ein anderes geflasht wird, in dem Du so tust als wolltest Du flashen.
Lösche das HEX-File nocheinmal, nachdem Du den ersten Test durchgeführt
hast. Versichere Dich wieder das es wirklich weg ist.
Dann führe den zweiten Test aus.
Aus dem Datenblatt vom HD44780
However, when N is 0 (1-line display), AAAAAAA can be 00H to 4FH. When N
is 1 (2-line display),
AAAAAAA can be 00H to 27H for the first line, and 40H to 67H for the
second line.
Mit dem Display ist alles in Ordnung und die Offsets aus dem ersten
Progamm
stimmen. Bei vierzeiligen Displays ist die Reihenfolge
Zeile 1 vorderer Teil
Zeile 2 vorderer Teil
Zeile 1 hinterer Teil
Zeile 2 hinterer Teil
Das Display hat intern also gar keine 4 Zeilen! Es sind nur zwei.
Warum die Anordnung so gewählt wurde hat wohl irgendwelche Gründe.
Als nächstes versuchst Du dann mal folgendes:
Setze LCD_CONTROLLER_KS0073 auf 1.
Setze die Zeilenadressen wieder auf die ursprünglichen Werte zurück.
An sich nämlich kann ein HD44780 nur eine oder zwei Zeilen behandeln.
Das spielt für eine fortlaufende Ausgabe wie "ABCD...." keine Rolle,
wenn es auch die Reihenfolge verwürfelt. Aber es führt zu Fehlern bei
gotoxy.
>Es könnte eine Erklärung sein, so wie du die Zeilen angibst. Es doch den
HD 44780. Wie ist eine Darstellung damit möglich?
Was könnte eine Erklärung sein und wofür?
Wie gebe ich Zeilen an und wo?
Was heisst: "Es doch den HD 44780."
Von welcher Darstellung schreibst Du? Was meinst Du mit der Frage?
Tut mir leid, aber ich verstehe das überhaupt nicht. Das sind, bis auf
den letzten, völlig ungrammatikalische Sätze und dem ersten und letzten
fehlt der inhaltliche Kontext.
>Holger, das wissen wir schon. Siehe
Worüber diskutiert ihr dann noch?
Wenn man 80 Zeichen schreibt springt das Display
ab Stelle 0x28 automatisch auf 0x40. Basta.
>>Worüber diskutiert ihr dann noch?>>Lies den Thread. Dann weisst Du es.
Ab hier
Beitrag "Re: Komisches Verhalten mit lcd_puts"
baust du nur noch scheisse.
Deine Offsets sind falsch. Deine Annahmen sind falsch.
Wieso soll er einen Ks0073 einstellen?
Bullshit.
>Tja Holger, du hast es als Bo.. bezeichnet, damit stehst du in der>Pflicht was besseres zu zeigen.
Du hast doch jetzt gesehen das dein Kram funktioniert
wenn du lcd_gotoxy() benutzt. Also bleib dabei.
Das mit dem automatischen Zeilenvorschub scheint
bei dir aus irgendwelchen Gründen nicht zu funktionieren.
Also benutze das nicht.
Das hier ist korrekt. Genau so passt das für dein Display.
#define LCD_START_LINE1 0x00 /**< DDRAM address of first char of
line 1 */
#define LCD_START_LINE2 0x40 /**< DDRAM address of first char of
line 2 */
#define LCD_START_LINE3 0x14 /**< DDRAM address of first char of
line 3 */
#define LCD_START_LINE4 0x54 /**< DDRAM address of first char of
line 4 */
Dein Display hat keinen KS0073. Also bleibt das define auf 0.
Schreib nicht über das Ende einer Zeile hinaus und erwarte nicht
das der nächste Buchstabe eine Zeile weiter unten am Anfang der Zeile
erscheint.
So, und jetzt kannst du glaube ich ohne Probleme das mit deinem
Display machen was du möchtest.
Soweit klar. Gibt aber noch was ich nicht versteh, hatten gestern das
Thema
lcd_puts("2\n");
Damit müsste Zeilenvorschub erfolgen. Geht auch von Zeile 1 auf 2, aber
mehr nicht. Wieso?
Das hier könnte es erklären :
http://www.sprut.de/electronic/lcd/#4x20
[...]
4x20 Display
Vierzeilige Displays mit bis zu 20 Zeichen pro Zeile lassen sich mit
nur einem Controller und zusätzlichen Displaytreibern aufbauen. Das 4x20
Display ist eigentlich ein 2x40 Display, das in der Mitte
durchgeschnitten wurde, und bei dem dann die hinteren Hälften der Zeilen
unter den vorderen Hälften der Zeilen angebracht wurde. Wenn man also
dem Controller Daten für die 1. Zeile übergibt, so werden davon die
ersten 20 Zeichen wirklich in die 1. Zeile geschrieben, während Zeichen
21 bis 40 in die 3. Zeile gelangen. Genauso gehören die 2. und 4. Zeile
des Displays eigentlich hintereinander.
[...]
So, nachdem wir Holger verabschiedet haben, kann's weitergehen.
Das Problem iat, dass wir mit dem abschalten des Wrappings auch das
weitersetzen der Zeilenanfangsadressen ausser Betrieb gesetzt haben.
Setze LCD_WRAP_LINES wieder auf 1.
1
#define LCD_WRAP_LINES 1 /**< 0: no wrap, 1: wrap at end of visibile line */
Setze LCD_CONTROLLER_KS0073 wieder auf 0. Das ist wichtig!
Setze die Zeilenanfänge so wie ich sie beschrieben habe.
L1 0x00
L2 0x28
L3 0x14
L4 0x3c
Dann probiere dieses Programm noch einmal.
>So, nachdem wir Holger verabschiedet haben, kann's weitergehen.
Träum weiter;)
>Die Reihenfolge sollte jetzt stimmen.
Wird sie nicht. Dazu muss man kein Hellseher sein.
Zeile 2 und Zeile 3 werden vertauscht bleiben.
Die Gründe habe ich oben schon genannt. Aber du verstehst das ja nicht.
>Aber du verstehst das ja nicht.
Nein. Tatsächlich. Das verstehe ich nicht.
Schau Dir mal den Code an: (Die Funktion wird für jedes Zeichen des
Strings aufgerufen.
1
voidlcd_putc(charc)
2
{
3
uint8_tpos;
4
5
6
pos=lcd_waitbusy();// read busy-flag and address counter
7
if(c=='\n')
8
{
9
lcd_newline(pos);
10
}
11
else
12
{
13
#if LCD_WRAP_LINES==1
14
#if LCD_LINES==1
15
if(pos==LCD_START_LINE1+LCD_DISP_LENGTH){
16
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE1,0);
17
}
18
#elif LCD_LINES==2
19
if(pos==LCD_START_LINE1+LCD_DISP_LENGTH){
20
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE2,0);
21
}elseif(pos==LCD_START_LINE2+LCD_DISP_LENGTH){
22
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE1,0);
23
}
24
#elif LCD_LINES==4
25
if(pos==LCD_START_LINE1+LCD_DISP_LENGTH){
26
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE2,0);
27
}elseif(pos==LCD_START_LINE2+LCD_DISP_LENGTH){
28
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE3,0);
29
}elseif(pos==LCD_START_LINE3+LCD_DISP_LENGTH){
30
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE4,0);
31
}elseif(pos==LCD_START_LINE4+LCD_DISP_LENGTH){
32
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE1,0);
33
}
34
#endif
35
lcd_waitbusy();
36
#endif
37
lcd_write(c,1);
38
}
39
40
}/* lcd_putc */
Wenn die pos stimmt, die zurückgegeben wird, dann sollte der Mechanismus
mit dem weitersetzten der Zeilen eigentlich funktionieren.
Da bei dem Test oben der Mechanismus ausser Betrieb war, konnte man
tatsächlich die Positionen der Zeichen abzählen und die Offsets waren
korrekt.
>Träum weiter;)
Davon träumst Du vielleicht, das ich von Dir träume. Eine höfliche
Verabschiedung scheinst Du nicht zu verstehen.
Habe das gemacht, Einstellungen geändert und das Prg gestartet. Anzeige
ist wie gehabt. Beide zeilen sind vertauscht.
Noch was, bleibt bitte beide sachlich, es bringt nichts, wenn wir banal
uns die Köpfe einschlagen. Wir versuchen gemeinsam ein problem zu lösen.
Dazu zählt auch der Austausch von Gedanken und Vorschlägen, aber bitte
sachlich mit einem Anteil von Vernunft. Danke
>Wenn die pos stimmt, die zurückgegeben wird, dann sollte der Mechanismus>mit dem weitersetzten der Zeilen eigentlich funktionieren.
Dann lies mal noch mal bei mir nach.
Die zweite Zeile beginnt im zwei Zeilen Modus bei 0x40.
Das ist FAKT. Deine Offsets stimmen einfach nicht.
Ich tu dir aber den Gefallen und halte mich ab hier raus.
Wird bestimmt lustig einfach nur weiter zu lesen;)
@ Holger
>Die zweite Zeile beginnt im zwei Zeilen Modus bei 0x40.
Das aber hatte auch eine Vertauschung ergeben. Siehe hier:
Beitrag "Re: Komisches Verhalten mit lcd_puts"
Wie erklärst Du Dir das?
> Noch was, bleibt bitte beide sachlich, es bringt nichts, wenn wir banal> uns die Köpfe einschlagen.
Nur nebenbei: der eine oder andere eingeschlagene Kopf wäre wirklich
eine Banalität.
Aber was ist mit der Website los - ich kann derzeit jedes ankommende
Byte per Handschlag begrüßen.
Sorry, hab was zu essen geholt, die Sache macht hunrig
Das gleiche ergebnis, verfolge gerade eine andere Sache. Da sich die
Anzeige nicht ändert, vermute ich, das ich die Datein ändere aber aus
einem unbekannten Grund auf andere datein zugegrioffen wird. habe
Verzeichnis kontrolliert und such dabei noch
>Das gleiche ergebnis,
Wenn die Zeilen bei der Gegenprobe immer noch vertauscht sind, dann
stimmt irgendwas mit pos nicht, denke ich.
Das mit dem versehentlich falschen Datei, kannst Du sicherstellen in dem
Du immer die HEX-Datei löschst und vor dem neuen compilieren den
Flash-Vorgang startest. Es sollte keine HEX-Datei mehr in dem Dialogfeld
zu sehen sein. (Ich vermute allerdings nur, das Du AVRSTudio 4
verwendest).
Um das zu diagnostizieren, möchte ich die Variable pos ausgeben.
Allerdings sind das ja möglicherweise grössere Zahlen als 9 bzw. f.
Daher will ich die Zahl in ein Zeichen umwandeln, welches das Display
darstellen kann.
Ändere als einmal die Funktion wie folgt ab.
1
voidlcd_putc(charc)
2
{
3
uint8_tpos;
4
5
6
pos=lcd_waitbusy();// read busy-flag and address counter
7
if(c=='\n')
8
{
9
lcd_newline(pos);
10
}
11
else
12
{
13
#if LCD_WRAP_LINES==1
14
#if LCD_LINES==1
15
if(pos==LCD_START_LINE1+LCD_DISP_LENGTH){
16
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE1,0);
17
}
18
#elif LCD_LINES==2
19
if(pos==LCD_START_LINE1+LCD_DISP_LENGTH){
20
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE2,0);
21
}elseif(pos==LCD_START_LINE2+LCD_DISP_LENGTH){
22
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE1,0);
23
}
24
#elif LCD_LINES==4
25
if(pos==LCD_START_LINE1+LCD_DISP_LENGTH){
26
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE2,0);
27
}elseif(pos==LCD_START_LINE2+LCD_DISP_LENGTH){
28
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE3,0);
29
}elseif(pos==LCD_START_LINE3+LCD_DISP_LENGTH){
30
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE4,0);
31
}elseif(pos==LCD_START_LINE4+LCD_DISP_LENGTH){
32
lcd_write((1<<LCD_DDRAM)+LCD_START_LINE1,0);
33
}
34
#endif
35
lcd_waitbusy();
36
#endif
37
lcd_write((pos<0x5E)?(pos+0x21):(pos+0xA1),1);
38
}
39
40
}/* lcd_putc */
So bekommen wir für jede Position ein eigenes Zeichen. Anhand der Lage
des Zeichens auf dem Display und dem Zeichen selbst können wir dann
erkennen, ob welche Adresse das Display jeweils annimmt, bevor es ein
Zeichen ausgibt.
Hi
>Das hat ja früher auch eine Vertauschung ergeben.
Das sind aber die üblichen Zeilenanfänge bei einem 4x20 Display:
http://www.lcd-module.de/pdf/doma/4_20.pdf
MfG Spess
Mir ist was aufgefallen. Die Datei lcd.c und lcd.h sollen im gleichen
Ordner sein. sind sie. Wenn ich ein neues Programm schreibe, gebe ich
den Standort an. Danach scheint das programm sich die Datein zu holen
und zusätzlich noch mal in das verzeichnes des Programmes zu schreiben.
Wenn es dann das alte nimmt, kann ich ändern so viel ich will es wird
nichts. Muss noch einiges kontrollieren, wenn nicht muss ich einiges
löschen. Will das Programm zwinen was neues zu nehmen.
achim
@ Spess53
> Das sind aber die üblichen Zeilenanfänge bei einem 4x20 Display:
Das mag sein. Aber worauf willst Du mit Deinem Beitrag hinaus? Ich kann
mir da nichts bei denken. Meinst Du es findet keine Vertauschung statt?
Oder was willst Du sagen?
Im Moment haben wir zwei offene Punkte, denke ich:
1. Der TO macht irgendeinen Fehler beim compilieren und flashen
2. Es stimmt was mit dem Rückgabewert von lcd_waitbusy() nicht.
Siehst Du noch eine Möglichkeit, die man prüfen könnte? Oder meinst Du
es ist sinnlos das zu prüfen?
Hi
>Das mag sein. Aber worauf willst Du mit Deinem Beitrag hinaus?
Darauf, das z.B. solche Aussagen
>L1 0x00>L2 0x28>L3 0x14>L4 0x3c
schlichtweg falsch sind.
Hilfreich wäre es auch, wenn der TO mal den genauen Typ des Displays
bekanntgeben würde.
MfG Spess
>>Das mag sein. Aber worauf willst Du mit Deinem Beitrag hinaus?>>Darauf, das z.B. solche Aussagen>>>L1 0x00>>L2 0x28>>L3 0x14>>L4 0x3c>>schlichtweg falsch sind.
Sag ich doch schon die ganze Zeit;)
>Hilfreich wäre es auch, wenn der TO mal den genauen Typ des Displays>bekanntgeben würde.
PC2004. Hast du oben wohl übersehen.
Aber nun ist er schlafen gegangen. Muss früh raus der arme Kerl.
@ Spess53
>Darauf, das z.B. solche Aussagen ... schlichtweg falsch sind.
Auch das mag so sein. Es spricht sogar vieles dafür. Zugegeben.
Andererseits ist diese Aussage auch nicht völlig aus der Luft gegriffen,
wenn Du Dir das Testergebnis hier
Beitrag "Re: Komisches Verhalten mit lcd_puts" anschaust.
>Hilfreich wäre es auch, wenn der TO mal den genauen Typ des Displays>bekanntgeben würde.
Das sehe ich genauso und diese Frage wurde hier schon gestellt und
beantwortet. Siehe Beitrag "Re: Komisches Verhalten mit lcd_puts"
Leider hat uns das, wie Du in den darauf folgenden Beiträgen sehen
kannst, nicht viel weitergebracht, weil wir kein Datenblatt finden
können.
Spess, ich halte Dich für kompetent, aber ich sehe nicht, wie uns Deine
Beiträge bis jetzt, auf irgendeine Weise weiterbringen. Auch meine ich
nicht, das es Anzeichen dafür gibt, das ich (oder wir) uns auf eine
Annahme versteift haben, so das es nötig wäre, andere Gesichtspunkte
einzubringen.
>Leider hat uns das, wie Du in den darauf folgenden Beiträgen sehen>kannst, nicht viel weitergebracht, weil wir kein Datenblatt finden>können.
Hmmmm:
Beitrag "Re: Komisches Verhalten mit lcd_puts"
>Sag ich doch schon die ganze Zeit;)
Schon recht.
Aber Du und Spess müsst doch auch sehen, dass das was bisjetzt immer so
war,
doch auch einmal anders sein kann. Damit muss man doch vernünftiger
Weise rechnen. Das ist doch ein wenig unvernünftig, hier in der Manier,
das nicht sein kann, was nicht sein darf, immer wieder das selbe zu
wiederholen.
Und wie gesagt: Es hat sich ja auch niemand darauf versteift. Wo ist
etwas anderes erkennbar hier? Falls sich herausstellt, das diese
Adressen falsch sind, dann wird das eben geändert. Wir/ich sind doch
noch dabei, das Problem zu lösen.
@ Holger
Oh weh. Dumm gelaufen.
In dem Beitrag wurde das nicht als Datenblatt für den gesuchten Typ
benannt und die Frage war so gestellt, als wenn es sich um eine nicht
direkt zum Thema gehörige Seitenfrage handelt. Ich hatte gestern
nichtmal in die Datei geschaut.
Das ist mir und Karl Heinz entgangen.
Danke.
Gut. Dann dürfte das mit den Adressen wohl erledigt sein.
Bleibt also noch das beim Compilieren oder flashen was schiefgeht.
Hi
>PC2004. Hast du oben wohl übersehen.
Das hab ich wohl. Musste zwischendurch jemand zum Krankenhaus fahren.
PC2004: 4x20 von Powertip mit ST7066U Controller.
Am ST7066U kann es aber nicht liegen. Das ist einer der vielen
kompatiblen zum HD44780.
MfG Spess
Guten morgen an alle
Habe noch was gefunden, was ich nicht verstehe. Wenn ich ein neues
prigramm schreibe, gebe ich das Verzeichnis an, in dem sich lcd.c und
lcd.h befinden. Compiliere das Programm, es wird eine hex und elf
erzeugt und gleichzeitig speichert sich das AVR Studio die Datein lcd.c
und lcd.h nochmal in das gleiche Verzeichnis in dem sich auch das
eigentliche Programm befindet. Wird danach die lcd.c und lcd.h
verändert, wird die Änderung nicht beachtet, da die beiden anderen
genommen werden. Habe danach auch diese geändert, an einigen stellen
auch gelöscht. Jetzt bekomme ich teilweise Fehlermeldungen, auch wenn
ich das Programm neu erstelle. Der zusammanhang ist mir unklar, warum so
oder so. Werde einiges neu aufsetzen müssen und neue Programme anlegen.
Bitte ein wenig geduld. Werde sfort berichten
achim
Schreibe uns bitte mal, welches AVRStudio Du verwendest.
Es gibt nämlich verschiedene Versionen davon.
Leider kenne ich mich nur mit der Version 4 wirklich gut aus.
Eine weitere Möglichkeit Dir zu helfen ist, dass Du mal das gesamte
Projektverzeichnis in eine ZIP-Datei packst (komprimierst) und hier als
Anhang postest.
Wenn ich so überlege, dann ist das durchaus ein sinnvolles Verhalten.
Du lädst C-Dateien aus dem Netz herunter. Beispielsweise in den Ordner
"Downloads". Dann legst Du ein neues Projekt unter sagen wir "Eigene
Dateien\Projekte\LCD" an. Nun gibst Du als eine der Quellcodedateien,
die C-Datei in "Downloads" an. AVRStudio kopiert sie sich in das
LCD-Verzeichnis.
Die Dateien unter Download bleiben original und man kann sie für weitere
Projekte verwenden.
Habe ich zwar noch nicht gesehen, aber das wäre doch sehr nützlich.
>Habe danach auch diese geändert, an einigen stellen>auch gelöscht. Jetzt bekomme ich teilweise Fehlermeldungen, auch wenn>ich das Programm neu erstelle.
Wenn ich recht verstehe, dann ging es aber, bevor Du die Dateien
geändert hast? Das ist schon mal gut.
Dann stelle die Originaldateien wieder her und kompilieren das Programm
mit der ABC-Ausgabe. Falls Fehlermeldungen kommen, bitte posten.
>Ich verwende das AVR Studio 6
Ah. Na dann kann ich nur nach allgemeinen Grundsätzen raten:
Mache es einfach so, wie Du es vorher gemacht hast.
Aber ändere nur die Kopie von lcd.h in dem Projektverzeichnis.
Das sollte eigentlich super funktionieren.
Lasse mich überraschen, was will ich auch machen. Nach altbewährter
Methode, das grösste Problem sitzt vor dem Monitor .. , bin ich offen
für alles
achim
>Lasse mich überraschen, was will ich auch machen. Nach altbewährter>Methode, das grösste Problem sitzt vor dem Monitor .. , bin ich offen>für alles
Worauf bezieht sich das? Was für einen Rat brauchst Du jetzt? Welches
Problem steht an?
Bleib erst mal ganz ruhig. Du brauchst eine Pause. Ich muss was tun.
Besonders die Programme in Ordnung bringen, die Verzeichnisse der
einzelnen und testen ob der Aufruf wirklich so ist, wie vermutet. Könnte
ja sein, das es sogar irgendwo steht. Das Problem steht von mir. Ihr
habt mehr getan als ich jemals erwartet hätte. Für das bis hier auf
jeden Fall besten Dank. Habe versprochen, das ich berichte und das werde
ich auch machen. Danke
achim
Hallo
so, habe meinen Fehler gefunden und alle Datein von gestern wieder in
Ordnung gebracht. Habe an der stelle weitergemacht. Egal welche Adresse
ich angebe
0x40
0x00
0x14
0x54
oder
0x00
0x28
0x14
0x3c
bei dem Text mit ABCD .. und so weiter, ist die Anzeige
Zeile 1
Zeile 3
Zeile 2
Zeile 4
Bei der Angabe von lcd_gotoxy erscheint
1
2
3
4
Komme auf den Beitrag von oben zurück. Verwende nur noch lcd_goto. Dann
klapp es damit. Das andere vergessen wir.
Ansonsten stimmte meine Vermutung. Die beiden lcd.c und lcd.h stehen bei
mir im Ordner "Datein" und diese wird im Programm angegeben. Nach dem
compilieren schreibt sich AVR Studio diese in das Verzeicnis des
Programmes und beachtet die anderen gar nicht mehr. Wieder was neues für
mich. Danke an alle.
achim
Thread beobachten
Seitenaufteilung abschalten