PIC16F1512 subwf not working

[G. Hoffman]

I'm having a problem which SHOULD be a super simple arithmetic operation. 

PIC15F1512, MPLab 5.35, so that I can keep using MPASM, because I don't feel like relearning PIC-AS for what is a very simple project.  I'm debugging it with a PICKIT3.

The problem I'm having is:

Code Select Expand


        movlw b'00111111'     ;check PNL_SW port
xorwf sPORTB,w
xorwf PORTB,w
btfss STATUS,Z
PortB 0-5 are six latched switches, and I'm trying to compare changes.  When I run the debugger, even when nothing changes, so sPORTB and PORTB are exactly the same (looking at the registers in the debugger, they are the same!), I'm not getting a result of zero.  I tried it with a subwf too, and that also isn't working.

Any idea what this could be?

[G. Hoffman]

DOH!!!!!! 

Never mind, I figured it out.  I was using the wrong op to filter out unused bits.  Should have been andwf, not xorwf.

[ElectricDruid]

DOH!!!!!! 

Never mind, I figured it out.  I was using the wrong op to filter out unused bits.  Should have been andwf, not xorwf.

I often find posting a question about something is a great way to then suddenly spot something obvious that you've been staring at for hours already!

Glad you've got it sorted, anyway.

PS: Like you, I'm reluctant to move away from MPASM. If I get a new laptop, I'll finish up having to use a recent version of MPLAB X and then I'll be forced to swap over. Since that then makes a large collection of legacy code basically unmaintainable, I'm not exactly in a hurry to do it, despite my current laptop being on its last legs.
Dropping MPASM was such a terrible decision by Microchip. Even the code in their own datasheets doesn't compile any longer! Imagine coming to that as a Newb and not knowing the history...you'd waste weeks trying to figure out what you were doing wrong.

[G. Hoffman]

DOH!!!!!! 

Never mind, I figured it out.  I was using the wrong op to filter out unused bits.  Should have been andwf, not xorwf.

PS: Like you, I'm reluctant to move away from MPASM. If I get a new laptop, I'll finish up having to use a recent version of MPLAB X and then I'll be forced to swap over. Since that then makes a large collection of legacy code basically unmaintainable, I'm not exactly in a hurry to do it, despite my current laptop being on its last legs.
Dropping MPASM was such a terrible decision by Microchip. Even the code in their own datasheets doesn't compile any longer! Imagine coming to that as a Newb and not knowing the history...you'd waste weeks trying to figure out what you were doing wrong.

You can always just download 5.35.  It's still up there.  But yeah, moving to a programing environment which doesn't match the code in the manuals is....unbelievably stupid.  Honestly, I'm just glad they got the PICkit3 actually functional before they came out with the Pk4 and Pk5 - it's been (quite) a while since I programed anything, and when I first got the Pk3, I had to get a Pk2 to get most things done. 

[G. Hoffman]

I was about to have to ask another question, but it turns out I just needed a movf instruction instead of a movwf.  One god damn letter.

I am definitely not cut out to be a programmer.  I got it working now, but I wanna go back to woodworking!!!!

[thomas642daniel]

I'm having a problem which SHOULD be a super simple arithmetic operation. 

PIC15F1512, MPLab 5.35, so that I can keep using MPASM, because I don't feel like relearning PIC-AS for what is a very simple project.  I'm debugging it with a PICKIT3.

The problem I'm having is:

Code Select Expand

Code Select Expand

        movlw b'00111111'     ;check PNL_SW port
xorwf sPORTB,w
xorwf PORTB,w
btfss STATUS,Z
PortB 0-5 are six latched switches, and I'm trying to compare changes.  When I run the debugger, even when nothing changes, so sPORTB and PORTB are exactly the same (looking at the registers in the debugger, they are the same!), I'm not getting a result of zero.  I tried it with a subwf too, and that also isn't working.

Any idea what this could be?

Have you considered that there might be an issue with how the inputs are being read? Sometimes, debouncing or even a noise issue on the input pins can lead to unexpected results. Also, I wonder if implementing a state change detection mechanism could simplify your comparisons. It's always interesting to see how different strategies can evolve when debugging these kinds of issues!