Best place for lookup table - #define, const rom, or EEPROM - Page 1
Forum section: electronics / general

author: steaky1212
author_rank: Regular Contributor
timestamp: June 26, 2013, 06:54:45 pm
content: Hi,I'm doing some work on a PIC18F, and I have limited RAM (Data Memory). Because of this I was wondering the "best" place to store a lookup table.As its an array, it automatically discounts #define.const ROM takes up Program Memory, but I'm only using 22% of the device at the moment. The data is protected against accidental modification.EEPROM uses up eeprom (obv), but I'm not using any of that atm, so I'm not too fussed. To protect the data, I can set a configuration bit.I dont believe there is a time overhead to using either method - so I am stuck between which one I should use.This might turn into a "how long is a piece of string", but does anyone have any successions regarding best practice?Thanks in advance,Steaky

author: Unknown
author_rank: Unknown
timestamp: June 26, 2013, 06:58:44 pm
content: I put immutable lookup tables and strings in program memory. I figure I have much more of that available than RAM, and at least under the AVR architecture, reading and writing to EEPROM takes a few extra steps. RAM is precious on an embedded device and I try to use as little of it as possible.

author: Codemonkey
author_rank: Regular Contributor
timestamp: June 26, 2013, 07:01:34 pm
content: If you're not going to ever want to change it, stick it in program memory. If its in EEPROM, there's always the remote possibility that some obscure brownout condition that will only ever happen when its in the customers impossible to get to site will result in it getting corrupted.

author: poorchava
author_rank: Super Contributor
timestamp: June 27, 2013, 06:16:53 am
content: As the other guys said: depends on the size of the table, end application and whether or not will the LUT have to be changed. If LUT doesn't change (like for example sinewave, byte->7seg decoding etc) then program memory. If there's a need to change often then eeprom. If it's only going to be changed from time to time (like sensor calibration) then you may go with program flash memory and store it in remote location away from the actual program (flash has higher density than eeprom on any given avr or pic, but iirc an order of magnitude worse write endurance.

author: Jeroen3
author_rank: Super Contributor
timestamp: June 28, 2013, 08:53:56 pm
content: For speed, SRAM.For size, FLASH.I would not even consider eeprom if you're not recalculating or updating LUT.But this also depends on which block of memory you put them relative to the other active memory when calling the lut, and how many internal memory buses your mcu has.

author: cthree
author_rank: Frequent Contributor
timestamp: June 28, 2013, 11:42:16 pm
content: macros are substituted so each time you use one you get another copy (think copy and paste or snippet). If you #define a table then each time you use it you get a separate copy in a new location in RAM.

author: Jeroen3
author_rank: Super Contributor
timestamp: July 01, 2013, 10:13:18 pm
content: That is why you implement lookup tables as (const) arrays.The location of the array can be anywhere. Manually (or by the linkerscript) copied to ram for speed, or just leave it in flash.