Pages: [1]   Go Down
Author Topic: creating a lookup table (array storage issues?)  (Read 2454 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
Full Member
***
Karma: 0
Posts: 221
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

My program size is fairly small and afaik I was not using up to much memory but there seems to be a problem when I use an array I declared for the purpose of a lookup table of value:

int ledfade[1024];

Any time I assign values to this array my program does not work. Once I reduced the array size to int ledfade[255] then it was ok.

I assum this is a memory issue?

What I am trying to do is create a lookup table of pwm values so that I can fade an led in what is perceived as a linear fashion.
 
The led controller has 10bit pwm registers so I used the simple code of:
Code:
int ledfade[1024]

for (int i=0; i<1024; i++) {
   ledfade[i] = (int)( (float) i*i/1024.0);
}

any tricks for freeing up some memory or doing this differently?
Logged

Norway@Oslo
Offline Offline
Edison Member
*
Karma: 13
Posts: 2033
loveArduino(true);
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Tip: Do not use a lookup table.

Or, you can store the array in PROGMEM


Example w/o array:
Code:
int getPWMValueAt(int state){
    return (int)( (float) state*state/1024.0);
}

Instead of analogWrite( 11, ledfade[120] ); you can use analogWrite( 11, getPWMValueAt(120) );

[edit]You where correct about the RAM usage, by the way.[/edit]
« Last Edit: July 22, 2009, 10:06:32 am by AlphaBeta » Logged

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 362
Posts: 17307
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Well your problem is related to understanding of the Harvard architecture used by the AVR processors.

There are three types of memory available in a typical AVR chip. For a 168 processor there is 16KB of flash memory that holds your program instructions, just 1KB of SRAM that hold program variable data (like your arrray's data) and 512 bytes of EEPROM of general purpose memory. An array would normally be assigned memory from the SRAM so it's clear that your array size is too large for a 168 chip.

 Possible solution would be:
Go to a 328 chip which doubles the memory available in each of the types. It's a plug and play replacement for most Arduino boards that use a 28 pin DIP package.

Or store your array in FLASH program memory using the PROGMEM function. http://arduiniana.org/libraries/flash/

You can also use the EEPROM memory to store array data and fetch it back but I think using PROGMEM is a cleaner way to go and the EEPROM is not large enough anyway if you are using the 168 chip.

Lefty
Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 221
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

aha! I should not have been so lazy and actually looked up the 168 specs!

I think I will use "PROGMEM" for now and then just get a 328 chip for future revisions.

thanks!
Logged

Seattle, USA
Offline Offline
Full Member
***
Karma: 0
Posts: 248
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

If the values in the lookup table do not change during execution, the array could be declared as a const int instead of just int.

Would that change the memory allocation?
Logged

.andy

Norway@Oslo
Offline Offline
Edison Member
*
Karma: 13
Posts: 2033
loveArduino(true);
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Code:
int x = 0;
const int y = 1;

Serial.println( sizeof(x) );
Serial.println( sizeof(y) );
Logged

0
Offline Offline
Sr. Member
****
Karma: 0
Posts: 388
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Would that change the memory allocation?
Are you asking if that would change where the compiler puts the array, in SRAM or in FLASH memory? I don't have access to an Arduino right now to "ask the machine," but maybe someone else could answer the question about the compiler's memory location assignment for const ints.
« Last Edit: July 22, 2009, 07:50:14 pm by TBAr » Logged

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 362
Posts: 17307
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I'm pretty sure that const variables still get assigned to SRAM memory ram not FLASH program ram, at least that is my memory from past threads on this subject.

Lefty

Logged

0
Offline Offline
Sr. Member
****
Karma: 0
Posts: 388
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

It looks like you're right.

I just had a chance to ask the machine, and both
Code:
int a[1024] = {0};
void setup() {}
void loop() {}
and
Code:
const int a[1024] = {0};
void setup() {}
void loop() {}
give
Quote
Binary sketch size: 976 bytes (of a 30720 byte maximum)

although it's a moot point for the OP, since the original code

Code:
ledfade[i] = (int)( (float) i*i/1024.0);
modifies the array, precluding the use of a const for the ledfade[] array anyway.
Logged

Seattle, USA
Offline Offline
Full Member
***
Karma: 0
Posts: 248
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Interesting. I would have thought that something declared as a const could be resolved at compile-time, like #define, and not require any permanent storage. But I'm not a compiler theory guy...obviously.
Logged

.andy

Global Moderator
UK
Offline Offline
Brattain Member
*****
Karma: 310
Posts: 26631
I don't think you connected the grounds, Dave.
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I would have thought that something declared as a const could be resolved at compile-time, like #define
Simple scalar types do, I think, but you can't do that with a const table, because the compiler can't know in what order it will be accessed.

What is annoying is that const tables are not automatically assigned to PROGMEM - I'm pretty sure they're copied to RAM from flash at startup, effectively taking up twice as much memory as necessary.
Logged

"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

Pages: [1]   Go Up
Jump to: