next topic »

[on:]

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?

[Reply #1 on:]

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]

[Reply #2 on:]

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

[Reply #3 on:]

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!

[Reply #4 on:]

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?

[Reply #5 on:]

Code:

int x = 0;
const int y = 1;

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

[Reply #6 on:]

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.

[Reply #7 on:]

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

[Reply #8 on:]

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

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.

[Reply #9 on:]

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.

[Reply #10 on:]

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.