Jinx wrote:
>> Why?  There is no harm in having a table start on a odd address.  I
>> don't understand the problem you are trying to solve here.
>
> Hmmm, I thought there was a problem.

There shouldn't be.  The PIC 18 program memory is byte addressable, and
TBLPTR can hold odd values and even values.  Instructions do need to be even
aligned, but that has no bearing on data tables.  You do have to remember to
put data tables into a CODE_PACK section, not a CODE section.  Forgetting
that can cause padding to be added in unexpected places.

> For simulation, W was being
> sent to RAM pointed at by FSR0. Odd addresses weren't working,
> and, as you say, they should, but padding to an even address seemed
> to be a fix.

I'm not sure what you're saying here, as the FSRs point to data memory, not
program memory.  Whatever was going on is worth investigating since this
smells like a bug you don't want to cover up then have it bite you when
you've forgotten all about it later.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist