It's for any data you want to preserve if you power the Arduino off and on again. I like to use it to save High Scores on little Arduino games.
Careful though, it has a limited number of write cycles so be sure your sketch isn't writing to the EEPROM on every pass of the main loop though, or it won't take long to get there. https://docs.arduino.cc/tutorials/uno-r4-minima/eeprom/
the EEPROM has also a limit of 100,000 write cycles per single location, therefore avoiding rewriting the same value in any location will increase the EEPROM overall life.
I suspect that it requires a deep understanding on "how it all works". I do not have that deep understanding but I found that the verify process in the IDE generates a map file and I had a look at the generated map files for respectively 4800x4 and 4900x4 bool arrays.
You can find the map files in the temp directory if you enable verbose output during compilation in the IDE. Compile your sketch, copy the output to a text editor and search for .ino.map; you will find something like below
It doesn't do anything useful but serves it's purpose. Below a table with the relevant data.
variable etc
start address
size
end address
.bss.outputArray
0x20000104/0x20000104
0x4c90/0x4b00
0x20004D93/0x20004C04
.heap
0x20005c10/0x20005a80
0x2000/0x2000
0x20007C0F/20005A7F
.stack
0x20007b00/0x20007b00
0x400/0x400
not relevant
The second, third and fourth column contain the info for 4900x4 and 4800x4 respectively separated by a '/'.
As far as I can see (and I'm absolutely no specialist)
The heap always uses 0x2000 bytes and the start address moves based on size of the outputArray variable.
The stack is at a fixed position (start address).
Doing the calculations you can see that the end address of the heap for 4900x4 bytes ends up in the space allocated for the stack. And that's exactly what the error tells you.
I did have a quick look around to see how this can be solved be reducing the size of the heap or changing other stuff but I did not find an obvious a way.
Hi @sterretje ...
... I don't know exactly why (it probably uses a different area of memory), but adding the keyword 'static' to the array seems to solve the problem ...
If you really have a bunch of bool, they aren't stored efficiently. sizeof(bool) is the same as sizeof(byte): one byte, which of course has eight bits. Each bit is either on ("set") or off ("clear"), just like a bool is either true or false. So
byte b[1000];
is effectively equivalent to
bit b[1000][8]; // `bit` is not a real type
You don't have to use all eight. Built-ins like bitWrite and bitRead (implemented as macros or functions) do the extra work to use them.
#define SIZE 1000
bool outputArray[SIZE][4];
byte outputBits[SIZE];
uint16_t cnt1 = 0, cnt2 = 0;
// these two are equivalent
outputArray[cnt1][cnt2] = digitalRead(cnt2);
bitWrite(outputBits[cnt1], cnt2, digitalRead(cnt2));
// and these two
Serial.println(outputArray[cnt1][cnt2]);
Serial.println(bitRead(outputBits[cnt1], cnt2));
Of course @kenb4 , but ... that doesn't solve the problem that on an MCU with 32 KB SRAM I can't allocate a 19660 byte variable without getting a linker error... and that's what we need to understand, not how to use the 8 bits in a byte...
So ... I have seen that, on my R4 WiFi, the limit for this #define is 4131, which is equivalent to a variable of 16524 bytes. With this value I get:
Sketch uses 52472 bytes (20%) of program storage space. Maximum is 262144 bytes.
Global variables use 23268 bytes (71%) of dynamic memory, leaving 9500 bytes for local variables. Maximum is 32768 bytes.
I tried on the MINIMA, the problem appears when the #define is 4834 and this is understandable ...
... the 'Arduino core' on the MINIMA occupies, for an empty program, 3940 bytes of SRAM, while on the WiFi is 6744 bytes ... 2804 bytes more, so, on MINIMA, you have free SRAM for 701 array elements (4 bytes each) more.
It seems that a memory occupancy greater than 23272 (71%) causes the problem ...
Based on the map file with the 8K for the heap and the 1k for the stack, it brings the usable maximum down to 32k - 9k = 23k. Probably some overhead somewhere and you get at your number.
... and that's what we need to understand, not how to use the 8 bits in a byte... 