To improve execution speed, I was thinking it would be nice to define and populate a one dimensional array in flash ram at startup and use it as lookup table, rather than perform the calculations on the fly.
However, from the docs and tutorials I've seen, only constants can go there.
Are there any workarounds, or should I drop this idea?
(Filling the array by hand is more trouble than it's worth--10,000 integers.)
However, from the docs and tutorials I've seen, only constants can go there.
You don't expect to change the values in the lookup table at run time, do you? If you do, you'll need to abandon the idea of using PROGMEM.
If not, then the data is, by definition, constant, isn't it?
How are they filled now?
A constant does not have to be a literal. the compiler can perform arithmetic to precalculate values for you, as long as all the input values are constants.
You do not have to hand-type the entire table. There are other ways, such as using spreadsheet formulas to calculate the values and insert the surrounding formatting.
I've seen, only constants can go there.
Hum, do you know the difference between: Flash memory, SRAM and EEPROM?
The table values would not be changed during run time.
Right now, I'm calling a function to supply the values several times in a time-critical loop. It works fairly well, but it would be better (I suspect) if it ran faster.
I had briefly considered using an external program like a spreadsheet to precalculate but the formatting process seemed like it would be ugly. Much more elegant to do it at startup.
I have a reasonable understanding of the different memory types. I need 20k for this table, and only the flash room for it.
Thanks to all of you for your suggestions. I must cogitate on it and do a little experimenting.
Write a simple sketch to generate your table values, serial print the values, comma separated, and use a terminal emulator to capture the values into a file, e.g. "lookup.table"
const PROGMEM int lookup [] = {
#include "lookup.table"
};
nixie:
Right now, I'm calling a function to supply the values several times in a time-critical loop. It works fairly well, but it would be better (I suspect) if it ran faster.
How complicated is this calculation? Please show the code
I need 20k for this table, and only the flash room for it.
This is a lot (for a UNO). What Arduino are you using? Your calculation may have room for optimization like calculating fewer initial values and interpolating between them.
nixie:
I had briefly considered using an external program like a spreadsheet to precalculate but the formatting process seemed like it would be ugly. Much more elegant to do it at startup.
How would it be ugly? You can use spreadsheet formulas to add whatever curly braces and commas you need too.
Thanks to all who replied. I wanted to learn what can and cannot be done with PROGMEM, and thought this would be a good vehicle to do so. I see now that there's no way for the arduino itself to prefill the table into flash (I was hoping there's a way to do it, perhaps in setup(), using some magical incantations.).
The function I was hoping to replace with the lookup table is pretty simple but it contained one floating point division. I know that's slow on these 8 bit processors, but I can live with it.
Is there a way to close a thread?
Again, thanks. You're all super-knowledgeable and patient with us newbs.
nixie:
Thanks to all who replied. I wanted to learn what can and cannot be done with PROGMEM, and thought this would be a good vehicle to do so. I see now that there's no way for the arduino itself to prefill the table into flash (I was hoping there's a way to do it, perhaps in setup(), using some magical incantations.).
This does sound like a good use of a lookup table. The problem isn't the technique you've chosen, it's insisting that the Arduino do it all by itself that's the problem. It's not "fake" or "not genuine" to generate a lookup table with some other program and copy+paste it into your sketch. Anything that makes your task easier is a benefit to you. A good programmer is a strategically lazy one.