Timeline for Is EEPROM's location relocated on sketch compile?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 1, 2017 at 12:13 | comment | added | 6v6gt | Not all Arduinos, if you define Arduino as something which can run Arduino core code, have the same EEPROM concept. For instance, the ESP8266 simulates an EEPROM in a bit of flash memory. Clearly, however, in the OP's case an EEPROM as in say the atmega328p is being referred to and the problem is, as mentioned, that strings are not a primary datatype but an object, the data of which is not resident in the structure being saved. These should be converted to, say, an array of characters before being saved. | |
| Mar 1, 2017 at 0:42 | vote | accept | Florin Mircea | ||
| Mar 1, 2017 at 0:33 | comment | added | Florin Mircea | Let us continue this discussion in chat. | |
| Mar 1, 2017 at 0:30 | comment | added | Majenko | When you reload the objects from EEPROM the pointers point to areas of RAM that now are not allocated to the objects so give you gibberish. | |
| Mar 1, 2017 at 0:28 | comment | added | Majenko | You still aren't understanding what I am saying. Your struct does not contain your data . It contains objects that point to RAM which is allocated at runtime when the object is created where your string data is. | |
| Mar 1, 2017 at 0:26 | comment | added | Florin Mircea | My struct has a single variable called letter. I write it to eeprom, and I expect the /0 termination indicates the end of the string. Then, I add another variable to the struct. Another string, called title, before letter. Without writing, I read the new structure and observe that the title is gibberish then I can see my old letter further on. Where is the gibberish coming from and why is it before what I wrote before at address zero? This is basically what I don't understand. I do get that you are explaining that the struct itself is a reference. I don't get the field result. | |
| Mar 1, 2017 at 0:18 | comment | added | Majenko | You're missing the fundamental issue here. The issue has nothing at all to do with EEPROM. That is exactly as you assume it to be - fixed. You read from address 0 exactly what you write to address 0. The fundamental issue is that you are not writing what you think you are writing to the EEPROM. It's like you have stored the envelope a letter came in and burned the letter itself, then go back to the envelope expecting it to be the letter. | |
| Mar 1, 2017 at 0:16 | comment | added | Florin Mircea | There's my problem. "dynamically alocated at runtime". My thought was that EEPROM is a fixed data storage entity you can always address the same way, similar to old assembly addressing mode. The fact that the EEPROM chip is separate also allows me to sustain this assumption. Why would runtime execution allow data shifting? | |
| Mar 1, 2017 at 0:11 | comment | added | Majenko | The struct is saved and loaded fine. The point is that the string data isn't in the struct for you to save. The struct only contains the String objects, and those just contain a pointer to dynamically allocated (at runtime) memory for the string data. | |
| Mar 1, 2017 at 0:10 | comment | added | Florin Mircea | The assumption was that EEPROM starts ALWAYS at the same address. the struct defined above should be able to be loaded as long as the save is equivalent. And it actually is. Problem was that data is shifting in EEPROM and I don't know why. I read your answer many times and it still does not help me understand this. What am I missing? | |
| Feb 28, 2017 at 23:34 | history | answered | Majenko | CC BY-SA 3.0 |