> What we have here is an MPLAB bug where each DB/DE directive always
> 'allocate'
> an even number of bytes.

Yes, it seems that way.  This the way DB is supposed to work, but not DE.
DE is supposed to allocate an entire word for each byte value.  I always
assumed this was done so that each DE value would reliably allocate one
additional EEPROM byte regardless of how many value there were per DE
directive.

I think they messed it up on the 18 series.  In fact, they can't seem to
make up their mind how the EEPROM data layout is supposed to be stored in
the HEX file.  I check with the simulator, and it expects each EEPROM byte
in successive addresses, not every other address.  What a mess!

Here is some source code I created as a test:

  .eedata  code    ee_start

           de      h'11', h'22'
           de      h'33'
           de      h'44'

           db      h'55', h'66'
           db      h'77'
           db      h'88'

           dw      h'99', h'AA'

And here is the resulting HEX file line:

  :100000001122330044005566770088009900AA0049

This means DE and DB work the same on the 18 family, with both adding an
extra padding byte when an odd number of values are given.  DW does work
as expected.  With this situation, there is no way to define EEPROM
initial values without having to be conscious of whether there are an even
or odd number of values per line.  This sucks.  I'll send a bug report to
Microchip.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.