dealing with very large rom tables

[Vector Research]

I need to store a rather large table in rom, However im coming up aganst the static const limitation of 255 bytes. Can anyone explain why the compiler was limited in this way? Is there another more elegant workaround rather than breaking up into several 255 byte long arrays?


Thanks

Vince

[chava]

Hi
you didnt mentioned what pic are you using so Ill assume 16c, 16f
The limitation results from the program memory structure: a table is a series of opcode: "retlw x" instructions where x is the value in the table.
now, when you access the table the pic calls this location with the index of the cell loaded into the W register. the W register value is then added to the Program Counter. the program counter is an 8 bit register so if W>255 then the "add" will cause a wraparount, like that:

pc is the first cell location in memory
W acts as an offset from the value of pc.
when W<255 : pc+W < pc+255 and thats O.K

when W>255 : pc+W =255 + (pc+W-255) => in 8 bit value its "pc+W-255" not "pc+W"

here is a numeric explanation:

when W=5, pc=5 W+pc=10- the cell is cell #5

when W=300, pc=5 W+pc=305=0x131, when you trunc this you get only 0x31 which is cell # 0x31=cell 49 not 300
hope I helped
chava

[Vector Research]

Thankyou for that excellent explaination.
I am using a 16f876, and i need to store some rather large bitmaps to send as icons on a graphic display.

Does this limitation go away if i go to an 18F part?




thanks

Vince

[chava]

hi
I dont know pic18
as I remember, ther is a methode of reading program memory in those kind of pics. you should check the section 5 in the datasheet to see realy how meny bytes can you access in those kind of pics
good luck

Chava

[schmobol]

To answer your question, yes your problems will go away with 18F. I personnally store a large quantity of Constant data in ROM with no limitation using 18FXXX chips. The instruction set of this familly implements a set of table read/write instruction that allow larger table than 256.

[Vector Research]

<monty burns voice> Excelent!!! </monty burns voice>

thanks

[John P]

You could store your data in the program flash, then access it via read_program_eeprom() or equivalent separate instructions. Note that if you do this you get 14 bits of data per address.

Trouble is, I don't think CCS gives you any way to write data into your code so that it gets placed properly in flash memory. When I've done this, I've written a little C program on the computer that generates a hex file from a text file containing the data, then spliced this into the hex file that the compiler produced. Not very elegant, but it worked.

If you use a programming method that doesn't erase the entire flash, you can keep data (in the highest area of memory, for example) intact while loading new code to another part of the memory.