Compiling using PBP mode causes funnies

[timmers]

When I compile a programme using PBPL, our product works absolutely fine. However, when I compile using PBP the product messes around and sends an incorrect checksum.
The programme does not use Longs.

Unfortunately I am not able to share the whole code, but here is an extract where we calculate the checksum.
Programme uses DT interrupts.

Device 18F46K22
Total compiled programme 61632 bytes
PBP 2.6c
MPASM v8.63

'================================================
DOUT:  IF TX2_FLAG THEN RETURN				'TX2 flag says we are still transmitting
			
            DATA_OUT [1] = "*"
            DATA_OUT [2] = "D"
            DATA_OUT [3] = "*"
            DATA_OUT [4] = HEAD_OUT
            DATA_OUT [5] = FUNC_OUT
            DATA_OUT [6] = PAN_OUT
            DATA_OUT [7] = TILT_OUT
            DATA_OUT [8] = ZOOM_OUT
            DATA_OUT [9] = FOCUS_OUT
            
            TEMP2 = 0
            FOR TEMP1 = 4 TO 9
            	TEMP2 = TEMP2 + DATA_OUT [TEMP1]
           NEXT
           ERROR_OUT = TEMP2 ^ $FF
           DATA_OUT [10] = ERROR_OUT
            
            POINTER_DOUT2 = 1					'start with byte 1
            TX2_BYTES = 10						'end with byte 10
            @ INT_ENABLE TX2_INT				'send it now via ISR
			
			RETURN
			
'================================================

Is there anything I should be looking at or is this just a funny fixed in PBP3?

[HenrikOlsson]

Hi,
So the ERROR_OUT variable gets assigned different values depending on if you compile with PBP or PBPL, even though all the input values are equal?
Can you share some typical values for DATA_OUT[4] to DATA_OUT[9] when it fails so we can try/verify? Or does it always fail, no matter what the values are?
Also, the variables in the code you're actually showing, are they BYTEs or WORDs?

When you compile with PBPL all the internal system and temp variables are 32bit variables and some operations are treated as LONGs even though the end result is "going into" a byte or word sized variable. Depending on what's happening with the value "along the way" so to speak it's possible that you'll end up with the "wrong" result. I don't know enough about the internals to say if your code might "suffer" from that but I guess it's possible.

If the program doesn't use any LONGs why are you compiling with PBPL to start with? You'll save a bunch of FLASH, RAM and cycles from not doing that (once you figure out how to make it work of course).

/Henrik.

[HenrikOlsson]

Hi again,
I just tried it here with 8 different sequences of bytes in DATA_OUT[4] to DATA_OUT[9] and it generates the same with PBP as it does with PBPL:

Program start with PBP

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,000,000,000,000,000,000
ERROR_OUT: 255

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,001,002,003,004,005,006
ERROR_OUT: 234

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,001,002,004,008,016,032
ERROR_OUT: 192

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,045,091,110,200,201,199
ERROR_OUT: 177

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,045,097,210,225,079,120
ERROR_OUT: 247

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,123,123,123,123,123,123
ERROR_OUT: 029

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,092,091,090,091,092,093
ERROR_OUT: 218

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,255,255,255,255,255,255
ERROR_OUT: 005

---------------------------------------

Program start with PBP

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,000,000,000,000,000,000
ERROR_OUT: 255

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,001,002,003,004,005,006
ERROR_OUT: 234

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,001,002,004,008,016,032
ERROR_OUT: 192

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,045,091,110,200,201,199
ERROR_OUT: 177

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,045,097,210,225,079,120
ERROR_OUT: 247

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,123,123,123,123,123,123
ERROR_OUT: 029

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,092,091,090,091,092,093
ERROR_OUT: 218

 0   1   2   3   4   5   6   7   8   9
255,042,068,042,255,255,255,255,255,255
ERROR_OUT: 005

Now, this IS with PBP3 but I'd be surprised if using PBP2.60C would make it any different. For reference, here's the exact code I used to generate the above output, compiled once with PBP and once witl PBPL:

DATA_OUT VAR BYTE[11]
TEMP1 VAR BYTE
TEMP2 VAR BYTE
HEAD_OUT VAR BYTE
FUNC_OUT VAR BYTE
PAN_OUT VAR BYTE
TILT_OUT VAR BYTE
ZOOM_OUT VAR BYTE
FOCUS_OUT VAR BYTE

ERROR_OUT VAR BYTE

PAUSE 2500
HSEROUT["Program start with PBP",13,13]

Main:
    HEAD_OUT = 0 : FUNC_OUT = 0 : PAN_OUT  = 0
    TILT_OUT = 0 : ZOOM_OUT = 0 : FOCUS_OUT = 0
    GOSUB DOUT
    
    HEAD_OUT = 1 : FUNC_OUT = 2 : PAN_OUT  = 3
    TILT_OUT = 4 : ZOOM_OUT = 5 : FOCUS_OUT = 6
    GOSUB DOUT
    
    HEAD_OUT = 1 : FUNC_OUT = 2 : PAN_OUT  = 4
    TILT_OUT = 8 : ZOOM_OUT = 16 : FOCUS_OUT = 32
    GOSUB DOUT

    HEAD_OUT = 45 : FUNC_OUT = 91 : PAN_OUT  = 110
    TILT_OUT = 200 : ZOOM_OUT = 201 : FOCUS_OUT = 199
    GOSUB DOUT
    HEAD_OUT = 45 : FUNC_OUT = 97 : PAN_OUT  = 210
    TILT_OUT = 225 : ZOOM_OUT = 79 : FOCUS_OUT = 120
    GOSUB DOUT
    
    HEAD_OUT = 123 : FUNC_OUT = 123 : PAN_OUT  = 123
    TILT_OUT = 123 : ZOOM_OUT = 123 : FOCUS_OUT = 123
    GOSUB DOUT
    
    HEAD_OUT = 92 : FUNC_OUT = 91 : PAN_OUT  = 90
    TILT_OUT = 91 : ZOOM_OUT = 92 : FOCUS_OUT = 93
    GOSUB DOUT

    HEAD_OUT = 255 : FUNC_OUT = 255 : PAN_OUT  = 255
    TILT_OUT = 255 : ZOOM_OUT = 255 : FOCUS_OUT = 255
    GOSUB DOUT
PAUSE 100
END



'================================================
DOUT:  
			
        DATA_OUT [1] = "*"
        DATA_OUT [2] = "D"
        DATA_OUT [3] = "*"
        DATA_OUT [4] = HEAD_OUT
        DATA_OUT [5] = FUNC_OUT
        DATA_OUT [6] = PAN_OUT
        DATA_OUT [7] = TILT_OUT
        DATA_OUT [8] = ZOOM_OUT
        DATA_OUT [9] = FOCUS_OUT
            
        TEMP2 = 0
        FOR TEMP1 = 4 TO 9
            TEMP2 = TEMP2 + DATA_OUT [TEMP1]
        NEXT
        ERROR_OUT = TEMP2 ^ $FF
        DATA_OUT [10] = ERROR_OUT

SendIt:
        HSEROUT[" 0   1   2   3   4   5   6   7   8   9", 13]
        For TEMP1 = 0 to 8
            HSEROUT[DEC3 DATA_OUT[TEMP1],","]
        NEXT
        HSEROUT[DEC3 DATA_OUT[TEMP1],13]
        HSEROUT["ERROR_OUT: ", DEC3 DATA_OUT[10],13,13]
RETURN

By the way, compiled with PBP it's 995 bytes. With PBPL it's 1173 bytes. Don't use PBPL if you don't specifically need support for LONGs (or don't care).

/Henrik.

[timmers]

Thanks for the responses, the typical values that exhibit a problem are

HEAD_OUT = 101
FUNC_OUT = 38
PAN_OUT = 0
TILT_OUT = 0
ZOOM_OUT = 1
FOCUS_OUT = 6

ERROR_OUT should calculate as 109 but the ERROR_OUT is 45?
All values are decimal.
All variables are bytes.
Array DATA_OUT has 15 elements

[richard]

is it possible to do some debug statements to find out if the value was correct at some stage and then corrupted

'================================================
DOUT: IF TX2_FLAG THEN RETURN 'TX2 flag says we are still transmitting

DATA_OUT [1] = "*"
DATA_OUT [2] = "D"
DATA_OUT [3] = "*"
DATA_OUT [4] = HEAD_OUT
DATA_OUT [5] = FUNC_OUT
DATA_OUT [6] = PAN_OUT
DATA_OUT [7] = TILT_OUT
DATA_OUT [8] = ZOOM_OUT
DATA_OUT [9] = FOCUS_OUT

TEMP2 = 0
FOR TEMP1 = 4 TO 9
TEMP2 = TEMP2 + DATA_OUT [TEMP1]
NEXT
ERROR_OUT = TEMP2 ^ $FF
debug temp2
DATA_OUT [10] = ERROR_OUT
debug data_out[10]
POINTER_DOUT2 = 1 'start with byte 1
TX2_BYTES = 10 'end with byte 10
@ INT_ENABLE TX2_INT 'send it now via ISR

RETURN

'================================================

you might be overrunning another array somewhere

just a thought snippets are notorious for their difficulty to debug

[HenrikOlsson]

Hi,
I tried the values in your latest post, got 109 from PBP as well as PBPL. Again, I'm testing with PBP3, I don't have any older version installed.
Please try the above code with your version of the compiler and see if it returns the correct values. If it does the problem, obviously, isn't related to that particular piece of code but perhaps to the ISR responsible for sending the data. You're going to have to narrow it down further and possibly post some more code if you find something that looks suspicious.

/Henrik.

[timmers]

Update:

The PIC is sending the correct data on the TX pin with both compilations.
The problem is in the RS485 Tx enable line.
With PBPL, the PIC sends data out and after a 2mS delay, sets the RS485 line to receive mode from transmit. But with PBP, the 2mS delay is not working, so it was dropping off halfway through the last (checksum) byte.

109 decimal is 0110 1101 or 10110110 in RS232
45 decimal is 0010 1101 or 10110100 in RS232

Now to investigate why the 2mS delay timer is different between compilations.
Many thanks for your help and suggestions.

Tim.

[HenrikOlsson]

Hi,
I'm glad you've been able to narrow it down a Little bit but as far as I'm concerned that's almost equally weird - as long as it's a hardcoded pause of course and not using a variable for the duration (which would still be weird but perhaps not as much). Are you running this on the same board (not two different but "equal" boards) with the same clock speed and everything, the only change you make is to switch compiler between PBPW and PBPL?

Anyway, if you want further help you're going to have to come up with more details and/or show the offending code.

/Henrik.

[timmers]

Hi Henrik,

Yes identical hardware, it just looks like PBP runs faster than PBPL!

Tim.

[HenrikOlsson]

Hi Tim,
Identical but not the same board?
I'm asking because I guess it is possible that one board isn't running at the correct speed....wrong x-tal populated for example.

PBP wil run faster than PBPL since the math routines will be 16 bit instead of 32 bit (doesn't matter if you're actually using LONGs or not). So if you're relying on a specific routine taking x amount of time then you can see a difference (depending on what the routine in question is doing) but if your using PAUSE or PAUSEUS there shouldn't be any difference at all.

/Henrik.