I've encountered several problems using large arrays with Arduino
(V14,15 and 16 under Ubuntu). I'm trying to generate arbitrary
waveforms from a DAC, the code works great if the waveforms are
256 bytes long, but when they are around 800 bytes long bad values
are produced. Downloading similar code with a 3000 byte array
bricks the Arduino by overwriting the bootloader.
I tried putting line breaks within the data but that did not
change the behavior. No errors show up when compiling any
of this code.
You are most likely running out of RAM. You've only got 2k bytes to play with so an 800 byte array takes up a fair chunk. Now you say "bytes" but if you declare your array as:
int array[800];
you're actually taking up 1600 bytes since an "int" is 2 bytes.
When you say the 3000-byte array overwrites the bootloader, that suggests you're actually putting the arrays in FLASH? That was going to be my recommendation, putting the arrays in FLASH (using the PROGMEM keyword). But if you're already doing that.....then I don't know.
So can you clarify exactly what you're doing code-wise and what other RAM/FLASH resources are taken up by your program?
That sounds like a plausible explanation for why the longer arrays
don't work. However, when I take
working code with three 256 byte (not int) arrays and change
them to PROGMEM, the data becomes partially garbled.
I thought I'd start by trying PROGMEM on the working code before
trying the broken code that uses the longer arrays.
re: the response: The large array that overwrote the flash was NOT stored in
flash: #define STEPS 3840
byte wavetable[STEPS] = {0,.....};
...So, to wrap this issue up, some details:
I'm using an Arduino Decimilia board with the ATmega 168 cpu,
that's 16K flash and 1K RAM according to the Atmel data sheet.
Apparently, creating an array that's longer than the
size of RAM can compile without an error and if the array is
much larger than RAM, the bootloader gets corrupted. Fixing this
requires reflashing the CPU via a USBtinyISP board.
Putting the large arrays into PROGMEM seems like the logical
solution, but experiments produce corrupt data. More experimentation will be required here...
Make sure you use the PROGMEM datatypes when you use PROGMEM. I remember my sketches generated bizarre bugs with corrpt data at certain size limits when I used regular data types.
The PROGMEM docs continue to suffer banishment from management, so you have to dig for them.
Apparently, creating an array that's longer than the
size of RAM can compile without an error
Can and usually will. The compiler is very trusting about such issues. PROGMEM does work reliably (on my duemilanove at least. I embedded a couple of images for a recent projects using it; the largest one was about 5.5KB and could be read (in lots of small chunks ;)) without trouble.