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
hallo in welcher sprache programmierst du es wäre vielleicht net wenn du den code einfach mal anhängst
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 | int main (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 | return 0; |
13 | }
|
Natürlich habe ich die lcd.h an meine Bedürfnisse angepasst...
Im Anhang steckt der verwendete Quellcode, der stammt von hier: http://homepage.hispeed.ch/peterfleury/avr-software.html
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.
Es gibt auch LCD-Displays mit chinesischem Zeichensatz..... Katapulski
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 :)
Katapulski wrote:
> Es gibt auch LCD-Displays mit chinesischem Zeichensatz.....
LCD-Displays gibt es gar nicht. Höchstens LC-Displays oder LCDs...
...dafür dann aber trotzdem chinesische Zeichensätze. P.S. Wer SMD-Bauelemente einlöten kann, kann auch Haare spalten. ;-)) Katapulski
>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.
Was für einen Charakter muß ein ROM haben, um solche Sachen zu speichern? ...schnell fort! Katapulski
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!
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.