use of DATA and READ

[smikes]

When using DATA in pbp, an optional label may be used. The assembler (MPASM) with an 18Fxxx part uses even address (WORD) boundaries for EEPROM BYTEs, thus the labels are on even boundaries.

BYTEs are aligned on WORD address boundaries when entered, according to the MPASM list file. How does this affect the use of READ i,j? Does the 'i' correspond with the WORD address boundary, or the actual byte offset in the table? If the label is based on a WORD boundary, must it be divided by 2, or used directly as the entry point in the table?

[Darrel Taylor]

Hi smikes,

Data, Read and Write operate on the EEPROM, which are byte sized locations. They are not affected by labels or word boundaries.

ReadCode and WriteCode work with Code space. For more info on these two, check out Melanies thread called "Making Program Code Space your playground... " in the Sample Code section.

Here's a link to that thread.

http://www.picbasic.co.uk/forum/show...=&threadid=137

Best regards,
  Darrel Taylor

[smikes]

Thanks Darrel,

But that's not my problem. I understand what the instructions do. I found the potential problem by examining the assembler code generated by MPASM win, v3.50. I actually found the answer when I spoke with Jeff Schmoyer. It's due to a compatibility issue between pbp and MPASM.

It seems that my version of pbp, 2.43, generated the asm instructions 'DE' per each byte requested by the DATA statement. The Microchip assembler, v3.50 and earlier, builds that instruction into WORDs, at least for the 18F family, thus tossing a byte of EEPROM each time. Jeff said they (Microchip) have never changed it, so he has a later version of pbp that solves the problem by using a different approach.

Thus, if anyone is using the EEPROM or DATA statements in a program targeted toward an 18Fxxx part, a compiler upgrade may be needed.