PDA

View Full Version : Problem with << ?



BigWumpus
- 3rd August 2006, 19:57
Yesterday, i have a strange problem...

Code, that was working since weeks, doesn't work anymore....

I don't change the PIC (16F876), I don't update PBP, I only worked on the source (on other places) and has rearranged some variables to Bank0.

A subroutine convertes a byte to a word:
DummyW=(Dummy&%00011111)*15

The mainroutine has to double the word and store it to a word-variable:
Warte_Drive=DummyW<<1

There was a %00100001 in Dummy, so I get a %0000000000001111 in DummyW, but I get a %1000000000011110 in Warte_Drive after the "<<1"

Strange !

2 hours later I only change the "<<1" to "*2" and I get the supposed decimal 30 in Warte_Drive....

Bug ?

mister_e
- 3rd August 2006, 20:11
mmm are DummyW and Warte_Drive in bank0?

if so what about if your remove them from there?

i guess you could be out of 'space' in BANK0

What happen if you group all the BANK0 variable in the same block... i mean
Var1 var Byte BANK0
Var2 var Byte BANK0
Var3 var Byte BANK0

and later you list all other variable bellow BANK0 list. pure guessing so far.

BigWumpus
- 3rd August 2006, 21:11
Dummy... are defined to be in bank0,
Warte_Drive is located at $C2.

If there is some time tommorow I will test it again on the dedicated hardware and can deliver the .lst-files.
I use MPASM !

I just looked inside the lst-file.
I think there is an error !
DummyW<<1 is recognized as a 1-bit shift of a word-variable.
First, C is cleared. OK.
Then, RP is set to BANK0 in order to acces DummyW,
DummyW is rotated left into WREG,
RP is set to BANK1,
W is stored in Warte_Drive,
DummyW+1 is rotated left into WREG, (without choosing Bank0!)
W is stored in Warte_Drive+1.

There is a bug !

Here is the part of the lst-file:

06090 ; D:\_\ENTWIC~1\BIOFUE~1\BFC220~1.BAS 01795 Dummy=Cod_Time_Drive:Gosub Cod2Wert:Warte_Drive=DummyW<<1
06091 SHIFTL?WCW _DummyW, 001h, _Warte_Drive
M if (001h == 1)
1681 1003 M bcf STATUS, C
M if (_Warte_Drive == _DummyW)
[...]
M else
M CHK?RP _DummyW
[...]
1682 0D3C M rlf _DummyW, W
M MOVE?AB _Warte_Drive
M CHK?RP _Warte_Drive
[...]
1683 1683 M bsf STATUS, RP0
[...]
1684 00C2 M movwf _Warte_Drive
M CHK?RP _Warte_Drive
[...]
1685 0D3D M rlf _DummyW + 1, W
M MOVE?AB _Warte_Drive + 1
[...]
1686 00C3 M movwf _Warte_Drive + 1
M endif
M else
M MOVE?WW _DummyW, R0
M MOVE?CA 001h
M L?CALL SHIFTL
M MOVE?AWW R0, _Warte_Drive
M endif
06092

Bruce
- 3rd August 2006, 21:46
If you're using MPASM, start MPLAB, select the PIC you've compiled for,
then use File >> Import, and select the .COD file.

Next click View >> Program Memory. It's much easier to follow than looking
at cryptic .lst files generated by PBP. This allows you to view all code without
macros & includes all your routine labels making it very easy to follow all the
assembly routines PBP generates.

BigWumpus
- 4th August 2006, 07:49
puuuuhh....

I've never used MPLAB....


But, the bug must be inside the macro SHIFTL?WCW !
In front of the access to the high-byte of the source-word the CHKRP? is missing !

Melanie
- 4th August 2006, 07:59
I just thought I'd add an aside to this...

I have experienced a peculiar situation that perfect working code suddenly won't compile without a stream of compile errors.

Nothing had changed. No code, no compiler versions, nothing.

However, I run my PC 24/7 every day. It NEVER gets switched OFF. I must have maxed out memory (1GB) with a host of applications, and good old Windows XP Pro though working perfectly, somewhere behind the scenes had screwed up.

A REBOOT of the PC and everything was back to normal, but for a while I was wondering what on earth was happening with my code.

BigWumpus
- 4th August 2006, 08:25
@ Mel:
nice try ! ;-)

But, inside PBPPIC18.MAC:

SHIFTL?WCW macro Win, Cin, Wout
if (Cin == 1)
bcf STATUS, C
if (Wout == Win)
CHK?RP Wout
rlcf Wout, F
rlcf Wout + 1, F
else
CHK?RP Win
rlcf Win, W
MOVE?AB Wout
CHK?RP Wout <----- meeeeep
rlcf Win + 1, W
MOVE?AB Wout + 1
endif
else
MOVE?WW Win, R0
MOVE?CA Cin
L?CALL SHIFTL
MOVE?AWW R0, Wout
endif
endm



The marked part should be:
CHK?RP Win



Is this right ????

Bruce
- 4th August 2006, 14:09
I don't change the PIC (16F876),

But, inside PBPPIC18.MAC
Are you compiling for a 16F or 18F part?

BigWumpus
- 4th August 2006, 14:30
I compile for PIC16F, but there is the same error in PBPPIC18.MAC and PBPPIC14.MAC.

Bruce
- 4th August 2006, 14:50
Can you post your code with variable declarations?

BigWumpus
- 4th August 2006, 14:57
I don't want to post my source... it is one of our good cashcows.

But the error is obvious in the macro SHIFTL?WCW (and others) !
Before accessing an register, the RP-bits have to be set right. The programmer has interchanged Win and Wout.

Look at the SHIFTR?WCW-macro, it is right !

Bruce
- 4th August 2006, 15:26
I can't check the SHIFTR?WCW macro in version 2.46, but it looks fine in
V2.47, and definitely changes banks appropriately.

BigWumpus
- 4th August 2006, 15:41
@Bruce,

look at the SHIFTL?WCW in 2.47, it is right ?

Bruce
- 4th August 2006, 16:05
Nope. SHIFTL?WCW is not right. SHIFTR?WCW is fine.

Make this change;


SHIFTL?WCW macro Win, Cin, Wout
if (Cin == 1)
bcf STATUS, C
if (Wout == Win)
CHK?RP Wout
rlf Wout, F
rlf Wout + 1, F
else
CHK?RP Win
rlf Win, W
MOVE?AB Wout
CHK?RP Wout ' <- change this to CHK?RP Win and save it
rlf Win + 1, W
MOVE?AB Wout + 1
endif
else
MOVE?WW Win, R0
MOVE?CA Cin
L?CALL SHIFTL
MOVE?AWW R0, Wout
endif
endm