Hallo Leute ich habe die Bibliothek von Ape
[link]Beitrag "KS0108 GLCD Routinen"] auch auf
meinen Atmega32
laufen, nur leider sieht das das Display so aus wie im angehängten Bild.
Hier mal mei n Quellcode vom main.c
Könnt ihr mir sagen warum ich diese weißen Streifen habe?
Kann es ein verkabelungsproblem sein, vielleicht Leitungen vertauscht,
hab eigentlich alles schon 2 mal kontrolliert.
Eigentlich sollte "Ha" da stehen aber es passt nicht so recht.
Wer schön wenn ihr mir helfen könntet.
Hier nochmal das DB vom
Display:http://www.pollin.de/shop/downloads/D120424D.PDF
Auf den ersten Blick würde ich sagen, daß Du die Adressen nicht richtig
hast. Schau mal ins DB, an welcher Adresse die 2. und an welcher die 3.
Zeile liegen und überprüfe mal ob das im Code auch so gemacht wird.
Wenn da ein KS0108 drauf ist, dann ist das ein KS0108, und dann passt
auch die lib. Der hat keine unterschiedlichen Adressen oder Pins für
Zeile 2 oder 3.
Dein Bild sieht so aus, als ob falsche Daten aus dem Controller gelesen
werden (immer nur 0xff). Das nicht alles Weiß wird, liegt vermutlich
daran, daß deine Buchstaben zufällig genau auf einem Zeilenwechsel
enden. Dann wird diese Zeile nicht gelesen, sondern gleich
überschrieben. Das das prinzipiell funktioniert, zeigt schonmal, das die
Beschaltung nicht ganz verkehrt ist.
Mal den R/W-Pin überprüfen, ob da alles richtig ist.
Ansonsten gleicher Tip wie immer: Timing verlangsamen - in der lib NOP's
bei den EN's einfügen, sowie die "little delay"-Schleifen (oder so
ähnlich) deutlich verlängern. Wenn es dann geht, kannst du dich ja
langsam wieder rückwärts an das Optimum rantasten.
Oliver
Oliver wrote:
> Dein Bild sieht so aus, als ob falsche Daten aus dem Controller gelesen> werden (immer nur 0xff).
Das glaub ich eigentlich nicht.
Wenn ich mir das Bild ansehe:
Die ersten 8 Pixelzeilen stimmen
Dann kommt ein Gap von 16 Zeilen, in denen nichts stimmt.
Die nächsten 8 Pixelzeilen, sind diejenigen, die eigentlich an die
ersten 8 anschliessen sollten.
Für mich sieht es so aus, als ob in der 'Page-Adressierung' in der Lib
was nicht stimmt. Die mag mit dem dort verwendeten Controller
funktioniert haben, aber mit dem hier stimmts anscheinend nicht.
> Das das prinzipiell funktioniert, zeigt schonmal, das die> Beschaltung nicht ganz verkehrt ist.
Genau.
Auch das das Display initialisiert ist und was anzeigt zeigt eigentlich
auch, dass keine Vertauschung der Datenleitungen vorliegt. Ansonsten
wären die Initialisierungscommandos sicherlich nicht sauber zum Display
durchgekommen.
Ich denke, dass dieses Display ganz einfach ein anderes Memory Layout
benutzt, als das welches in der verlinkten Lib benutzt wurde.
> Ansonsten gleicher Tip wie immer: Timing verlangsamen -> in der lib NOP's bei den EN's einfügen, sowie die "little delay"-> Schleifen (oder so ähnlich) deutlich verlängern.
Diese Funktion
1
voidks0108Enable(void){
2
volatileuint8_ti;
3
4
LCD_CMD_PORT|=0x01<<EN;// EN high level width: min. 450ns
5
asmvolatile("nop\n\t"
6
"nop\n\t"
7
"nop\n\t"
8
::);
9
LCD_CMD_PORT&=~(0x01<<EN);
10
for(i=0;i<8;i++);// a little delay loop (faster than reading the busy flag)
11
}
ist allerdings auch sträflich leichtsinnig geschrieben. Kann man der
Entstehungszeit der Lib zuschreiben. Aber die sollte schnellstens auf
solide Füsse gestellt werden:
Anzahl der NOP aus der Taktfrequenz ableiten
die 'little delay loop': sorry, aber so geht das gar nicht. Die
Chancen stehen gut, dass der Compiler die einfach rauswirft.
Ein Indiz, dass auch der OP so einige Schwierigkeiten mit dem Timing
hatte, ist für mich diese Stelle:
1
voidks0108SetDot(uint8_tx,uint8_ty){
2
uint8_tdata;
3
4
ks0108GotoXY(x,y);// read data from display memory
Warum da ein dummy read eingefügt werden muss, ist mir nicht ganz klar.
Offenbar war der Chip nach dem ks0108GotoXY noch nicht fertig mit
arbeiten. Der schnelle Fix: Wenns beim ersten mal nicht geklappt hat,
machen wirs halt nochmal, in der Hoffnung das es dann klappt.
Leider komm ich grad nicht ans board um zu schauen was es für ein
Kontroller ist aber mit Bascom und der Ks lib hats einwandfrei
funktioniert.
aber danke kbuchegg, ich werd sehen was sich da machen lässt, dachte
eben das is ne lib auf die ich aufbauen kann und wo ich mich nichtmehr
mit der Displayansteuerung rumschlagen muss...
Komisch das es bei den vielen anderen einwandfrei funktioniert hat und
bei mir nicht, hab das ganze übrigens auch mit 4mhz Takt getestet, war
auch nicht besser
Christian Hohmann wrote:
> aber danke kbuchegg, ich werd sehen was sich da machen lässt, dachte> eben das is ne lib auf die ich aufbauen kann und wo ich mich nichtmehr> mit der Displayansteuerung rumschlagen muss...
Ich hab den Code noch ein wenig überflogen, da sind auch an anderen
Stellen noch dubiose Warteschleifen drinn.
> Komisch das es bei den vielen anderen einwandfrei funktioniert hat und> bei mir nicht, hab das ganze übrigens auch mit 4mhz Takt getestet, war> auch nicht besser
Kann auch Compiler/Versions abhängig sein. Schalte mal den Optimizer vom
Compiler weg.
Karl heinz Buchegger wrote:
> die 'little delay loop': sorry, aber so geht das gar nicht. Die> Chancen stehen gut, dass der Compiler die einfach rauswirft.
Hab übersehen, dass die Schleifenvariable volatile ist.
Ist allerdings eine interessante Fragestellung: Kann der Compiler eine
lokale Variable komplett eliminieren, wenn sie sonst nirgend gebraucht
wird, selbst wenn sie volatile ist?
Sascha wrote:
> Hallo,>> @Karl heinz>> also das mit dem Dummyread steht sogar im Datenblatt so drin.
Danke.
Mangels Datenblatt konnte ich das nicht nachsehen. Aber wenns da auch so
enthalten ist .... ziehe ich den Einwand zurück.
Hat einfach nur seltsam ausgesehen.
Datenblätter zum ks0108 gibt es überall im Netz.
Das mit dem Dummyread ist in der lib nicht ganz optimal implementiert.
Genaugenommen ist das Read-Register gelatcht, beim Lesen wird aber genau
wie beim schreiben der Adresszeiger automatisch inkrementiert, und auch
jedesmal das latch nachgeladen. Beim sequentiellen Schreiben eines
zusammenhängende Blocks in einer Zeile braucht es also eigentlich auch
nur ein Dummy-Read zu Anfang. Die lib prüft aber nicht auf sequentielles
Schreiben, sondern gibt grundsätzlich für jedes byte einzeln die Adresse
neu aus, macht den dummy-Read, und liest dann die Daten. Das bremst
nicht unerheblich, hat aber mit dem Problem der weissen Streifen nichts
zu tun.
>aber mit Bascom und der Ks lib hats einwandfrei funktioniert.
Das zeigt ja, das im Prinzip alles richtig ist.
Wenn du die Möglichkeit hast, über uart Daten auszugeben, dann schreib
mal jede Zeile des Display mit den Werten 0-127 voll, lies das wieder
aus, und gib das ausgelesene über die uart aus. Dann siehst du gleich,
was nicht funktioniert.
Oliver
Hallo,
anbei mal das was ich gefunden habe
> bei Reichelt selbiges Display suchen -> Datenblatt -> im PDF ist dann ein Link
und da hab ich das Datenblatt zum KS0108 gefunden.
also ich habe auch selbiges Display von Pollin am laufen, allerdings
habe ich mir die C-Routinen aus dem von dir verwendeten Paket in ASM
umgeschrieben.
Sascha
Mit dem Datenblatt versteh ich erstmal welches Signal an DB 0-7 für die
einzelnen Befehle anliegen muss.
Warum ich nicht selbst drauf gekommen bin ein anderes DB zu suchen...
Servus leute sitze jetzt endlich wieder am Board und hab erstmal die
Kompileroptimierung abgeschaltet:
http://www.pretty-kunze.de/avroptimum.jpg
Hoffe das ist der richtige Ort zum Abschalten.
Dann wollt ich das ausgeben lassen:
1
ks0108Init();
2
3
ks0108GotoXY(0,0);
4
ks0108PutString("Hallo",smallFont);
5
6
ks0108GotoXY(0,22);
7
ks0108PutString("Das ist ein Test",smallFont);
Und raus kam das: was im Anhang steht.
Ich verzweifel noch wo kann ich jetzt suchen oder was kann ich
probieren???
Ich bin leider noch Anfänger auf dem AVR Gebiet.