Hallo, ich bekomme ein Seltsames verhalten von rol (links rotieren) befehl beim 615. zyklus. Also konkret geh es um ein LED Matrix welche mittels mega8 gesteuert wird. Zeilen hängen am port c (5 Zeilen) Spalten hängen am port d (8 Spalten) Der Assembler code ist angehägt. Was ich mache ist folgendes: Ich lade mir die Daten für die Buchstabe "A" ins sram und lasse sie mir auf die Leds ausgeben. Wenn die buchstabe komplett erscheint möchte ich das die Buchstabe sich "fortbewegt", eine Laufschrift also. Die bewegung implementiere ich in dem ich die Daten für die spalten jedesmal nach dem sie ausgegeben wurden rechts rotierend schieben (mittels ror befehl) Die Zeilen werden dann per rol geschoben(hier wird nur ein bit geschoben). Alles klappt bis hier hin gut und die Buchstabe beget sich auch ganz schön vorwärts aber wenn die Buchstabe den Rand erreicht spielt die Zeilenverschiebung (rol) verrück. hier wird ja die ganze Zeit nur ein bit geschoben (wie multiplikation mit 2) aber plötzlich nach dem 615. zyklus wird aus dem 0x02 ein 0x05 (sollte 0x04 werden) und danach gehts ungerade weiter. Der HW aufbau ist nicht angehängt weil dieses verhalten kann man auch im simulator beobachten, müsste also mit der code zusammenhängen. Woran kann das liegen? Ach ja das sind meine erste "gehversuche" in assembler und elektronik
Geht's wenn du LSL (Schieben Links) statt ROL (Rotieren Links) benutzt?
Hallo, hast du beachtet das ROL das Carry-Flag mit einbezieht? Ohne mir den Code jetzt genauer angesehen zu haben schätze ich das das Carry-Flag gesetzt ist bevor du den ROL Befehl ausführst, womit das ganze Byte nach links geschoben wird, und dabei am LSB das Carry-Bit reingeschoben wird. Grüße Peter
Hallo, eiegntlich wurde es schon gesagt. ROL schiebt über das Carry-Bit. Nimm LSL, das schiebt immer eine 0 rein. Also Bit0 setzen, LSL bis das Register 0 wird. Dann ist die 1 links rausgeschoben worden, also 8 Bit rum, dann Bit0 wieder setzen und von vorn. Habe mir jetzt Deine Register nicht gemerkt: ldi tempx, 0x01 ... lsl tempx brne ok ; nicht 0, also ok. ldi tempx, 0x01 sonst die 1 wieder vorn rein ok: und weiter Gruß aus Berlin Michael
also der raus geschobene bit sollte hinten wieder rein geschoben werden darum habe ich rol verwendet. das komische ist das es ja solange funktioniert bis der andere register sich durch geschoben hat. Werd heute Abend mit lsl versuchen aber trotzdem kann ich mir nicht erklären warum ein mit rol geschobenes bit sich nach zig langen Durchgängen so verhält. vlt habe ich ja rol und ror falsch verstanden. also ich meine rol bzw. ror soll ja den carry bit, das zuvor raus geschoben wurde hinten wieder dranhängen oder nicht?
>vlt habe ich ja rol und ror falsch verstanden. also ich meine rol bzw. >ror soll ja den carry bit, das zuvor raus geschoben wurde hinten wieder >dranhängen oder nicht? Das ist schon richtig. Du mußt mal gucken, ob nicht eine andere Routine (vornehmlich ein Interrupt) Dein Carry-Flag verändert und somit statt einer erwarteten "0" vielleicht eine "1" geschoben wird. Alle Rechen- und Schiebeoperationen verändern mitunter das Carry-Flag.
Die Wait Funktion verändert das Carry, was du also in tmp2 reinschiebst ist das Ergebniss der Wait Funktion.
@ Travel Rec. nein verwende keine interrupt bzw. sind nicht aktiviert (s. code) im main loop benutze ich ja ror tmp2 und rol tmp1, tmp2 scheint richtig geschoben zu werden und tmp1 wird auch etwa 7 oder 8 mal richtig Durchgeschoben aber beim nächsten Durchgang wird nach dem rol tmp2 aus 0x02 ein 0x05, das kann ich mir eben nicht erklären.
@ Benedikt K. das ist zwar gut möglich aber beim decrementieren sollte doch kein carry enstehen und auch sonst sehe ich nicht wo der wait routine ein carry erzeugen könnte. Bin mir zwar nicht sicher aber ich meine ich hab alle rcall wait wegen Schnelligkeit beim simulieren kommentiert.
Stimmt, dec beeinflusst das Carry nicht. Auch alle sonstigen Befehle machen das nicht. Ist denn das Carry vor dem 615. Zyklus gesetzt, wenn rol eine 1 reinschiebt ?
Das Carry entsteht durch 'ror temp2'. Irgendwann ist temp2 = 0b00000101 und dann passiert es im nächsten Schritt. Das Carry wird gesetzt und anschließend per rol in temp1 reingeschoben. Verfolge es Schritt für Schritt im Simulator, bis Du es verstanden hast. Das ist besser, als solange am Code rumzudoktern, bis der Fehler zufällig verschwunden ist.
AVRFan wrote: > Das Carry entsteht durch 'ror temp2'. Irgendwann ist temp2 = 0b00000101 > und dann passiert es im nächsten Schritt. Das Carry wird gesetzt und > anschließend per rol in temp1 reingeschoben. kann zwar erst heute Abend testen aber ich glaub das muss es sein. > Verfolge es Schritt für Schritt im Simulator, bis Du es verstanden hast. > Das ist besser, als solange am Code rumzudoktern, bis der Fehler > zufällig verschwunden ist. Hab schon mehr mals Schritt für Schritt simuliert darum konnte ich Angaben wie oben machen wie Zyklus etc. werde heute Abend darüber berichten obs geklappt hat
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.