Tut mir wirklich Leid, dass auch ich jetzt mit so einem Problem ankomme... Ich wollte nur 'mal schnell' ein paar Dinge auf einem LCD testen - und schon kommt das Problem;-) LCD: 2*16chars (HD44100H / HD44780A) von Toshiba AVR: ATmega8515 @ 8Mhz Code: AVRASM aus dem hiesigen LCD-Tut Bei dem Code habe ich Target, Zeitschleifen und den Port (von D auf C) umgeändert. Zur Kontrolle lasse ich noch eine LED in der Hauptschleife blinken. PROBLEM: Die erste Zeile wird gelöscht, die zweite ist komplett mit 'schwarzen Kästchen' gefüllt. Von dem 'Test' erkennt man nur '| |'. Aus einem 'hello world' wird ein '| || ||'. Ich habe schon am Kontrast gekurbelt, die Spannung am Display mit 100n geblockt, das Backlight mit ca. 300 Ohm gesichert und RW+D0-D3 auf GND gelegt. Nach dem Flackern der LED und den fuses zu Urteilen arbeitet die mcu wirklich auf 8MHz. Ich bin mit meinem Latein mittlerweile am Ende und steuer auf die Krise zu;-) HIILFEEE!!! Viele Grüße, Hendrik
Hi! Schon mal mit 4Mhz Quarz probiert? Ich hatte auch mal so ein Problem -> 4 MHz Quarz und gut war... Ciao Pete
Mir ist klar, dass das Tut auf 4MHz geschrieben wurde. Da sich das LCD aber in einen Stapel 8MHz-Routinen einfügen muss, habe ich die Zeitschleifen angepasst (->Delayloop-Generator) An den Schleifen sollte es also nicht liegen... Trotzdem Danke!! Hendrik
Den Enable-Puls habe ich gerade auf 6nops verdoppelt - keine Änderung :-(
schon getestet, das das Display noch ok ist? ...also z.B. Tutorialcode mit 4MHz nur fürs Display... Sieht aus wie Probleme mit dem Display-Speicher. Die Striche kommen ja so nicht im Zeichensatz vor (Tabelle geprüft?). ... Masseverbindungen des Displays, Störungen durch Großverbraucher, Spikes auf der Displayversorgung...
Tutcode auf 4MHz werde ich noch probieren - sollte aber nicht viel ändern. den Port muss ich trotzdem umlegen... Die ASCII-Tabelle wird nicht von uns programmiert, sondern steckt im LCD-Controller und im Compiler. Masse sollte OK sein, ist sogar abgeblockt. Großverbraucher sind auch nicht dran (nur der ATmega8515).
-> Originalcode auf PortC umgeschrieben, fuses auf intern 4MHz umgestellt: KEINE ÄNDERUNG. Der Fehler liegt irgendwo anders...
Die Frage ist doch warum senkrechte Striche. Ist das der senkrechte Strich aus dem Displayzeichensatz, dann werden die falschen Daten empfangen. Ist der Strich anders als der aus dem Zeichensatz, dann ist der Displayspeicher tot oder der Displaycontroller kommt durcheinander. Der Blechrahmen liegt aber auch auf Masse?
Ich hab gerade mal in meiner Kiste gewühlt und einige 2*16 Displays angeschaut. Die LCD-Gläser sind doch mit so Zebragummis oben und unten kontaktiert. Wenn da nun irgendwie kein richtiger Kontakt...
Hallo, bist Du dir sicher, das du das Display richtig initialisiert hast? Ich hatte da etliche Probleme, mit einem angeblich kompatiblem Controller. Gruß Toby
Manche "kompatible" LCDs erfordern noch langsameres Timing. ...
Zunächst : Vielen Dank für Eure Hilfe!! @Hannes: Sämtliche Timings hatte ich schon bei den 8MHz-Versionen verlangsamt. Selbst eine 8MHz-Version auf den internen 4MHz führt zu diesem Problem (obwohl sich die Delays ja nun verdoppelt haben müssten). @???: Displaygehäuse liegt aug GND. Bei festem Druck auf den Rahmen werden sämtliche Querstriche (nicht nur die gewünschten, sondern wirklich alle) sichtbar. Wenn sämtliche Buchstaben, bei denen ein senkrechter Strich vorkommt (T,l,d,H,...) zu Strichen werden, ist das ein eigenartiger Zeichensatz... @Toby: Deine Vermutung hat was: Von Natur aus ist ja 1Zeile transparent, 2Zeile schwarz. Nach lcd_init und lcd_clear erwarte ich eigentlich komplette Transparenz... Zudem bekam ich gestern noch eine 8MHz Firmware geschickt, die auf diesem Display gelaufen sein soll. Die Chancen lagen ungefähr 1:50, dass die untere Zeile korrekt ausgegeben wurde (die obere machte immer Striche). Ansonsten gab es auch hier die Striche... Allerdings ist das Tut für genau diesen Controller geschrieben worden - wie kann da was falsch initialisiert werden?!?
nächster Versuch mit PC und jaLCD: Ich habe eben einen SubD-25 Stecker zusätzlich an das LCD gelötet und den AVR entfernt. Im 8bit-Mode arbeitet die 2.Zeile korrekt - die erste macht die bekannten Striche. Aber die zweite arbeitet schonmal... Irgendwer eine Idee?
Ein LCD, das statt Text nur einige Striche anzeigte, hatte ich auch mal. Ich musste das Handy, in das es eingebaut war, außer Betrieb nehmen, da ich die Telefonnummern nicht mehr lesen konnte. ...
Hi, mit Jalcds habe ich auch mal was gemacht. da hatte mein LCD auch nur Striche. Ich schau mal, ob ich da noch was finde. Kleinen Moment. Welches LCD hats du da nochmal ?! Ich meine, es lag an der Initialisirung und der Warteschleifen. Diese waren beim AVR deutlich zu kurz. Das LCD habe ich mit jaLCD nicht zum laufen gebracht. Mit dem AVR irgend wann schon. Wie gesagt, es war ein "kompatibler" Controller drauf. Gruß Toby
Hallo nochmal, ich hatte ein LCD "DEM16216 SYH-PY/V". Soviel vorweg. Gruß
Es ist ein TLC-493-LON von Toshiba Controller: HD44780A00 HD44100H
Nun wäre noch interessant, ob der LCD-Controller mit maximal möglichem Takt läuft. Könnte ja sein, dass er langsamer getaktet wird um Strom zu sparen. Damit ist das LCD immer noch schneller als wir lesen können. ...
Hallo nochmal, so, jetzt hab ich es gefunden. ich hatte den WINAVR Compiler, damit ging es garnicht. Warum auch immer. Dann hatte ich noch den CVAVR Compiler, und mit der LCD Routine hat es geklappt. Ich habe es eben nochmal ausprobiert. Ich hänge die Files mal an, dann kannst Du etwas aus diesen entnehmen. Gruß Toby
...und das main Programm. Ich hoffe, du findest was raus. Gruß Toby
Hier noch die Pinbelegung des Mega16 LCD PA0 RS Pin4 PA1 RD Pin5 PA2 EN Pin6 PA3 Frei PA4 DB4 Pin11 PA5 DB5 Pin12 PA6 DB6 Pin13 PA7 DB7 Pin14 Wie schon gesagt, das LCD läuft im 4 Bit Modus. Gruß Toby
ich verwende einen mega8515! @Tobi: könntest Dus mir kurz kompilieren? Welchen Takt braucht Dein Programm?
Hier mal mein aktueller Status: Durch die jaLCD-Experimente bin ich drauf gekommen, dass die zweite Zeile funzt. Also habe ich nach der 'Rücklötaktion' den Pointer auf die zweite Zeile gesetzt und kann dort nach Herzenslust rumkrakeln (auch im 4bit mode mit AVR @8MHz) Die erste Zeile macht nach wie vor nur Striche... Kann es sein, dass einfach das Modul Schrott ist? (es wurde nicht antistatisch verpackt und ich habe den Postboten gerade erwischt, wie das LCD in den Briefschlitz quetschen wollte...) Was meint Ihr? Kann es hier wirklich noch an Timings/Init liegen, wo die zweite Zeile funzt?? Hendrik
Hallo Hendrik, ich hänge heute Früh mal eine HEX Datei an. Hab hier im Moment nix da. Damit sollte dein LCD auch was anzeigen (hoffe ich). Was es anzeig, ist ja erstmal schnuppe, nicht? Der Mega16 laüft mit internen 8 Mhz. Gruß Toby Ach, das Prog könntest Du auch mit der Demo machen, die ist bis 2K Flash begrenzt. Ich habe irgendwo mal was über Senkrechte Linien gelesen. Ich glaube sogar bei Peter Fleury oder NAME ????, vergiss es, das bringt dir bestimmt nix, nein, brigt dich wieder auf eine andere Fährte, meinte ich. Mann, mir fällt der NAME nicht ein. Trotzdem Komisch, das die erste Zeile spinnt, die 2te aber geht! Eigentlich sollte das Timing überall gleich sein, bzw. ist es sogar! Hast Du vielleicht noch einen Fehler in der Init ? Schreib doch mal an Stellen und Zeilen, die das LCD garnicht mehr anzeigt! Zeigt es plötzlich etwas an, dann stimmt etwas mit der Adresse der ersten Zeile nicht! Mann, mir fällt der NAME immer noch nicht ein. Gruß Toby
Wie sieht denn das Zeichen 255 (FF) aus? Wird das Komplett als schwarzes Viereck dargestellt, dann ist der RAM im Display ok. Der HD44780A ist ja das Original (Nicht nur ein schwarzer Klecks). Da sollte auch die Initialisierung klappen. Die 2. Zeile geht, also hat die Initialisierung geklappt. Das einfachste wird wohl ein neues Display.
Bei 0xFF wird wirklich an erster Position der ersten Zeile ein schwarzes Kästchen ausgegeben. -> die Feldadresse war also korrekt Im Gegensatz zur zweiten Zeile funzen aber keine Buchstaben. Ich habe das Display auch mal einzeilig initialisiert: In Folge lief nur noch die (defekte) erste Zeile, die zweite war transparent. -> init ist auch OK Das alles führt mich zur Überzeugung, dass die Post auch hier mal wieder ganze Arbeit geleistet (und das Display auf dem Gewissen) hat... Danke für Eure Ausdauer! Hendrik
Hallo, Meinst du vieleicht Freak5 TobyTetzi? Mfg Daniel M.
Hallo, ich meinte Ulrich Radig. Seine LCD Lib ist sehr interessant. Ich werde mal eben für den Mega16 kompilieren. Bin gleich wieder da. Gruß Toby
Radig arbeitet mit dem BF. Hilft mir nicht groß, da ich RW anf GND habe ;-) Die inits sind identisch.
Hallo, so, probier das mal, Mega16, 8Mhz, Pins wie oben beschrieben an PORTA. Bin mal gespannt! Bis gleich! Gruß Toby
@Daniel M. : Ich hatte kein Problem mit senkrechten Srichen. Das waren im Grafikmodus aber die Muster an denen ich versucht habe herauszufinden, warum Pixelfehler auftreten. Dabei habe ich eigenartige Ergebnisse erziehlt: Senkrechte Linien über das gesamte Display waren fehlerfrei. Wenn man das Muster aber ab einem bestimmten Punkt versetzt hat, so traten dort oft fehlermuster auf, die aber nicht zufällig waren, sondern periodisch auftraten. Eigenartig war auch, dass der Text 1. nur in der 2. Zeile funktionierte und dass er dort auch nur erkennbar war, wenn man den rest des Displays nicht gelöscht hat. Weil beim Löschen wurde der Text sehr serh bass und hate Pixelfehler, wobei der Buchstabe, der ja vom Display generiert wurde, noch lesbar war. Ich schaue mal, was mit diesem Display los ist. Es ist zwar auch von Toshiba, aber ich hatte einen anderen Controller...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.