View previous topic :: View next topic |
Author |
Message |
j_s_connell
Joined: 02 Feb 2004 Posts: 17
|
Large const long arrays |
Posted: Wed Dec 08, 2004 1:08 am |
|
|
Anyone have any ideas on the best way to implement a lookup table of 1024 long integers? I don't mind that this will take up 2k of rom space.
ccs doesnt seem to let me define a const table bigger than 128 longs. (256bytes). I would need 8 tables and i find that annoying, but if I have to i'll do that.
Any tricks or information would be great- Oh, im using a 16F88 with no external eeprom. |
|
![](templates/subSilver/images/spacer.gif) |
RossJ
Joined: 25 Aug 2004 Posts: 66
|
|
Posted: Wed Dec 08, 2004 1:46 am |
|
|
You could create the table using the #rom directive. Then read it using the read_program_eeprom() function. Also, if you only need the table to contain integers upto 16K (or +/- 8K) then you can save space by storing each value in a single program word (14 bits). Otherwise you will have to store it in two bytes and make two reads to retrieve the whole value. |
|
![](templates/subSilver/images/spacer.gif) |
j_s_connell
Joined: 02 Feb 2004 Posts: 17
|
|
Posted: Wed Dec 08, 2004 3:43 pm |
|
|
Thanks for the tip on using the single word, I hadn't thought of it like that- its perfect because i only really need like 10 bits of it. However, i'm not sure if using the on chip eeprom will work, as there is only 256 bytes (I need 1k program words or 2k bytes). |
|
![](templates/subSilver/images/spacer.gif) |
RossJ
Joined: 25 Aug 2004 Posts: 66
|
|
Posted: Wed Dec 08, 2004 9:15 pm |
|
|
If you take a look at the reference manual you will find that the read_program_eeprom() function reads PROGRAM memory (ie. flash in your case). To read the 256 bytes of DATA EEPROM you would use read_eeprom(). |
|
![](templates/subSilver/images/spacer.gif) |
RossJ
Joined: 25 Aug 2004 Posts: 66
|
|
Posted: Wed Dec 08, 2004 9:50 pm |
|
|
Also, do you plan on putting signed values in the table? If so, you will need to sign extend the 14 bit value after reading them into an int16. This is done by testing if bit 13 is set and if so, setting bits 14 and 15 as well. Otherwise, the value read back will always be positive since bit 15 (and bit 14 for that matter) will always be returned as zero on a 14 bit PIC device. |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Fri Dec 17, 2004 3:03 pm |
|
|
I read in another thread that it might be necessary to generate this table by hand (in hex), and insert it into the compiled hex file after the fact (as ccs cannot generate a table this large). Any idea what the asm would look like, and where i would insert it into the hex file? |
|
![](templates/subSilver/images/spacer.gif) |
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Fri Dec 17, 2004 6:50 pm |
|
|
Anonymous wrote: | I read in another thread that it might be necessary to generate this table by hand (in hex), and insert it into the compiled hex file after the fact (as ccs cannot generate a table this large). Any idea what the asm would look like, and where i would insert it into the hex file? |
Wouldn't be asm but what Ross stated:
Quote: | You could create the table using the #rom directive. Then read it using the read_program_eeprom() function. Also, if you only need the table to contain integers upto 16K (or +/- 8K) then you can save space by storing each value in a single program word (14 bits). Otherwise you will have to store it in two bytes and make two reads to retrieve the whole value. |
|
|
![](templates/subSilver/images/spacer.gif) |
|