Hallo!
Vor kurzem habe ich mit der Mikrocontrollerprogrammierung begonnen. Ziel
ist eine Art Temperatur-Regelung. - Mein Bastlerdrang darf dabei aber
auch nicht zu kurz kommen, also versuche ich, mich auch mit den Basics
auseinanderzusetzen. Ich habe bereits eine funktionierende Schaltung für
einen mega8, einen Programmieradapter (SI-Prog) sowie die ersten
Gehversuche mit LCD-Displays gemacht. Bis dahin kein Problem, jetzt
hakts aber:
Mit der "lcd-routines.h" hier aus dem Wiki konnte ich das Display
erfolgreich initialisieren und erste Zeichen anzeigen, doch statt dem
erhofften "hallo welt" standen nur merkwürdige japanische oder
chinesische Zeichen auf dem Display. Was kann das sein? - gleiches gilt
übrigens für das lcdlibrary von Peter Fleury.
Es handelt sich im übrigen um ein LCD-Display von Conrad, Artikelnummer
183342, Hersteller ANAG VISION. Im Datenblatt steht "KS0066 or
Equivalent".
Ich betreibe das Display wie im beispiel im 4bit-Modus und bin gerade
echt aufgeschmissen.
Interessant war:
Ich habe eine Schleife gebaut und alle Werte von 0 bis 255 auf das
Display schreiben lassen. Je 16 Zeichen waren die ersten vier
unterschiedlich, aber die kommenden vier wiederholten sich. Beispiel:
"0123ABCDABCDABCD", nur dass halt keine normalen Ascii-Zeichen
erscheinten sondern nur diese japanischen.
Habe ich vielleicht ein Timing-Problem? (Ich verwende den mega8 in der
Standardkonfiguration mit internem Oszi)
Wer weiß Rat?
Danke,
Matthias
Du bist wahrscheinlich zu schnell mit der Ausgabe der Daten an das
Display. Einfach mal die Taktrate des Controllers herunternehmen oder
Wartezeiten einbauen.
Hi,
oh stimmt, ich vergass. Ich programmiere unter Linux mit avr-gcc.
Entsprechend gelten die Quellcodes. Ich habe quasi noch nichts eigenes
programmiert, nur eben die oben erwähnten Libs benutzt. Der Quelltext
ist also denkbar kurz (in diesem Fall mit Fleurys lib):
1
#include"lcd.h"
2
3
intmain(void){
4
lcd_init(LCD_DISP_ON);
5
lcd_data('T');
6
lcd_data('e');
7
lcd_data('s');
8
lcd_data('t');
9
10
while(1){}
11
12
return0;
13
}
Natürlich habe ich die lcd.h an meine Bedürfnisse angepasst...
Also am Timing scheint es nicht zu liegen. Wenn ich die Mhz-Zahl im
Quellcode (XTAL bzw. F_CPU) rauf- oder runtersetze, tut sich gar nichts,
das Verhalten bleibt gleich.
Ausprobiert habe ich:
1000000 (dürfte etwa dem internen oszi entsprechen)
4000000 (war Standard im lcdlibrary)
8000000 (verdopplung, Ausführung wurde merklich langsamer)
zusätzlich dazu habe ich bei der Ausgabe nach jedem
1
lcd_data();
noch einen delay von satten 50ms eingebaut, auch das hat das Display
nicht umgestimmt.
Im übrigen gilt das mit diesen japanischen bzw. Chinesischen Zeichen
nicht für alle Werte. Ein lcd_data('0') gibt zum Beispiel die gewünschte
0 aus. das gilt bis '3'. Ab lcd_data('4') kommt wieder Müll heraus.
Das ganze scheint einem festen Muster zu folgen. Ich werde heute Abend
weiter forschen und die Zeichentabelle von http://www.myke.com/lcd.htm
zu Rate ziehen.
Falls noch jemand einen Tipp hat, immer her damit :)
Wackelkontakt an einer Datenleitung? Überprüf mal alle Verbindungen zum
Display. Wenn da eine Leitung nicht richtig Kontakt hat, kann es
durchaus passieren, dass scheinbar systematische Ausgabefehler
auftreten, weil die Leitung dann dauerhaft einen bestimmten Pegel haben
kann.
Das mit dem Kontakt müsste es sein! Nach der Zeichentabelle werden nur
Zeichen angezeigt, deren erste zwei Bit (je Nibble) gleich sind.
Das erklärt auch das Muster und die dreifache Wiederholung, genauer
gesagt müssten PORTD(0) und PORTD(1), also die ersten beiden
Datenleitungen, kurzgeschlossen sein. Ich werde es heute abend prüfen!
danke soweit :)
>Es gibt auch LCD-Displays mit chinesischem Zeichensatz.....
Nicht chinesisch, japanisch (sog. Kana-Zeichen). Haben alle normalen
Displays (mit HD44780) im Character-ROM ab A0h-FFh.
Ich konnte mein Problem immer noch nicht lösen.
Dass die beiden ersten Bits "hardwaremäßig verodert" werden führt auf
jeden Fall zu meinem Problem. Nur habe ich durch meine Schaltung
gemessen und konnte keine Kontakte zwischen den beiden Pins am AVR oder
der Leitung zum LCD feststellen.
Nun bleibt für mich nur noch das Display als Fehlerquelle übrig. Ob man
sowas trotz "Gebrauchsspuren", also benutzter Lötstellen, Umtauschen
kann? Wie sind da eure Erfahrungen?
Vor einem Umtausch könnte ich höchstens noch den 8Bit-Modus testen...
Mal sehen wann ich dazu komme.
Jack Braun wrote:
> Nicht chinesisch, japanisch (sog. Kana-Zeichen). Haben alle normalen> Displays (mit HD44780) im Character-ROM ab A0h-FFh.
Wäre auch etwas viel, da chinesisch reinzuprügeln, man stelle sich ein
Display mit vollständigem 16-bit-Unicode-Zeichensatz vor ;)
Obwohl - ich glaub ein paar Kanji waren auch noch drin, sen (1000) und
man (1'0000) für die Zahlen und noch irgendwas, hab leider nach etwa
zwei Jahren Japanisch aus Zeitgründen aufgegeben :(
Mal so aus Neugier - hat mal jemand die Katakana-Zeichen in Aktion
gesehen, also sinnvoll verwendet? Kann mir nicht wirklich einen ganzen
Text in Katakana vorstellen...
Ich weiß nicht, obs mittlerweile noch hilfreich ist. Trotzdem möchte ich
es kurz hier erwähnen. Mein Display legte genau das gleiche seltsame
Verhalten an den Tag. Nachdem ich hier mitgelesen habe, habe ich auch
gleich mal in der oben erwähnten Zeichentabelle von
http://www.myke.com/lcd.htm nachgeschaut und festgestellt, dass auch bei
mir der Fehler scheinbar systematisch auftrat.
Nachdem alles nichts gebracht hat (Kontrolle aller Verbindungen,
alternatives Display etc.), habe ich mich erstmal der "Ordnung" in
meinem Programm gewidmet (habe auch die von mir angepasste lcd-routine
von hier benutzt - allerdings die .asm). Und siehe da: nachdem ich in
JEDER Subroutine alle benutzten Register mit push und pop gesichert
hatte, war der Fehler verschwunden.
Offensichtlich lag der Fehler also bei mir. Vielleicht schaust Du Dein
Prog nochmal durch :)
Viel Erfolg!
