Compiling using PBP mode causes funnies

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

Code:

'================================================ 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?

Re: Compiling using PBP mode causes funnies

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.

Re: Compiling using PBP mode causes funnies

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:

Code:

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:

Code:

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.

Re: Compiling using PBP mode causes funnies

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

Re: Compiling using PBP mode causes funnies

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

Quote:

'================================================
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

Re: Compiling using PBP mode causes funnies

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.

Re: Compiling using PBP mode causes funnies

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.

Re: Compiling using PBP mode causes funnies

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.

Re: Compiling using PBP mode causes funnies

Hi Henrik,

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

Tim.

Re: Compiling using PBP mode causes funnies

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.