movlw verändert das Z flag?!?

[stowoda]

Moin

Wenn ich den folgenden Code mit MPLAB simuliere wiederfährt etwas was ich nicht nachvollziehen kann.
Es geht um diese Zeilen:
incf y, f
movlw .1
movwf temp
rrf temp
rlf data_2

Normalerweise sollte nach dem incf Befehl das Z flag gesetzt sein wenn in y ein Überlauf stattfindet. So weit so gut..
Nach den nächsten zwei Zeilen wird das Z flag allerdings wieder gelöscht.
Also quasi nach dem movwf Befehl.
Ich habe gelesen dass, movf das Z flag beeinflusst, movwf jedoch nicht.
Was habe ich da übersehen?
Die Passage um die es sich handelt findet Ihr am Ende das Codes unter dem label "one"


list p=16F84A

#include <p16F84A.inc>

__CONFIG _PWRTE_ON & _WDT_OFF & _XT_OSC



y Equ 0x30
data_1 Equ 0x31
data_2 Equ 0x32
temp Equ 0x33






;************************************************* ***************
;* Programmstart *
;************************************************* ***************
org 0x0000
clrf PCLATH
clrf STATUS
clrf INTCON
goto INIT
org 0x0004
goto INT_ROUT
org 0x0020

;************************************************* **************
;* Initialisierung *
;************************************************* **************
INIT ; Initialization
bsf STATUS, RP0
movlw B'00000000' ; PORTA output
movwf TRISA
movlw B'00000001' ; PORTB output except RB0
movwf TRISB
bcf STATUS, RP0

CONFIG_OPTION_REG
bsf STATUS, RP0
movlw B'10000001' ; Pull-up´s off : INT on falling edge :
movwf OPTION_REG ; TMR0 counts internal clock : prescaler 1:4 TMR0
bcf STATUS, RP0
bcf STATUS, Z

CONFIG_INTCON
movlw B'00100000' ; INT on : T0IE on : INTE :off
movwf INTCON ; RBIE off : T0IF, INTF, RBIF cleared

;************************************************* ***************
;* Identyfikacja naglowka! *
;************************************************* ***************
detect
btfsc PORTB, 0 ; Warte auf low
goto detect
call stoper_4t ; 2400ms (naglowek)
btfss PORTB, 0
goto detect ; Fehler, wenn nach 2,4ms immer noch low
detect_bit
btfsc PORTB, 0
goto detect_bit
call vor_bitempfang

stoper_4t
bsf STATUS, RP0
movlw B'10000011'
movwf OPTION_REG ; prescaler TMR0 -> 1:16
bcf STATUS, RP0
movlw .106 ; TMR0 laden für 2,4ms
movwf TMR0
btfsc INTCON, T0IF
count_1
btfss INTCON, T0IF
goto count_1
return


vor_bitempfang
movlw .248 ; Variable wird geladen um abzählen
movwf y ; zu können ob data_1 voll ist
bitempfang
xt
bsf STATUS, RP0
movlw B'10000001' ; prescaler TMR0 -> 1:4
movwf OPTION_REG
bcf STATUS, RP0
bcf INTCON, T0IF
movlw .109
movwf TMR0
count_2
btfss INTCON, T0IF
goto count_2
btfsc PORTB, 0
goto zero ; sende null
bsf STATUS, RP0
movlw B'10000001' ; prescaler TMR0 -> 1:4
movwf OPTION_REG
bcf STATUS, RP0
bcf INTCON, T0IF
movlw .109
movwf TMR0
count_3
btfss INTCON, T0IF
goto count_3
goto one

;************************************************* *************
;* eine 0 wurde empfangen, wird nun gespeichert *
;************************************************* *************
zero
btfss STATUS, Z
goto teil_1z
teil_2z
movlw .0
movwf temp
rrf temp
rlf data_2
bsf STATUS, Z
goto bitempfang
teil_1z
incf y, f
movlw .0
movwf temp
rrf temp
rlf data_1
btfsc STATUS, Z
bsf STATUS, Z
goto bitempfang

;************************************************* *************
;* eine 1 wurde empfangen, wird nun gespeichert *
;************************************************* *************
one
btfsc STATUS, Z
goto teil_1o
teil_2o
incf y, f
movlw .1
movwf temp
rrf temp
rlf data_2
goto bitempfang
teil_1o
movlw .1
movwf temp
rrf temp
rlf data_1
bcf STATUS, Z
goto bitempfang


INT_ROUT

end

Gruß
lk

[PicNick]

Normalerweise sollte nach dem incf Befehl das Z flag gesetzt sein wenn in y ein Überlauf stattfindet

Und ? War ein Überlauf ? Z-Bit gesetzt ?

[stowoda]

Ja, darum geht es nicht.
Was wichtiger ist: wieso wir das Z flag gelöscht nach den oben gennannten Befehlen?

[PicNick]

Darum geht es haarscharf.
movlw & movwf greifen das Z-Bit nicht an.
es kann also nur verschwinden, wenn es vorher garnicht da war

[stowoda]

Hehe, mathematisch gesehen hast recht mit dem verschwinden ;)

Es war da, da ein Überlauf stattfand.
Deswegen wundere ich mich ja wieso es verschwindet. :(
Wie Du richtig sagtest, sind movlw und movwf neutral was das Z flag angeht.
Eine arithmetische wie logische Operation die zum Ergebnis 0 haben, könnten sich darauf auswirken(Z flag), aber das kann ich ausschließen.
Irgendwas muss ich übersehen haben.

Gruß
lk

[PicNick]

Es war da, da ein Überlauf stattfand.
Das klingt mehr wie eine Schlußfolgerung.

Egal:
Stepp' dich mit dem MPLAB mal VOR den "incf", und dann mach single steps bis zum "rrf".
Und nimm' nix an, sondern kontrollier' es

[stowoda]

Stepp' dich mit dem MPLAB mal VOR den "incf", und dann mach single steps bis zum "rrf".
Bei eben diesem Vorgehen fiel es mir ja auf.
Aus diesem Grund sah ich mich in einer Sackgasse und beschloß hier zu fragen.

Gruß
lk

[PICture]

Hi stowoda!
Deine Frage ist nicht prezise genug um eine Antwort zu geben. Um was handelt sich genau? Der Z Flag wird in der Befehlsfolge, die Du am Anfang listest sicher nicht gelöscht, aber bis zum Label "one" sind noch ein paar Befehle, die vielleicht den Z Flag beeinflüssen können.
MfG PICture

[stowoda]

Hey PICture!

Du hast recht, es könnte etwas Einfluss nehmen auf das Z flag, was sich noch davor befindet.
Wenn ich das Ganze allerdings simuliere springt Z von 1 auf 0 genau in dem Moment, indem der PC von Zeile (movwf temp) zu Zeile (rrf temp)
springt.. Ok, diese Tatsache schließt nicht aus, dass früher etwas Einfluss nimmt, aber ich wüsste es. Schliesslich habe ich das Programm geschrieben.
Nur wo habe ich den Fehler gemacht?
bzw.
Was übersehen?


teil_2o
incf y, f
movlw .1
movwf temp
rrf temp
rlf data_2
goto bitempfang

[PICture]

Hi stowoda!
Ich habe keine Erfahrung mit Simulationen und teste alle Programme auf einem echtem PIC Controller an den eine echte Hardware angeschlossen ist. Alle Simulationen halte ich als Zeitverschwendung. Vielleicht ist der Fehler in der Simulation?. Deswegen kann ich Dir nicht weiterhelfen.
MfG PICture

[stowoda]

hmm..
Ich werde das Programm nochmal gründlich analysieren und falls dies zu keinem Ergebnis führt, werd ich die Hardware anschließen (müssen).
Denke so ein Simulatonstool ist eine Super sache, solange es bugfrei ist..
Obwohl dies noch zu beweisen bleibt, ich tippe eher auf einen Fehler meinserseits.

Falls jemandem doch was auffallen sollte wär ich dankbar für Tips.

Gruß
lk

[stowoda]

War wohl zu voreilig

[PicNick]

Deiner "INT_ROUT" solltest du ein RETI spendieren.
Wenn da sonst nix drin ist, hat das allerdings mit dem Z-Bit nix zu tun.
Noch was: bist du dir sicher, welcher befehl im Simulator grade gemacht wird und wo der Zeiger hinzeigt ?
denn "rrf" verändert das Z-Bit natürlich sicher.

[stowoda]

Deiner "INT_ROUT" solltest du ein RETI spendieren.

Danke für den Tip. Wie erwähnt ist das Programm sehr "frisch" und ich konzentriere mich auf das wichtigste bevor ich Schönheitsfehler beseitige, dennoch vielen Dank.

Mittlerweile hat sich der Schleier gelüftet. :)

Im Support-Forum von Microchip sind sie der Sache auf den Grund gekommen.

You are indeed being victim of a MPSIM bug, but not the bug you described. It happens that on 14bit cores, MPSIM sets the Z flag if a RRF instruction is executed!!!

Gruß und danke für die Hilfsbereitschaft
lk