[ASM] RGB Tabelle komischer Wert

[RGB (Gast)]

Hallo,

ich habe bei dem Code im Anhang folgendes Phänomen:

Wenn unten das bei "ab:" auskommentiert ist klappt alles wunderbar und 
fadet durch.

Mache ich das auskommentierte dort weg, dann nimmt "bl"(oder auch rt, gn 
je nachdem welche Farbe grade dran ist) im Timer Interrupt oben komische 
niedrige Werte an sobald "blau" (oder die entsprechende Farbe) auf 62 
ist. Geht aber danach weiter wie es sein sollte also erreicht 
letztendlich den Wert 255.

Sichtbar wird das ganze, dass die Farbe immer Heller wird und kurz vor 
Maximalhelligkeit kurz flackert.

Da ich absolut neu auf dem Gebiet bin hab ich hierfür keinerlei 
Erklärung.
Hat wer ne Idee?

[RGB (Gast)]

Selbst wenn ich anstelle von "sinnvollem" einfach einige nop reinmache 
da unten tritt das Blinken schon auf.

Irgendwie hab ich das Gefühl ich hab irgendwo was übersehen und es wird 
da was überschrieben...

[RGB (Gast)]

Je mehr ich unten in die Endlosschleife schreibe (z.b. nop) desto 
weniger funktioniert das Dimmen.

Woran liegt das?
Unterbricht nicht der Timer jeden Überlauf das Hauptprogramm, läuft 
durch und setzt anschließend dort fort wo es war?!?
Von daher sollte es doch egal sein wieviel dort steht

[Kai G. (runtimeterror)]

Nur kurz überflogen:

Deine Lookup-Tabelle "dimtab" liegt vermutlich auf einer 
256-Byte-Grenze. Richte die mit einem ORG auf eine glatte Adresse aus 
oder verwende für die Adressierung beide Z-Register.

Schöne Grüße,
Kai

[RGB (Gast)]

achja... so einfach kanns doch sein

Vielen Dank

[Kai G. (runtimeterror)]

Ist aber auch ein fieser Fehler. Im Debugger wäre das recht schnell 
aufgefallen ;)

[RGB (Gast)]

Das wäre meine nächste Frage, woran erkenn ich das?
In der "Memory" ansicht im AVR Studio?

[Kai G. (runtimeterror)]

Ich habe jetzt z.B. deine m1-Schleife so lange laufen lassen, bis 
blau=0x3F (Run to Cursor auf "rcall wait"). Das ist ja der Zeitpunkt, wo 
das Dimmen spätestens schief geht.

Dann Run To Cursor auf "lpm bl, z" in deinem Interrupt-Handler. Hier 
könnte man schon feststellen, dass Z=0x0001 ist, wenn man wüsste wonach 
man sucht ;)

Einen Einzelschritt später steht in bl der Wert 0xC0 und nicht wie in 
der Lookup-Tabelle eingetragen 0xFE - und hier solltest du stutzig 
werden und das oben gezeigte Problem erkennen ;)

Spiels einfach mal durch - ich hänge noch ein Poster mit den 
relevanten Stellen an.

Gute Nacht,
Kai

[RGB (Gast)]

Ah, wenn ich mir das jetzt so ansehe ist das dann schon klar :)
Danke nochmal.


Was mir allerdings noch nicht klar ist, woran ich erkennen kann wann die 
Tabelle ungeschickt liegt.
.org 0x174 funktioniert nicht, 0x12C dagegen schon. Sieht für mich aber 
im Speicher irgendwie "gleich" aus?!?

[Kai G. (runtimeterror)]

Die Grenzen liegen bei 0x0000, 0x0080, 0x0100, 0x0180, ...
(Das AVR-Studio zeigt dir die WORD-Adressen an - die eigentlich 
interessanten Byte-Adressen sind analog 0x0000, 0x0100, 0x0200, ...) Um 
diese Grenzen zu überschreiten muss das ZH-Register modifiziert werden.

>.org 0x174 funktioniert nicht, 0x12C dagegen schon.
Die erste Tabelle überschreitet 0x0180, die zweite hingegen nicht.
.org 0x180 sollte gehen.

>Sieht für mich aber im Speicher irgendwie "gleich" aus?!?
Das ist inhaltlich auch gleich, aber die Adressen der Tabelle liegen 
unterschiedlich.

Ich empfehle solche Sondertabellen irgendwo ganz an den Anfang des Codes 
oder ganz ans Ende Speichers zu setzen, sonst kommst du aus dem Hin- und 
Herschieben nicht mehr raus.

Gruß,
Kai

[RGB (Gast)]

Ah, okay. Vielen Dank nochmal.
Ich glaube ich habs verstanden ;)