Hallo, vorweg: Ich weiß, daß dieses Thema schon oft behandelt wurde und ja, ich habe die diversen Beiträge gelesen! Ich wollte bei einem Projekt das genannte Display mit einem ATmega 8 einsetzen und versuche schon seit Tagen die Initialisierung hinzubekommen. Anfangs nur mit Hilfe der Datenblätter vom Display und vom Controller und später mit den diversen Codes im Forum. Allerdings beschränke ich mich im wesentlichen auf ASM. Da alles erfolglos war habe ich - zwei neue Displays gekauft - den ATmega 8 gewechselt - die Steckbrettschaltung in eine fest verdrahtete Version geändert. Nach vielen vergeblichen Versuchen hatte ich dann gestern ein erstes Lebenszeichen mit dem Code von Bernhard (5V, 4Bit) Beitrag "5V 4Bit - DOGM162 DOGM081 EA DOGM163 Initialisierung Beispiel ATmega8 Assembler" Nachdem es schon spät war habe ich alles unverändert gelassen und nur ausgeschaltet. Als ich dann heute wieder eingeschaltet habe, tat sich wieder nichts. Nach diversen Versuchen bin ich nun dahinter gekommen, daß das Display nur nach dem Flashen startet. Oft auch erst beim 2. Mal. Das ist natürlich keine Lösung und ich frage mich was die Ursache sein könnte! Ich habe vor der Initialisierung auch schon 1s Pause eingelegt, aber ohne Änderung. Hat jemand einen Tip?
Bruno M. schrieb: > Hat jemand einen Tip? Ja, 1. den verwendeten Code zeigen (Anhang), 2. den verwendeten Schaltplan anhängen (pdf), 3. die aufgebaute Schaltung zeigen (Foto), 4. das Datenblatt zum Display verlinken, 5. schreiben, welche Messmittel (Oszilloskop/Multimeter/Logikanalysator) zur Verfügung stehen.
Rick schrieb: > Bruno M. schrieb: >> Hat jemand einen Tip? > Ja, > 1. den verwendeten Code zeigen (Anhang), > 2. den verwendeten Schaltplan anhängen (pdf), > 3. die aufgebaute Schaltung zeigen (Foto), > 4. das Datenblatt zum Display verlinken, > 5. schreiben, welche Messmittel (Oszilloskop/Multimeter/Logikanalysator) > zur Verfügung stehen. Code, Schaltplan sind im aufgeführten Link, die Schaltung entspricht dem Schaltplan, der Hinweis auf den Controller findet sich im Link. Signale habe ich mit einem analogen Oszi geprüft. Ich kann kein Problem erkennen.
Bruno M. schrieb: > Nach diversen Versuchen bin ich nun dahinter gekommen, daß das Display > nur nach dem Flashen startet. Oft auch erst beim 2. Mal. Mit welchem Takt läuft der Controller?
Hmmm schrieb: > Bruno M. schrieb: >> Nach diversen Versuchen bin ich nun dahinter gekommen, daß das Display >> nur nach dem Flashen startet. Oft auch erst beim 2. Mal. > > Mit welchem Takt läuft der Controller? Wie von Bernhard angegeben: 1 MHz
Bruno M. schrieb: > Wie von Bernhard angegeben: 1 MHz Dann solltest Du Dir das mal mit einem Logic Analyzer (billiger Saleae-Clone reicht) ansehen. Dass es mal funktioniert und mal nicht, klingt nach falschem (zu schnellem) Timing.
Hmmm schrieb: > Dann solltest Du Dir das mal mit einem Logic Analyzer (billiger > Saleae-Clone reicht) ansehen. Das kann ich mal versuchen! Ich meine, ich habe noch irgendwo einen vergraben.
Wie kommt Bernhard S. auf die 10 us, bei einem CPU-Takt von 1 MHz?
1 | ; rcall 3 Takte |
2 | ; ret 4 Takte |
3 | ; |
4 | ... |
5 | ... |
6 | WAIT_10us: |
7 | ret |
S. L. schrieb: > Wie kommt Bernhard S. auf die 10 us, bei einem CPU-Takt von 1 MHz? > >
1 | > ; rcall 3 Takte |
2 | > ; ret 4 Takte |
3 | > ; |
4 | > ... |
5 | > ... |
6 | > WAIT_10us: |
7 | > ret |
8 | > |
Sei doch nicht so penibel. Bloß 30% zu kurz. Das stimmt doch fast ;o)
S. L. schrieb: > Wie kommt Bernhard S. auf die 10 us, bei einem CPU-Takt von 1 MHz? Das ist zwar ein guter Hinweis, aber eine Änderung hat leider nichts gebracht. Ich habe mir in der Zwischenzeit auch noch mal die Timing-Vorgaben im Datenblatt angesehen. Eigentlich hat Bernhard überall sehr viel Luft gelassen: Soll Ist - vor Initialisierung >40ms 100ms - nach dem ersten Schritt >1,6ms 10ms - danach jeweils >26,3us 1ms - nach Initialisierung >26,3us 100ms + 1s bleibt noch das toggeln von EN, aber auch da ist mit 50us genug Zeit eingebaut.
Bruno M. schrieb: > - danach jeweils >26,3us 1ms Clear Display und Return Home brauchen mindestens 1.08ms.
Bruno M. schrieb: > Ich habe mir in der Zwischenzeit auch noch mal die Timing-Vorgaben im > Datenblatt angesehen. Eigentlich hat Bernhard überall sehr viel Luft > gelassen: > Soll Ist > - vor Initialisierung >40ms 100ms Das ist oft ein kritischer Punkt, wenn man sein Gesamtsystem nicht überblickt. Was passiert auf den Leitungen, bevor der zuständige Treiber die Kontrolle darüber übernimmt? Hier hauen gerne mal schlecht programmierte Bestandteile der ohne Sinn und Verstand zusammenkopierten Software rein. Oder auch genauso ohne Sinn und Verstand designte Hardware... Bei der Identifizierung eines Problems in diesem Bereich hilft übrigens ein LA nicht. Da muss es schon wirklich ein Oszi sein.
> ... daß das Display nur nach dem Flashen startet. > Oft auch erst beim 2. Mal. Bernhard S. hat das LCD auf den Port B gelegt - über diesen läuft aber auch das Programmieren (Flashen). Was passiert, wenn stattdessen Port D benutzt wird?
Tja - ich nehme einen ATmega16 und ein uraltes 2*16 LCD, und es erscheint "HALLO", mit völlig unverändertem Programm.
Im 5V 4-Bit Modus ist Vin mit Vout zu verbinden und dort 5V einzuspeisen. Das DOGM163 läuft bei mir völlig problemlos, ich benutze aber SPI und 3,3V Betrieb.
:
Bearbeitet durch User
Bruno M. schrieb: > Allerdings > beschränke ich mich im wesentlichen auf ASM. Ja, man kann sich auch selber Knüppel zwischen die Beine werfen. Was stört Dich an zuverlässig funktionierenden C-Beispielen? Da die Leitungen auf dem Glas sehr hochohmig sind, sollte man Code mit Busy Rücklesen nicht benutzen, sondern nur welchen mit Delays.
Erstmal danke für das Interesse und die guten Ratschläge. Ich habe den Fehler gefunden! Ist mir zwar peinlich, aber da muß ich jetzt durch! Da ich übernommene Codes auch verstehen möchte, schreibe ich sie grundsätzlich neu, auch wenn ich nichts ändern will. So auch hier. Dabei habe ich aus Versehen das RS Signal vor der Initialisierung nicht auf low gesetzt. So nahm das Drama seinen Lauf!
Bruno M. schrieb: > Erstmal danke für das Interesse und die guten Ratschläge. > > Ich habe den Fehler gefunden! > Ist mir zwar peinlich, aber da muß ich jetzt durch! > > Da ich übernommene Codes auch verstehen möchte, schreibe ich sie > grundsätzlich neu, auch wenn ich nichts ändern will. So auch hier. > Dabei habe ich aus Versehen das RS Signal vor der Initialisierung nicht > auf low gesetzt. So nahm das Drama seinen Lauf! Also, wie von mir vermutet: Das Problem lag vor der eigentlichen Initialisierung. Oder anders ausgedrückt: die Intialisierung ist offensichtlich unvollständig. Wenn der Zustand von RS eine Rolle spielt, dann hat die Initialisierung sich natürlich auch um dieses Signal zu kümmern.
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.