[Edit - RW]
Preface:
This discussion was moved as it wasn’t directly relevant in the original thread. This post is an answer to this question about the way EEPROM data is handled:
[/edit]
@TrystanLea Not really, there was no discussion in the sense of a back and forth.
I understand the confusion a little better now, looking back at my message to Robert. I’d simple stated that I’d made changes and put it on github, which could easily of been interpreted as having changed the ‘master’ branch. @Robert.Wall I’m leaving it to you Robert. Do you think the issue I raised was important?
Your problem was your EEPROM had been initialised to valid (but nonsensical) values, which were accepted. It did not contain the default 0xFF that is expected of unused EEPROM memory.
I wrote a proposal for a comprehensive solution that would have allowed many sketches to use the available EEPROM without conflict, I put this forward to the ‘Staff’ but it received at best a luke-warm reception. I’ve not pursued it (though that doesn’t mean I won’t at some future time).
It’s strange that my eeprom had values other than 0xFF on a brand new device perhaps. The device was an uno copy, not official arduino, for a budget project… Is there documentation on what the default values are meant to be?
If my problem getting a tx shield to work is a minor issue pertaining to these non-official copies then the value of the work in implementing a signature check has to be reassessed.
I’ve remembered now, it was actually an official uno I used, not the budget uno from Conrad.
I think the question of whether there really is an issue, and how important it is to address, has still not been answered directly and clearly.
There is confusing information out there on a “cleared” EEPROM.
If you use avrdude to erase the chip (avrdude -e), all values are set to the factory default of 0xff, unless the “don’t erase the EEPROM” fuse is set (high byte, bit 3). This will also remove the Arduino bootloader, so don’t do this! I mention it only to indicate what the “default” value is supposed to be.
If you go to the Arduino EEPROM library and grab the “EEPROM Clear” example sketch, it will set all EEPROM values to 0x00, which is not “Cleared” by any definition in the datasheet.
That’s exactly as I understand it, the “as manufactured” state of any EEPROM is 0xFF. It is why the ‘erase’ option in the function writes that to ‘erase’ the stored values, and the reason why it looks for 0xFF to signify that the EEPROM is unused.
The realisation I came to this morning is that the EEPROM library example code includes a “Clear” example which does not reset the EEPROM to default, instead it actually fills it with zero’s.
Based on that would it be sensible to look for either 0xff or 0x00 in the EEPROM bytes to signify “unused”?
The 3-phase sketch follows exactly the same methodology as the emonTx V3 sketch in its use of the EEPROM, and backwards compatibility seemed an important consideration. My proposed protocol does consider 0x00 and 0xFF as indicating “unused” status.
I agree completely with this proposal, and as far as I’m concerned, it should go into all of the various versions of the emonTx firmware. Did that proposal go any further than that PM you sent previously?
That output comes from the config.ino file here
So the “nan” you are seeing is a direct result of Serial.println() trying to print those float memory locations that do not contain float values. The relevant EEPROM locations may in actual fact contain 0xFF’s but because the first byte of EEPROM did NOT contain 0xFF, the remainder of the values were assumed to be appropriate.
The relevant bits of code are line 48 and the section from lines 55 down to 75 here:
I understand now why you went to the effort of a proposal to them both regarding a change to the method.
The emonV3 sketch has not taken all possibilities into account it seems.
.
The response on the Arduino forum:
You will seldom, if ever, see an actual Arduino "factory" response.
A search brings up three different threads on the Arduino forum suggesting 0xFF is meant to be the default.
.
Checking for 0x00 or 0xFF is better I agree. Would there be a problem with backwards compatibility if 0x00 were used as a check?
.
A signature check would be an easy-to-implement change and relatively fail-safe, but isn’t backwards compatible.
No, is the short answer. As I wrote at the top (post no.2), I might pursue the idea at some stage.
The simple answer to anyone encountering the same problem that @danbates had, is simply invoke the “r - restore sketch defaults” option, which does in fact erase the EEPROM, whereupon the default values will be read from the sketch.
To move this forward Glyn and/or Trys need to make a decision on whether to implement one of the solutions at a future date, or not if they like.
When I made the signature check change of RW’s firmware Trys seemed to enjoy the idea. Not sure if it was the fact that I’d actually achieved something, or the work result.
Either solution will work, the simplest is the introduction of the 0x00 check, which I think will work fine.
