Printable View
I've noticed that the 'bytes used' line at the bottom of the screen is always an odd number, and just today, after compiling my latest, greatest, colonized program, the 'bytes used' number turned out to be exactly 1,000 bytes high (should've read 64,869, actually read 65,869). Checked with the .lst and .hex file, and with the window in the PICKit2 software. The 64,869 is the correct number.
Anybody had this issue yet? Or is it just me :)
Can't say if it's just you or not, but ...
I get the exact opposite.
Whatever I do, everything compiles to an Even number of bytes.
The number is reported by MPASM. MCS just passes it along.
Thought maybe there could be a problem when things go over 65535, so I made a quick test program that just uses however many NOP's you want to suck up program space.
It always reports the correct number of bytes, +4-6 that PBP adds.
Maybe you can try it to see if the results are different.Code:ASM
UseSpace macro Words
variable HighLoop = high(Words)
while HighLoop > 0
variable LowLoop = 255
while LowLoop > 0
nop
variable LowLoop = LowLoop - 1
endw
nop
variable HighLoop = HighLoop - 1
endw
variable LowLoop = low(Words)
while LowLoop > 0
nop
variable LowLoop = LowLoop - 1
endw
endm
ENDASM
@ UseSpace 33000
Are you using an @ db xx anywhere?
<br>
Not using any 'db' or 'dw' anywhere or anything out of the ordinary.
I do have a couple of macro's (the color LCD macros) going with numerous instances of those. However, I added a few lines just to get the total bytes used up to 65,535 exactly...came up correct, and again, still odd. Tried to force an even number using a few NOPs, couldn't do it. And this is again, only using an 18F4620.
Maybe it's a bug in the older version of MPLAB. I'm still running the 'stock' 7.62 of MPLAB, MPASM 5.13. (don't have a need for the newer version yet, if it ain't broke....)
I'll have a play with the above code later on...
EDIT: Updated to MPLAB 8.02 along with the latest PICKIT2 software/firmware (thanks Mr_E for the heads up). Same results, except that I haven't seen the count be 1,000 off. Now it's always odd and sometimes 1, 10, or 100 off. Haven't played with the code yet...
Yes, the bytes are -slightly- inaccurate just like you said. PBP and/or MCS adds a few bytes to the total...or does it?
I'm fairly sure MCS takes into account ALL bytes programmed...config bytes, eeprom, program space, everything.
In my situation, if I add together what the PICKIT software shows as the top of the program, add in all of the eeprom DATA statements, add in the eeprom used by my font, add in the 6 or so CONFIG fuse words, etc, it all adds up to the amount shown at the bottom of the screen by MCS.
Delete all of the DATA and EEPROM statements, and the total comes out to be about 4-6 bytes off. Remove anything resembling a CONFIG fuse from the .inc file, and the numbers are identical.
Figured it out? Doesn't sound like it.
Ok, so the unexpected used space is from the EEPROM or CONFIGs.
That's interesting. Never realized that was included in the the Byte total.
Now I can stop freaking out, thinking I'm only 100 bytes from the end, when there's 1K of EEPROM data too. Cause there's still 1K+ of program space left. Good news!
But it doesn't explain the ODD number of bytes. I've tried Configs, EEPROM, DATA, DB, DW, DA and no matter what, I can't make it come up ODD.
When you use the code above, does it give even or odd numbers. (in a program by itself)
<br>
Ok, now that is weird...I can't get it to come up EVEN!Quote:
Originally Posted by Darrel Taylor
If I use the above code, using 33000, obviously I get maximum address errors, but it still gives me 66015 bytes used. If I use 32000, I get 64015.
Not that it'll matter much, but this is the include file I use. I haven't modified any other files, PBP or MPLAB types...
Which PIC are you using for your testing?Code:;****************************************************************
;* 18F4620.INC *
;* *
;* By : Leonard Zerman, Jeff Schmoyer *
;* Notice : Copyright (c) 2006 microEngineering Labs, Inc. *
;* All Rights Reserved *
;* Date : 06/05/06 *
;* Version : 2.47 *
;* Notes : *
;****************************************************************
NOLIST
ifdef PM_USED
LIST
"Error: PM does not support this device. Use MPASM."
NOLIST
else
;original listing below
; LIST
; LIST p = 18F4620, r = dec, w = -311, w = -230, f = inhx32
; INCLUDE "P18F4620.INC" ; MPASM Header
; __CONFIG _CONFIG1H, _OSC_XT_1H
; __CONFIG _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H
; __CONFIG _CONFIG3H, _PBADEN_OFF_3H
; __CONFIG _CONFIG4L, _LVP_OFF_4L & _XINST_OFF_4L
; NOLIST
LIST
LIST p = 18F4620, r = dec, w = -311, w = -230, f = inhx32
INCLUDE "P18F4620.INC" ; MPASM Header
CONFIG OSC = HSPLL, FCMEN = ON, IESO = ON, PWRT = ON
CONFIG BOREN = OFF, BORV = 0, WDT = OFF, WDTPS = 32768
CONFIG MCLRE = ON, LPT1OSC = OFF, PBADEN = OFF
CONFIG CCP2MX = portc, STVREN = OFF, LVP = OFF
CONFIG XINST = OFF, DEBUG = OFF, CP0 = OFF, CP1 = OFF
CONFIG CP2 = OFF, CP3 = OFF, CPB = OFF, CPD = OFF
CONFIG WRT0 = OFF, WRT1 = OFF, WRT2 = OFF, WRT3 = OFF
CONFIG WRTB = OFF, WRTC = OFF, WRTD = OFF, EBTR0 = OFF
CONFIG EBTR1 = OFF, EBTR2 = OFF, EBTR3 = OFF, EBTRB = OFF
NOLIST
endif
LIST
EEPROM_START EQU 0F00000h
BLOCK_SIZE EQU 64
EDIT/UPDATE: I just tried an 18F4680 for grins...used 32000 for the code, got 64012 bytes used, 3 less than when using the '4620. Different formats in the PBP .INC file methinks...
Very interesting.
Confirmed, using that .inc file with the "New Config" style, it compiles to odd bytes.
And for more to ponder ...
I changed the CONFIG's, to the equivelent old style __CONFIG's, and it compiles Even again.
Go figure.
Code:;****************************************************************
;* 18F4620.INC *
;* *
;* By : Leonard Zerman, Jeff Schmoyer *
;* Notice : Copyright (c) 2006 microEngineering Labs, Inc. *
;* All Rights Reserved *
;* Date : 06/05/06 *
;* Version : 2.47 *
;* Notes : *
;****************************************************************
NOLIST
ifdef PM_USED
LIST
"Error: PM does not support this device. Use MPASM."
NOLIST
else
;original listing below
; LIST
; LIST p = 18F4620, r = dec, w = -311, w = -230, f = inhx32
; INCLUDE "P18F4620.INC" ; MPASM Header
; __CONFIG _CONFIG1H, _OSC_XT_1H
; __CONFIG _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H
; __CONFIG _CONFIG3H, _PBADEN_OFF_3H
; __CONFIG _CONFIG4L, _LVP_OFF_4L & _XINST_OFF_4L
; NOLIST
LIST
LIST p = 18F4620, r = dec, w = -311, w = -230, f = inhx32
INCLUDE "P18F4620.INC" ; MPASM Header
__CONFIG _CONFIG1H, _OSC_HSPLL_1H & _FCMEN_ON_1H & _IESO_ON_1H
__CONFIG _CONFIG2L, _PWRT_ON_2L & _BOREN_OFF_2L & _BORV_0_2L
__CONFIG _CONFIG2H, _WDT_OFF_2H & _WDTPS_32768_2H
__CONFIG _CONFIG3H, _MCLRE_ON_3H & _LPT1OSC_OFF_3H & _PBADEN_OFF_3H & _CCP2MX_PORTC_3H
__CONFIG _CONFIG4L, _STVREN_OFF_4L & _LVP_OFF_4L & _XINST_OFF_4L & _DEBUG_OFF_4L
__CONFIG _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L
__CONFIG _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H
__CONFIG _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L
__CONFIG _CONFIG6H, _WRTB_OFF_6H & _WRTC_OFF_6H & _WRTD_OFF_6H
__CONFIG _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L
__CONFIG _CONFIG7H, _EBTRB_OFF_7H
; CONFIG OSC = HSPLL, FCMEN = ON, IESO = ON, PWRT = ON
; CONFIG BOREN = OFF, BORV = 0, WDT = OFF, WDTPS = 32768
; CONFIG MCLRE = ON, LPT1OSC = OFF, PBADEN = OFF
; CONFIG CCP2MX = portc, STVREN = OFF, LVP = OFF
; CONFIG XINST = OFF, DEBUG = OFF, CP0 = OFF, CP1 = OFF
; CONFIG CP2 = OFF, CP3 = OFF, CPB = OFF, CPD = OFF
; CONFIG WRT0 = OFF, WRT1 = OFF, WRT2 = OFF, WRT3 = OFF
; CONFIG WRTB = OFF, WRTC = OFF, WRTD = OFF, EBTR0 = OFF
; CONFIG EBTR1 = OFF, EBTR2 = OFF, EBTR3 = OFF, EBTRB = OFF
NOLIST
endif
LIST
EEPROM_START EQU 0F00000h
BLOCK_SIZE EQU 64
Oh well, at least we figured out where the extra 1,000 or so bytes is going.Quote:
Originally Posted by Darrel Taylor
And besides, odd vs. even.....what's one byte between friends?
I think I found the root cause of the problem. Using MPASM 5.16 from MPLAB 8.02...
If you look at the bottom of a .lst file, it reports ALL bytes used.
Consider this cut/paste from the end of one of my .lst files:
-951 bytes free? It can't be!Code:All other memory blocks unused.
Program Memory Bytes Used: 66451
Program Memory Bytes Free: -915
Errors : 0
Warnings : 0 reported, 0 suppressed
Messages : 0 reported, 6 suppressed
When I checked the .lst file before, I only looked at the word at the last byte in the actual code itself, I didn't check the last line of the .lst file...