Read data from EEPROM:
10
1
1
15
15
1
1
73
73
1
1
1
150
500
10
Done
So what I’m getting out of the EEPROM doesn’t match what I’m putting in there. I have searched this, and other forums, but not found a solution using put/get commands for eeprom Array in Structs.
Thanks! Thanks!
The first index has values of 0 and 1. The second index has values of 0,1 and 2.
I have not tested your sketch, but let us know what happens when you either enlarge the arrays to hold the indexes you need or limit the indexes to the array size you have.
Weird. If you had generated indexes in a loop you would have gotten several warnings that you were using undefined behavior (indexing off the end of an array). But using compile-time constants for indexing, NOT A SINGLE WARNING!
For example, adding this in setup():
for (int r = 0; r < 3; r++)
for (int c = 0; c < 4; c++)
pData.varArr[r][c] = 0;
causes these warnings:
sketch_aug28a.ino:28:26: warning: iteration 3 invokes undefined behavior [-Waggressive-loop-optimizations]
pData.varArr[r][c] = 0;
~~~~~~~~~~~~~~~~~~~^~~
sketch_aug28a.ino:27:23: note: within this loop
for (int c = 0; c < 4; c++)
~~^~~
sketch_aug28a.ino:28:26: warning: iteration 2 invokes undefined behavior [-Waggressive-loop-optimizations]
pData.varArr[r][c] = 0;
^
sketch_aug28a.ino:26:21: note: within this loop
for (int r = 0; r < 3; r++)
^
#define ArrayCount(array) (sizeof array / sizeof array[0])
for (unsigned int r = 0; r < ArrayCount(pData.varArr); r++)
for (unsigned int c = 0; c < ArrayCount(pData.varArr[0]); c++)
pData.varArr[r][c] = 0;
Not warnings! But it is not related to my problem.
No. It has to do with the declaration of varArr [2][3];
It should be declared as varArr [3][4];
Arrary indexes are zero based. Two elements are 0 and1 and three elements are 0,1,2. If you want to store and retrieve elements from these elements noted below, you will need to declare a larger matrix. varArr[3][4]
You name the typedef twice with the same name. In C++ the word "typedef" is no longer needed. I made the name of the typedef and the name of the data better to distinguish from each other.
When the unique ID should tell if the data is valid, then that ID should be part of the data.
Using the "0x18fae9c8" twice in your sketch could cause a bug. Suppose the other one is "0x18fea9c8", then it is almost not noticable that it is wrong. I made a #define for it.
The names of the functions are confusing.
If you use always the same order of the elements of the struct in your sketch, then it is easier to check if there is a bug.