Hast ja Recht! Das hat mit dem Ursprungsthema nix mehr zu tun.Damit möchte ich die Diskussion über wie was womit besser/einfacher zu handhaben ist als beendet wissen.
Wenn Du Dich ja doch noch umentscheidest und Probleme hast, kannst Du nen neuen Post machen.
Für alle hier einen guten Rutsch!!!
Willkommen im Neuen Jahr!
Ich wollte mir zum Jahresbeginn eine Freude machen und hab den Test mit dem T24 versucht.
Leider kein guter Jahresbeginn
Den Code mehrfach überprüft, auch den Testaufbau. ICH kann keinen Fehler entdecken.
Möglicherweise ist mein LCD defekt. Hab es mittlerweile ein paar Jahre rum liegen. War zwar immer verpackt, aber ???
Egal ob der µC in der Schaltung steckt oder nicht, das LCD bleibt finster. Nur wenn ich das Kontrastpoti fast auf GND drehe, ist die zweite Zeile voll mit 5x7 Blöcken.
Die obere Zeile bleibt ganz finster. Kann das normal sein?
Vielleicht hat jemand Zeit und Muße und schaut mal über meinen Code, ob ich da einen Fehler übersehen hab bzw. mir dessen gar nicht bewusst bin.
Geändert von HeSt (01.01.2019 um 15:10 Uhr)
Ich denke, wirst Du schon untersucht haben, aber trotzdem noch mal:
Auch keine Kontaktschwierigkeiten mit irgendwelchen Anschlussadern am Display oder sonst wo? Stecker ab?
MfG
Ich glaube nicht, das das Display defekt ist.die zweite Zeile voll mit 5x7 Blöcken.
Die obere Zeile bleibt ganz finster. Kann das normal sein?
Das ist üblicherweise so, wenn das Display nicht richtig initialisiert wurde.
Schau mal Deine Init Routine und die Verbindungen zum Display durch!
Im Simulator vom AVR Studio kannst Du den Code ja mal Schritt für Schritt durchklicken.
@ Moppi
Ja, auch nachgemessen ...
@wkrug,
Im Sim scheint alles ok zu laufen. Zumindest läuft alles nach meinem Gedankengang ab.
Ist er richtig?
Das beschriebene Verhalten klingt völlig normal, glaube auch nicht dass das Display defekt ist.
Die Displays benötigen aber einen gewisse Zeit bevor sie überhaupt ansprechnbar sind, da sie nach dem Anlegen der Versorgung einen internen Reset ausühren.
Bevor Du also irgendwelche Zugriffe tätigst, muss vorher eine Wartezeit genereirt werden.
Vielleicht liegt es daran.
Siro
Also irgendwie komm ich mit dem Timing nicht so ganz mit.
Bei 1Mhz sind die Zeitschleifen zu lang (200ms bei 46msRoutine), bei 8 MHz sind es dann nur 28ms.
Auf jeden Fall bei mir im Simulator.
Der tiny24 hat auch keinen SPH?
Ein Tipp von mir, wie ich es auch immer gemacht habe und immer noch mache bis die Displays Leben zeigen:
Baue zunächst eine "lange" Warteschleife die "mit Sicherheit" mindestens 100ms dauert.
Dann benutze diese "überall". So kannst Du zunächst mal ein Timing Problem ausschliessen,
wenn es dann noch nicht geht, liegt das Problem bei der Ansteuerung selbst.
Bis das Display läuft, solltest Du generell die Lange Wartezeit benutzen.
Auch bei den Signalen von Enable RS usw, LAAAAANGE Schleifen zum Testen, das tut ja keinem weh....
Man verheddert sich sonst. Schnelligkeit Optimierung erst wenn das Display läuft.
Es scheint ja noch nicht einwandfrei geklärt zu sein, wie lange deine Funktionen wirklich warten
Dann fällt mir grade noch auf:
Du initialsierst dein Display dauernd neu:
ich würde die Initialisierung wohl eher so machen:
Das SPH Register in deinem Tiny24 existiert tatsächlich nicht, hat wkrug recht, das gibts erst beim Tiny84 mit 512 KByte RAMCode:rcall lcd_init ; Initialisierung nur EINMAL DSP_MOD: .... rjmp dsp_mod ; Hauptschleife ohne neue Inititialisierung
Die Initialisierung gleich beim Start für den Stack scheint okay und somit universell. Ich denke das kann bleiben.
Es gibt jedoch Controller die bei derartigen Zugriffen (auf Registern die nicht existieren) mit einer Speicherschutzverletzung reagieren und das System anhalten,
ich glaub aber nicht bei deinem.
Mich wunderte zudem noch der "OUT" Befehl für den Stackpointer:
Aber der Stackpointer liegt tatsächlich im IO Bereich, ungewöhnlich aber völlig korrekt.
Siro
Geändert von Siro (01.01.2019 um 19:29 Uhr)
Berechtigungen
Zitieren
Lesezeichen