Setting up sketch that sets different positions of a stepper motor depending which control button is pressed. I require that the user can change these default positions so that they become the default settings whenever the program is run. I can program the initial positioning, but need help in being able to change these settings on-the-fly and save them as the new defaults.
Welcome to the forum
Which Arduino board are you using ?
The solution may be different for different boards
Do you envisage the user doing this via
- LCD and pushbuttons
- Serial Monitor commands
- ???
The answer, along with your answer to post #2, define much. Post #2 defines a storage medium, while your answer to my question will define a programming approach.
+1 on those questions. it's doable but the code depends a lot on the user interface and board's type (EEPROM present or not for example)
Thanks for your quick response. User interface would be via LCD, Nextion Intelligent.
which Arduino or clone product??
by "program the initial positioning" do you mean hard-code in your program?
- on startup, values are read from EEPROM
- looks like you'll need a keypad for changing values, otherwise you can use the serial monitor
- add a cmd to write those values to EEPROM
Hi, I am using Arduino Mega 2560
Arduino Mega 2560
Then yes, classic EEPROM is your persistent storage, and @gcjr is correct. Use Serial for Serial Monitor debugging, and use Serial1, Serial2, or Serial3 for your Nextion connection. Further Nextion guidance will have to come from others, I know nothing about them.
Hi, thanks for the reply. Yes, on startup program will read initial positions. User will be able to change these, therefore require writing back to eeprom.
Store the targets in an array and use the EEPROM library put() and get() functions to read or store the values.
An extra flag (a uint32_t like 0xDEABEEF ) stored also in EEPROM at a known location would be useful to see if the EEPROM has already been initialized. (Basically in the setup you check for the presence of this value in memory, if it’s there you know you can safely read the preferences otherwise the memory is not correct and you should write there the default values and start the code with those).
more common to use 0xFF, whatever the EEPROM has from the factory
Using one byte could happen to be there by «mistake » if the board has been used for something else - having the 4 bytes in a row is less likely (unless you also used the same sentinel)
Maybe using a CRC is even better 
Allows you to detect data corruption.
i think you want to make sure nothing bad happens when a new unit is deployed with a fresh processor, that's why i suggested recognizing the values from the factory.
Better to use a 'signature', if you're in the habit of recycling devices from other projects; guards against "new processor" as well. I use 0xAA55 usually, and increment the 55 when I change a storage format. One project is up to 0xAA69, or thereabouts. Built-in information about what the config is, as opposed to should be; obviously, requires some software smarts as well, depends on how deep you want to dig.
But it's all YMMV from there.
CRC - even better indeed ! (Adds complexity for newbies)
I use a struct with version number and CRC so that I can upgrade and not loose the previous settings in case I update the code. But that more involved.
Any 'live' error check, such as a CRC or a more simplistic checksum, needs to be updated regularly; depending on the nature of the data that's changing, one could challenge the maximum writes limit for EEPROM quite quickly. This is a judgement the user needs to make. With a limit of 100k writes for any one EEPROM location, if 100 CRC changes happen per day, then 1000 days is the manufacturer's stated limit for writes. Sure, most experience is well beyond that, but no guarantees. That means you may encounter problems after 3 years of running.
Same applies to writing the actual data. The chance that the checksum is corrupt is just as big as the chance that an actual databyte is corrupt.
I'm not a mathematician but I think that the chances that a corrupt CRC matches corrupt data are quite slim.
And then there is always wear leveling 