timmers
- 8th October 2014, 13:46
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
- 8th October 2014, 14:16
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
- 8th October 2014, 19:07
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.
HenrikOlsson
- 9th October 2014, 19:00
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
- 14th October 2014, 11:04
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
- 14th October 2014, 21:53
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.
Powered by vBulletin® Version 4.1.7 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.