Hallo,
Ich habe einen LCD Timer den ich hier bei mikrocontroller.net gefunden
habe gebaut.
mein Problem jetzt, 1 Sekunde dauert etwa 4 sekunden und bin mir nicht
sicher wo der Fehler liegt entweder im aSm Code oder an der schaltung.
Wenn ich den Timer starte, verschwindet mein Text vom 2x16 LCD Display,
erst wenn ich am Poti für den kontrast schraube bekomme ich es wieder
sichtbar.
Ich habe es nach dem Schaltplan von folgendem Thread gebaut:
Beitrag "LCD-Timer für Belichtungsgerät"
Es reicht sehr danach, dass du nicht den externen 4MHz Quarz als
Zeitbasis hast sondern den ab Fabrik auf (interner 8MHz RC-Oszillator /
clkdiv8) Standardeinstellung hast. Das wäre dann 1/4 der gewünschten
Geschwindigkeit.
TobiS schrieb:> Ich habe extern (XTAL) einen Oszilator, kann das sein wenn der> integrierte Aktiviert ist das es Probleme gibt?
Du musst über Fusebits einstellen, welcher Takt verwendet werden soll.
Nur extern einen Quarz oder Taktgenerator dranhängen reicht nicht.
Hinweis: Quarz oder Taktgenerator sind unterschiedliche Einstellungen!
Gruß Dietrich
TobiS schrieb:> Ich habe extern (XTAL) einen Oszilator, kann das sein wenn der> integrierte Aktiviert ist das es Probleme gibt?
Es gibt keine Probleme, höhstens du hast ein Problem, nämlich die
Qual der Wahl der Quelle des Taktes. Es bleibt dir keine andere
Möglichkeit als explizit der Hardware zu sagen was du möchtest.
Zum Fuse bit,
wie genau stell ich das um, in meinem code habe ich folgendes gefunden:
; ***** sonstige Zuordnungen *****
.equ XTAL = 4000000
muss das weg oder Umgeschrieben werden?
TobiS schrieb:> Zum Fuse bit,>> wie genau stell ich das um, in meinem code habe ich folgendes gefunden:>> ; ***** sonstige Zuordnungen *****>> .equ XTAL = 4000000>> muss das weg oder Umgeschrieben werden?
Das Umstellen geht nur mit einem Programmer.
Die Angabe im Programm dient nur dazu, dass ggf. vom Assembler
berechnete Konstanten automatisch den richtigen Wert erzeugen.
Beispiel: Baudrate des UART einstellen; die Konstante für den
Bauraten-Generator hängt von der Taktfrequenz ab.
Gruß Dietrich
TobiS schrieb:> muss das weg oder Umgeschrieben werden?
das kommt auf die Wirklichkeit an
ist die 4MHz dann kann das so bleiben, ist deine Wirklichkeit anders
muss es geändert werden.
PS Du kannst die Wirklichkeit im Code nicht ändern, die wird bestimmt
von fuse setting und angeschlossenem Quarz
also:
ist ein Quarz am Xtal 1 + 2 Eingang?
hast du die fuse auf ext. crystal geändert?
hast du die fuse auf clkdiv8 oder nicht?
Ok, habs,
war CKOPT fuse bit.
dennoch habe ich das Problem mit dem Display, wenn ich meinen Timer
starte mit der Voreingestellten Zeit, verschwindet mein text, das is
aber nur der Kontrast, ich verstehe die Ursache nur nicht, wenn ich am
(Poti) Kontrastregler rekalibriere bekomme ich es wieder sichtbar, wenn
aber der timer ausgelaufen ist, wird der routine text mit zu viel
Kontrast, eigentlich alle pixel auf einmal angezeigt.
(Es ist nur der Kontrast des LCD was sich selbst ändert?)
Zeig mal dein Programm.
Wenn dein Programm wie wild das LCD löscht und den Text wieder neu
hinklatscht, kann das schon mal aussehen, als ob der Kontrast massiv
abnimmt. Allerdings hab ich noch nie beobachtet, dass man das mit dem
Kontrastpoti einigermassen ausgleichen könnte. Ich habs aber ehrlich
gesagt auch noch nie probiert.
Abgesehen davon gibt es keinen sinnvollen Zusammenhang zwischen dem
Kontrast des LCD und deinem Programm. Ausser eben, wenn du wie wild das
LCD löscht und den Text neu hinmalst. Dann flackert es wie Sau und da
das LCD dann 20% der Zeit tatsächlich leer ist, nimmt der Kontrast ab.
Aber ohne das Programm gesehen zu haben, ist das alles Spekulation.
Also um es genauer Auszudrücken, wenn ich den timer starte und der
kontrast so ziemlich auf 0 geht muss ich den poti nach links drehen um
den text wieder sichtbar werden zu lassen. Wenn abgelaufen oder gestoppt
ist der kontrast zu hoch gestellt und muss am poti rechts drehen zum
ausgleichen, immer son hin und her.
Karl Heinz schrieb:> Ausser eben, wenn du wie wild das> LCD löscht und den Text neu hinmalst. Dann flackert es wie Sau und da> das LCD dann 20% der Zeit tatsächlich leer ist, nimmt der Kontrast ab.
Genau das ist die Ursache! Also: Programmkonzept ändern.
Route 66 schrieb:> Karl Heinz schrieb:>> Ausser eben, wenn du wie wild das>> LCD löscht und den Text neu hinmalst. Dann flackert es wie Sau und da>> das LCD dann 20% der Zeit tatsächlich leer ist, nimmt der Kontrast ab.>> Genau das ist die Ursache!
Ich hab zwar versucht, im Code die Stelle zu finden, aber das ist gar
nicht so einfach, bei dem vielen hin und her Gehüpfe. Gefunden hab ich
allerdings nichts, das muss aber nicht viel heissen.
> Also: Programmkonzept ändern.
Und vor allen Dingen nicht so unübersichtlich schreiben. Ich kann mir
wirklich nicht vorstellen, warum der Code (Anmerkung: meiner Meinung
nach) so dermassen unübersichtlich sein muss. Der ist Wasser auf die
Mühlen all derjigen, die immer wieder sagen, dass man solche Dinge nicht
in Assembler schreibt, weil es einfach nicht wartbar ist.
Allerdings: der Code stammt ja aus einem fertigen Projekt. Ich kann mir
nicht wirklich vorstellen, dass das dem Original-Autor nicht auch
aufgefallen wäre. Nur: ich kann mir aber auch sonst keinen Zusammenhang
vorstellen. Einzig ein Einbruch in der Versorgungsspannung, wenn das
Relais geschaltet ist, wäre noch denkbar.
Route 66 schrieb:> Karl Heinz schrieb:>> Ausser eben, wenn du wie wild das>> LCD löscht und den Text neu hinmalst. Dann flackert es wie Sau und da>> das LCD dann 20% der Zeit tatsächlich leer ist, nimmt der Kontrast ab.>> Genau das ist die Ursache! Also: Programmkonzept ändern.
Nach nochmaliger Inspektion des Spaghetti-Kodes muß ich kbuchegg Recht
geben!
Allerdings liegt die schlechte Lesbarkeit nicht an der Verwendung von
Assembler generell. Es läßt sich einfach nur ein miserabler
Programmierstil erkennen.
Die Wartbarkeit und Fehlerträchtigkeit von Code hat mit der
Programmiersprache überhaupt nichts zu tun.
