transfer a string from ROM to an array

[Marcick]

Hi Richard,
maybe I'm doing some confusion and about to say something of funny, but I have a doubt:
How do you ensure in this code that you are in the correct bank reading the address of "buffer" ?

ASM
Flash2Ram macro buffer, msg ; Fills the buffer from flash msg
   movlw   UPPER msg
   movwf   TBLPTRU
   movlw   HIGH msg
   movwf   TBLPTRH
   movlw   LOW msg
   movwf   TBLPTRL
   movlw   low buffer		
   movwf   FSR2L
   movlw   High buffer
   movwf   FSR2H
   L?CALL  _bfill
   endm
ENDASM

[richard]

buffer does not actually exist its just a label in the macro , when assembled
@ Flash2Ram _buff , _String1 , produces

000168 0E00               M    movlw   UPPER _String1
0016A 6EF8                 M    movwf   TBLPTRU
00016C 0E01               M    movlw   HIGH _String1
00016A 6EF8               M    movwf   TBLPTRU
00016C 0E01               M    movlw   HIGH _String1
00016E 6EF7               M    movwf   TBLPTRH
000170 0E3E               M    movlw   LOW _String1
000172 6EF6               M    movwf   TBLPTRL
000174 0E1A               M    movlw   low _buff            
000176 6ED9               M    movwf   FSR2L
000178 0E00               M    movlw   High _buff
00017A 6EDA               M    movwf   FSR2H
                          M    L?CALL  _bfill

the label "buffer" is replaced with the symbol of the intended target
at no stage do we actually write directly to the "buffer" we simply load its address (from the symbol table) into the fsr regs
the bfill subroutine then fills the "buffer" indirectly via the fsr regs
macro's are not subroutines they are just another shortcut way to save typing, every time the macro is encountered the real code as above is inserted into your program

[Marcick]

Yes, but while _String1 is a fixed address that point to a univoque ROM location, isn't _buff a RAM location that points to different register according to the current bank ?
Marco

[richard]

evidently I'm not explaining it well
we never write directly to _buff we do it 'indirectly' via the 16 bit full address in fsr2 its called INDIRECT ADDRESSING read the chapter in the data sheet ,(this is how pic18's have arrays that can be bigger than a ram bank)
bank select is not applicable to indirect addressing

[richard]

observe symbol table

inbuff  var byte[30]
 buff var byte[30]       $500

SYMBOL TABLE
LABEL VALUE

_STVREN_OFF_4L 000000FE
_STVREN_ON_4L 000000FF
_StartLoop 00000168
_String1 0000013E
_String2 00000150
_TRISH 00000F94
_TRISL 00000F93
_WDTEN_OFF_2H 000000FE
_WDTEN_ON_2H 000000FF
_WDTPS_1024_2H 000000F5
_WDTPS_128_2H 000000EF
_WDTPS_16384_2H 000000FD
_WDTPS_16_2H 000000E9
_WDTPS_1_2H 000000E1
_WDTPS_2048_2H 000000F7
_WDTPS_256_2H 000000F1
_WDTPS_2_2H 000000E3
_WDTPS_32768_2H 000000FF
_WDTPS_32_2H 000000EB
_WDTPS_4096_2H 000000F9
_WDTPS_4_2H 000000E5
_WDTPS_512_2H 000000F3
_WDTPS_64_2H 000000ED
_WDTPS_8192_2H 000000FB
_WDTPS_8_2H 000000E7
_WRT0_OFF_6L 000000FF
_WRT0_ON_6L 000000FE
_WRT1_OFF_6L 000000FF
_WRT1_ON_6L 000000FD
_WRT2_OFF_6L 000000FF
_WRT2_ON_6L 000000FB
_WRT3_OFF_6L 000000FF
_WRT3_ON_6L 000000F7
_WRTB_OFF_6H 000000FF
_WRTB_ON_6H 000000BF
_WRTC_OFF_6H 000000FF
_WRTC_ON_6H 000000DF
_WRTD_OFF_6H 000000FF
_WRTD_ON_6H 0000007F
_XINST_OFF_4L 000000BF
_XINST_ON_4L 000000FF
__18F45K20 00000001
_bfill 0000022C
_buff 00000500
_inbuff 0000001A
main 000000EA
pauseloop 000000A6
pauseusloop 000000C2
ser2delay 0000007C
serout2bit 0000004E
serout2done 0000004A
serout2loop 00000022
serout2norm 00000068

[richard]

buff var byte[30] $4f0 ; buff is now straddles banks 4 and 5

_buff 000004F0 symbol table

code still works perfectly as expected

[Marcick]

Richard,
the source of my doubts is that I have some unexpected behaviours and I'm trying to understand where is the problem.
Watching the program memory, I found some "00" chars here and there in the middle of the string
Lets' say the string "Hello",0 when I look the program memory is 48 65 6C 00 6C 6F 00
I'm discovering now that the directive "da" is only for PIC12/16 and not for PIC18

http://ww1.microchip.com/downloads/e...Doc/33014J.pdf

I think I should use "db" or "data", I'm trying to understand

"db" seems to work fine