Hi,

I wrote:
>> instead of using directive DE (or DW) always use DB.
>>
>> Like:
>> EE_ROMDATA      CODE    0xF00000        ; data resides in onchip =
eerom
>>         DB
>> 0x03,0x01,0x05,0x05,0xDC,0x00,0x00,0x00,0x00,0x00,0x00,0x00=20
>> #define A_STRING_OFFSET $-EE_ROMDATA=20
>> DB      "some number of bytes",0x00
>>
>> If you keep number of bytes on each separate DB directive line even,
>> then you'll have no padding with 'extra' zeroes by the linker.

Olin Lathrop replied:

>But then the data won't go into the HEX file according to Microchip's
>requirements on an 18 family PIC.  Successive EEPROM bytes are expected =
in
>the low byte of successive instruction words.  In other words, only at
>even addresss.  The odd addresses are ignored.

Hmmm that's very odd, these staments (comments removed for clarity):

EE_ROMDATA      CODE    0xF00000        ; data resides in onchip eerom
        DB      0x03,0x01,0x05,0x05,0xDC,0x00,0x00,0x00,0x00,0x00,0x00,0x00
        DB      CALC_LOW_BAUD(9600),0x03,0x00

Generate this in the hex file:

:1000000003010505DC0000000000000005030000FE

Looks alright to me ? I've had weird problems with using DW/DE before =
but
since I started using only the DB directive I've had none.
The project above is assembled/linked for an 18F452.

Where did you find the information that only even adresses is accepted ? =


/Tony

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body