Hallo Forum, wenn es dem Esel zu wohl ist, geht er aufs Eis :-( ...könnte heute mein Motto gewesen sein :-( Nachdem ich seit fast 30 Jahren (fürs Hobby) Assembler programmiere (Z80, Z8, mal ein PIC, jetzt Attiny/Atmega), wollte ich dann doch mal in C einsteigen. Also erst mal mittels Timerinterrupt ein Portpin wackeln lassen, kein Problem. dann mal ein LCD ansteuern, aber das will und will nicht. Grundlagen: Hardware ist nach einer Tabelle (Hardware.pdf) auf einem Steckbrett (Aufbau.jpg) zusammengesteckt, Schaltplan dafür gibt es nicht. Programmiert wird im Atmel Studio 7, Programmer: JTAGICE3, Prozessor: Atmega168 mit 16MHz Quarz, Display: 16210 (großes 2 x 16). Programm im Anhang (Main.c). Verwendet wurden die lcd-routines aus dem Tutorial. Beim Starten des Programms wird das Display auch initialisiert, das sieht man ja daran, dass der schwarze Balken in der ersten Zeile verschwindet. allerdings kommt der Text nicht (LCD_uninitialisiert.jpg, LCD_initialisiert.jpg). Der Witz ist, wenn ich ein Assemblerprogramm mit selbst geschriebenen LCD-Routinen in diese Hardware lade, bekomme ich eine Anzeige (LCD_ASM_geschrieben.jpg), Hardware und Verdrahtung also OK. Ich habe extra die Verdrahtung nach der lcd-routines.h angelegt und die Ansteuerung meiner Assembler-Routinen angepasst. Nun habe ich mir mal die Timings angesehen. sind doch recht unterschiedlich. Rot ist das Enable-Signal, Gelb ist eine der Datenleitungen. Oszi_Asm-Routine_1_16MHz.png und Oszi_GCC-Routine_1_16MHz.png zeigen jeweils die Ausgabe zweier aufeinander folgender Zeichen, Oszi_Asm-Routine_2_16MHz.png die Ausgabe eines Zeichens nochmal gespreizt. Ich habe dann die Zeiten in der lcd-routines.h angepasst, sodass ähnliche Timings wie aus der Assemblerroutine erzeugt werden, siehe Oszi_GCC-Routine_2_16MHz.png. Hatte alles keine Wirkung. Ich habe auch den 16 MHz Quarz mal gegen einen 4 MHz getauscht, ohne F_CPU zu ändern, sodass sich stark verlängerte Timings ergeben, nichts. Dann habe ich noch in einer aufwändigen Prozedur per Oszi die Initialisierung aus der lcd-routines.h analysiert, nur um festzustellen, das diese die gleichen Anweisungen wie meine ASM-Routine ausgibt, nur in einer etwas anderen Reihenfolge am Ende, was aber nicht weiter relevant sein dürfte. Zuletzt habe ich noch das Timing in meinen ASM-Routinen schrittweise verkürzt, mit dem Ergebnis, das es bei weniger als 40 µs Zeichenabstand zu Unregelmäßigkeiten kommt, aber bis runter auf 20 µs noch irgendwas auf dem Display erscheint. Ich bin jetzt mit meinem Lathein am Ende, lade ich das ASM-Programm, geht es, Das GCC-Programm will einfach nichts anzeigen. Könnte morgen vielleicht noch mal ein anderes Display anschließen, wäre aber schade, das jetzige ist so schön groß :-) Irgeneiner noch eine Idee? Gruß Reinhard
Angehängte Dateien:
-
Aufbau.jpg
200 KB -
LCD_uninitialisiert.jpg
180 KB -
LCD_initialisiert.jpg
200 KB -
LCD_ASM_geschrieben.jpg
180 KB -
Oszi_Asm-Routine_1_16MHz.png
81 KB -
Oszi_Asm-Routine_2_16MHz.png
85 KB -
Oszi_GCC-Routine_1_16MHz.png
81 KB -
Oszi_GCC-Routine_2_16MHz.png
88 KB
Reinhard R. schrieb: > Irgeneiner noch eine Idee? Jo - nimm einfach eine fertige Bibliothek, z.B. die bewährte von Peter Fleury. Man muss nicht jedes Rad neu erfinden, nur die dreieckigen und viereckigen :-) http://homepage.hispeed.ch/peterfleury/avr-software.html#libs
Die 2 Eseleien wo Ich vor langer zeit 'druebergestolpert bin waren: 1) Geaenderte timing routinen in der avr-libc (neukompiliert und es ging nicht mehr) 2) Das verschwinden der `nop's (weil die gcc-kompilerbauern ja meinen sowas sei seiteneffektfrei).
Hallo, die eingebundene lcd-routines.h kann man aber nicht durchlesen. MfG
Reinhard R. schrieb: > Dann habe ich noch in einer > aufwändigen Prozedur per Oszi die Initialisierung aus der lcd-routines.h > analysiert, nur um festzustellen, das diese die gleichen Anweisungen wie > meine ASM-Routine ausgibt, nur in einer etwas anderen Reihenfolge am > Ende, was aber nicht weiter relevant sein dürfte. Wenn das der einzige Unterschied ist, den Du feststellen kannst, dann würde ich ihn einfach mal beseitigen. Dann wird man sehen, ob es relevant ist oder ob nicht. Gruß Jobst
> die eingebundene lcd-routines.h kann man aber nicht durchlesen. Wie sollen wir denn helfen, wenn der du uns den wirklich relevanten Code nicht zeigst? Schau mal in mein Buch (http://stefanfrings.de/mikrocontroller_buch/index.html) Band 3 da findest du ein minimales Beispielprogramm in C welches sehr konservatives Timing benutzt das sowohl mit aktuellen als auch 20 Jahre alten Displays funktioniert. Das komplexe Tinming ist dort detailliert als Text beschrieben - für die Leute, die mit den Diagrammen aus dem Hitachi Datenblatt nicht viel Anfangen können.
Angehängte Dateien:
-
GCC_OK.jpg
200 KB
Hallo, erst mal vielen Dank für eure Ideen. Stefan U. schrieb: >> die eingebundene lcd-routines.h kann man aber nicht durchlesen. > Wie sollen wir denn helfen, wenn der du uns den wirklich relevanten Code > nicht zeigst? Ich hatte die Bemerkung von Christian S. nicht gleich verstanden, ist mir durch deinen Kommentar klarer geworden, lcd-routines.h und .c und die aktuelle (jetzt funktionierende) main.c angehängt. Die auskommentierten Zeiten in der lcd-routines.h sind die originalen aus dem Tuorial dieses Forums. Jobst M. schrieb: > Wenn das der einzige Unterschied ist, den Du feststellen kannst, dann > würde ich ihn einfach mal beseitigen. Dann wird man sehen, ob es > relevant ist oder ob nicht. OK, habe ich gemacht. der Einfachheit halber habe ich meine ASM-Routinen auf die Reihenfolge der Initsequenz aus der lcd-routines.h umgestellt, Ergebnis das gleiche, ASM geht, GCC nicht. Matthias S. schrieb: > Jo - nimm einfach eine fertige Bibliothek, z.B. die bewährte von Peter > Fleury. Ja, hatte ich mir im Vorfeld auch schon mal angeschaut. War mir für den Einstieg aber erst mal, ähm, na ja, ich sag mal, unsympatisch, da der ja das Busssy-Flag abfragt. Ich dachte, eine auf Wartezyklen basierende Routine wäre im nicht funktionierenden Fall besser zu beherrschen. Langer Rede kurzer Sinn, jetzt geht es (GCC_OK.jpg). Bei weiteren Tests auf der Basis Trial and Error :-) bin ich auf die Idee gekommen, dass ein einmal initialisiertes Display ja so lange initialisiert bleibt, bis die Versorgungsspannung weg ist. Also habe ich es mit dem GCC-Programm initialisieren lassen und das ASM-Programm mit auskommentierter Initialisierung drauf gespielt. Und plötzlich waren auch die im GCC-Programm geschriebenen Zeichen zu sehen, soweit sie nicht vom ASM-Programm überschrieben wurden. Dann habe ich wieder das GCC-Programm geladen, wobei mir beim genauen Hinsehen auffiel, das die geschriebenen Zeichen kurz zu sehen waren. Also wird das Display nach der Ausgabe ausgeschaltet. Ein nachgesetztes Kommando "Display Ein" macht alles wieder sichtbar (main.c). Wenn ich dieses Kommando vor die Ausgabe setze, sehe ich wieder nichts. Muß also in der Zeichenausgabe ausgeschaltet werden, ich sehe aber beim besten Willen nicht, wo. Aber ich bleibe dran, hautptsache ich sehe erst mal was :-) Reinhard
Hi Zur Initialisierung eines LCD bietet sich Sprut.de förmlich an: http://sprut.de/electronic/lcd/index.htm Wenn Du mit Deinem Assembler-Teil z.B. nicht die Position festlegen kannst, könnte RS und R/W vertauscht sein. Bringt mich aber auch dazu, daß ich noch ein I2C-LCD an einen ATtiny häckeln wollte ... MfG
Reinhard R. schrieb: > OK, habe ich gemacht. der Einfachheit halber habe ich meine ASM-Routinen > auf die Reihenfolge der Initsequenz aus der lcd-routines.h umgestellt, > Ergebnis das gleiche, ASM geht, GCC nicht. Gut. Und wo ist nun der Unterschied auf den Leitungen? Gruß Jobst
Angehängte Dateien:
-
Ausgabe.jpg
210 KB -
Oszi_ASM-1_Zeichen.png
91 KB -
Oszi_GCC-1_Zeichen.png
88 KB
Patrick J. schrieb: > Zur Initialisierung eines LCD bietet sich Sprut.de förmlich an: > http://sprut.de/electronic/lcd/index.htm Ja, danke, kenne ich, war u.a. Basis für meine ASM-Routinen. > Wenn Du mit Deinem Assembler-Teil z.B. nicht die Position festlegen > kannst, könnte RS und R/W vertauscht sein. Das ASM-Programm funktioniert ja, auch die Positionierung. Das diente jetzt nur als Vergleich und Test. Im Grunde ging es darum, in C durchzustarten, weil ich im ASM letztens beim Prozessorwechsel so einen Verdruss hatte... Jobst M. schrieb: > Gut. Und wo ist nun der Unterschied auf den Leitungen? Die Unterschiede sind marginal, es funktionieren ja auch beide Init-Routinen, siehe meinen letzten Post. Nur schaltet sich bei der Ausgabe eines Zeichens über das GCC-Programm das Display aus. Ich habe jetzt noch ein wenig weiter experimentiert. Habe das GCC- und das ASM-Programm soweit zusammengestrichen, dass ohne Initialisierung nur noch jeweils ein Zeichen ausgegeben wird und dann in einer Endlosschleife verweilt (main.c). Zuerst wurde das Display noch eimal mit der GCC-Routine initialisiert. Anschließend wurden abwechselnd beide Programme geflasht und mehrmals per Reset gestartet. War das ASM-Programm aktiv, konnte man verfolgen, wie bei jedem Reset ein Zeiche mehr im Display erschien. Wurde das GCC-Programm gestartet, wurde und blieb das Display ausgeschaltet, wobei nach anschließendem aktivieren des ASM-Programmes auch die im GCC-Programm geschriebenen Zeichen angezeigt wurden, siehe Ausgabe.jpg. Die 'G' wurden mit dem GCC und die 'A' mit dem ASM erzeugt. Oszibilder von der Zeichenausgabe mit beiden Programmen habe ich angehängt, Gelb ist RS, Rot ist E. Es gibt keine weiteren Signale auf den Steuerpins, habe im Singleshot bis 5 s nach Reset gesucht. Reinhard, der jetzt erst mal den Kopf für morgen wieder frei bekommen muß :-)
Reinhard R. schrieb: > Wurde das > GCC-Programm gestartet, wurde und blieb das Display ausgeschaltet, wobei > nach anschließendem aktivieren des ASM-Programmes auch die im > GCC-Programm geschriebenen Zeichen angezeigt wurden, siehe Ausgabe.jpg. > Die 'G' wurden mit dem GCC und die 'A' mit dem ASM erzeugt. > Oszibilder von der Zeichenausgabe mit beiden Programmen habe ich > angehängt, Gelb ist RS, Rot ist E. Es gibt keine weiteren Signale auf > den Steuerpins, habe im Singleshot bis 5 s nach Reset gesucht. Okay, Du möchtest uns weis machen, dass mit den selben Signalen unter ASM ein Zeichen erscheint und mit C nicht, bzw. das Display abgeschaltet wird? Klingt unglaubwürdig, denn dem Display ist es egal, aus welcher Quelle die Signale entstammen, es kann nicht hellsehen und eigentlich interessiert es sich nur für die Signale, welcher Deiner Aussage nach nur marginale Unterschiede aufweisen. Entweder sind die Unterschiede vorhanden und sind Ursache des Problems oder Du führst uns an der Nase herum. Oder es soll ein "C/GCC ist scheiße (aber eigentlich kann ich es gar nicht)"-Bashing werden. Gruß Jobst
was macht diese Zeile lcd_command(0x0C); Es gibt doch so schöne defines für die Kommandos
Jobst M. schrieb: > Okay, Du möchtest uns weis machen, dass mit den selben Signalen unter > ASM ein Zeichen erscheint und mit C nicht, bzw. das Display abgeschaltet > wird? Hallo Jobst, ich glaube es ja selber nicht, komme mir langsam auch blöde vor, aber du (oder jemand aus der Nähe, PLZ 068xx) kannst gerne zu mir kommen und den Mist selber ansehen und durchspielen. Ich glaube, ich brauche langsam einen Zeugen, oder jemanden, der mir das Brett vor dem Kopf entfernt. Walter S. schrieb: > was macht diese Zeile > lcd_command(0x0C); Ist ja in der letzten von mir geposteten main.c schon geändert. Beitrag "Re: Mal wieder: LCD will nicht (Atmega, GCC)" Reinhard
Was mir so auffällt: in den Senderoutinen für lcd_data und lcd_command wird direkt nacheinander zweimal lcd_out aufgerufen. Die Konsequenz ist, daß die Hold-Time nach dem Enable-Puls nicht kontrolliert eingehalten wird, sondern nur mehr oder weniger als Seiteneffekt, wenn der Controller ausreichend langsam ist. Ich würde mal versuchen, zwischen den Aufrufen von lcd_out eine geeignete Wartezeit einzufügen, und zwar nach Datenblatt des Displays.
Hallo, also, ich habe nun nochmal weiter experimentiert. Wie weiter oben schon angedroht, habe ich mal andere Displays (ein 1x16, Typ ?, ein 2x8 Typ C0802-04 und ein 2x16 Typ CM1624) in dieser Schaltung und mit dem GCC-Programm getestet. Alle drei funktionieren so wie sie sollen, also ohne "DISPLAY ON" am Ende. Stecke ich dieses erste Display (2x16 Typ 16210) wieder an, kann ich wieder das oben beschriebene kuriose Verhalten beobachten. Muß also an diesem Display liegen, warum auch immer. Ich denke, es lohnt nicht, das Problem weiter zu verfolgen. Ich ärgere mich nur darüber, durch diese unglückliche Auswahl des zuerst verwendeten Displays von meinem eigentlichen Vorhaben, mich in C einzuarbeiten, abgehalten worden zu sein. Aber was solls, schauen wir nach vorn :-) Werde wohl das Display entsorgen, oder hat hier noch Einer Lust, sich damit rumzuärgern? Wenn ja, ich schicke es ihm gerne zu. Stefan U. schrieb: > Schau mal in mein Buch Habe ich mal kurz überflogen, werde ich mich sicher in nächster Zeit zumindest mit den C-Bereichen intensiver beschäftigen. Reinhard
Warum probierst Du nicht einfach mal den Code in meinem Link aus?
oder http://homepage.hispeed.ch/peterfleury/avr-software.html damit hatte ich meine ersten Gehversuche erfolgreich absolviert! kann viele LCD mit Hitachi und KS0066
Joachim B. schrieb: > oder > > http://homepage.hispeed.ch/peterfleury/avr-software.html > > damit hatte ich meine ersten Gehversuche erfolgreich absolviert! Ja, aber da waren wir auch schon im 2ten Beitrag hier. Will er ja nicht, weils einen zusätzlichen Pin braucht.
Matthias S. schrieb: > Ja, aber da waren wir auch schon im 2ten Beitrag hier. Will er ja nicht, > weils einen zusätzlichen Pin braucht. Wieso zusätzlichen PIN, du meinst wegen clock stretching? Ich hatte da in pure AVR noch keine Probleme aber OK die kann es geben weil der AVR damit nicht gut zurecht kommt.
Da würde ich doch erst mal ausschließen, dass das C-Programm nicht das tut, was man will. Gut möglich, dass da noch ein Bug drin ist. Warum eigentlich nie einer mal einen Debugger verwendet? Dafür ist das Ding doch da.
Joachim B. schrieb: > Wieso zusätzlichen PIN, du meinst wegen clock stretching? Nein, wegen Abfrage des Busy-Flags. Das bringt außerdem noch eine Reihe weiterer Probleme mit sich, z.B. bezüglich 3.3V/5V und möglichen Kurzschlüssen bei Programmierfehlern. Kann ich gut verstehen, daß man sich das spart.
Nop schrieb: > Nein, wegen Abfrage des Busy-Flags. oh, ich war gedanklich bei I2C Das Busy Flag hatte ich noch nie abgefragt, aber OK ich behalte es im Hinterkopf wobei hat das jedes LCD? Ausserdem spart man Ports mit I2C Umsetzung und ohne LED kann man sogar das LCD zurücksetzen einfach Power auf einen Portpin klemmen, aber da wären wir wieder bei Port Pins sparen, der Möglichkeiten gibt es viele, nichts dramatisches also, es gibt wirklich andere Probleme als ein schnödes LCD. Wenns nicht gerade 4 Zeilen a 40 Zeichen sein soll in großen Lettern finde ich die (roten Platinen) Nokia 5110 Teile billiger und besser für Statusausgaben.
Hast du einen Logicanalyzer? Denke hier wird einfach das Timing zw. ASM und C abweichen da C vielleicht ne extra Runde dreht und ggf. noch Registerinhalte sichert.... Ich poste dir heute Mittag auch mal einen Code.
Matthias S. schrieb: > Joachim B. schrieb: >> http://homepage.hispeed.ch/peterfleury/avr-software.html >> >> damit hatte ich meine ersten Gehversuche erfolgreich absolviert! > > Ja, aber da waren wir auch schon im 2ten Beitrag hier. Will er ja nicht, > weils einen zusätzlichen Pin braucht. Es geht nicht um den einen Pin, sondern darum, die Bussy-Flagabfrage als weitere mögliche Fehlequelle zu vermeiden. Peter D. schrieb: > Warum probierst Du nicht einfach mal den Code in meinem Link aus? Eigentlich wollte ich ja dieses problematische Display ad acta legen, da die anderen 3 ja funktionieren. Aber aus Respekt vor den aktiven Helfern werde ich die angebotenen Codes noch damit ausprobieren, ich melde dann das Ergebnis hier. Thomas O. schrieb: > Hast du einen Logicanalyzer? Nein, leider nicht, "nur" ein 2-Kanal-DSO. Reinhard
Hallo, ich habe nun auch den Code von Peter D. seinem Link getestet, gleiches Ergebnis. Display zeigt nur etwas an, wenn am Ende das Kommando "Display On" erfolgt. Ich habe es aber trotzdem rausbekommen :-) Dieses Display zeigt nichts an, wenn die RS-Leitung auf H-Pegel bleibt. Alle getesteten C-Routinen lassen einfach RS auf dem Pegel, der zuletzt genutzt wurde, d.h. nach Kommandoausgabe auf "L", nach Textausgabe auf "H". In meinen ASM-Routinen wird RS nach Nutzung immer auf "L" gehalten, habe ich damals so eingerichtet, ohne besonderen Grund. Deshalb hat das Display auch immer in dem ASM-Programm etwas angezeigt. Ich kann auch bei aktiver Anzeige nur durch setzten von RS --> "H" das Display dunkel und durch RS --> "L" wieder sichtbar schalten. Echt kurios. Also, Problem gelöst. Dank an alle, die mitgedacht haben und sich aktiv an der Lösung beteiligt haben. Übrigens, dieses Display entspricht in den Abmessungen dem "LCD 162F LED" von Reichelt. Dieses wird lt. Datenblatt aber als 16290 aufgeführt, meins ist ein 16210. Also wenn so ein Teil mal nicht will, mal an "RS=0" denken :-) Reinhard
Reinhard R. schrieb: > Dieses Display zeigt nichts an, wenn die RS-Leitung auf H-Pegel bleibt. Ich würd mal sagen, es ist defekt. RS liegt neben VEE (Kontrastspannung) und da wird wohl eine hochohmige Verbindung bestehen, d.h. RS = 1 zieht die Kontrastspannung hoch und nichts ist mehr zu sehen.
Dong, dong, dong, dong, dong, dong, dong, dong, dong, dong, das ist das Geräusch, wenn ich mit dem Kopf gegen die Wand haue :-( Peter D. schrieb: > Ich würd mal sagen, es ist defekt. > RS liegt neben VEE (Kontrastspannung) und da wird wohl eine hochohmige > Verbindung bestehen, d.h. RS = 1 zieht die Kontrastspannung hoch und > nichts ist mehr zu sehen. Fast richtig, es war eine eher niederohmige Verbindung, so etwa 0 Ohm :-( Ich hatte schon mal den Strom nach VEE gemessen, der kam mir mit um die 40 mA auch recht hoch vor. Hatte gedacht, na ja, großes Display, hoher Strom, zumal sich das eher rudimentäre Datenblatt dazu ausschweigt. Nachdem ich nun nochmal mit dem Lötkolben an den Anschlüssen war, funktioniert das Teil auch wieder normal :-), also ohne "RS=0" Habe rein optisch mit meiner 9-fach Lupe nichts ausmachen können, aber mit dem Ohmmeter :-) Na ja, nun ist aber endgültig alles geklärt, vielen Dank nochmal an Peter. Dong, dong, dong, dong, dong, dong, dong, dong Gruß Reinhard dong, dong, dong, dong, dong, dong...
Reinhard R. schrieb: > sondern darum, die Bussy-Flagabfrage als > weitere mögliche Fehlequelle zu vermeiden. Bussies sind nie ein Fehler :-) Aber LCDs sind so gut wie statisch und benötigen sehr, sehr wenig Strom. Bei 40mA muss man da auf jeden Fall misstrauisch werden.
Matthias S. schrieb: > Reinhard R. schrieb: >> sondern darum, die Bussy-Flagabfrage als >> weitere mögliche Fehlequelle zu vermeiden. > > Bussies sind nie ein Fehler :-) OK, wer Rechtschreibfehler findet darf sie behalten ;-) Aber an grundsätzlich hast du natürlich recht :-)
Reinhard R. schrieb: > Dong, dong, dong, dong, dong, dong, dong, dong, dong, dong, > das ist das Geräusch, wenn ich mit dem Kopf gegen die Wand haue :-( > Gruß Reinhard also es lag nicht an C, nicht am Code, nicht an der SW es war ein doofer Lötfehler..... und man sieht wieder mal ohne echte Bilder vom Aufbau und mit fehlerhaftem Aufbau kann man nicht vorhandene SW Fehler nicht finden ;) Wie oft habe ich schon zur Antwort bekommen ist alles richtig aufgebaut, so wie es im Tutorial steht und dann war es doch anders. Ich sage es immer wieder, hat man eine Verbindung gelötet wird diese mit dem Ohmmeter gemessen, jede Lötstelle zu den Nachbarn auch und wenn das stimmt wird die Leitung mit dem Marker vollständig gemarkert. 1. sieht man vergessene Leitungen 2. ist diese Leitung mit den Nachbarlötstellen OK 3. spart das Zeit bei der Fehlersuche.
:
Bearbeitet durch User
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.