transfer a string from ROM to an array

[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

[richard]

how are you looking at the pgm memory , I think something is not right

for me the da and data directives produce exactly the same result , I left the da directive in, thinking I might try the code on a pic16f1825 for a learning experience , for 7 bit ascii data either will do (pic 18's can store 2x8 bit ,pic 16's 2x7bit )

the relevant listings

0
0013E 6854 7369 6920 00199  data "This is a string",0
          2073 2061 7473 
          6972 676E 0000

00013E 6854 7369 6920 00199  da "This is a string",0
            2073 2061 7473 
            6972 676E 0000

[Marcick]

Found the problem.

I have a string like this:

say "hello"

I use this format do declare it, the same format I was using with arraywrite

@ da "say",34,"hello",34,0

The result in program memory is that before each char 34 is added a char 00
If I use "db" instead the result is correct.
The pdf I linked before says that "da" is not for PIC18

[HenrikOlsson]

I think it might have something to do with the number of bytes (odd or even) in the string.
In both of Richards examples there's an even number of bytes (16 and 22) but your Hello string there's an odd number of bytes (5). I seem to remember an issue with this being discussed in one of the 'Strings in codespace' threads some years ago.

/Henrik.

[richard]

odd length strings , wastes space but not a problem


00013E 6854 7369 6920 00199 data "This is a string1",0
2073 2061 7473
6972 676E 0031
0000

00013E 6854 7369 6920 00199 da "This is a string1",0
2073 2061 7473
6972 676E 0031
0000