Do NOT use the "String" object on an arduino, it will cause memory corruption and eventually a crash - use char arrays instead. When using EEPROM, I would suggest you to use get & put:
#define EEPROM_ADDRESS 123
uint8_t PHONE_NUMBER[6] = {44, 59, 59, 72, 32, 24};
//Store the number
EEPROM.put(EEPROM_ADDRESS, PHONE_NUMBER);
//Load the number
EEPROM.get(EEPROM_ADDRESS, PHONE_NUMBER);
//Convert to string
char buf[14];
sprintf(buf, "+%d%d%d%d%d%d", PHONE_NUMBER[0], PHONE_NUMBER[1], PHONE_NUMBER[2], PHONE_NUMBER[3], PHONE_NUMBER[4], , PHONE_NUMBER[5]);
Serial.println(buf);
The code is untested.
EDIT: "%d" in the format should probably be "%02d" in order to support leading zeros.
Eh?
But.... the Sim800L GSM library examples all use strings to send the number to the GSM module.
So I have to re-write the way those examples work? That totally sucks and is out of my ability I would think.
Why is the string Object so useless then? Isn't that a bit of a fundamental flaw?
Used strings many times before with other processors....
Brilliant
There are two strings only ever basically get declared at the boot in the variable declarations.
They are not likely to get changed during general running of the program.
The phone number gets 'set' in a settings routine that is probably only ever run once.
Hmm. That is the page I read. To be honest... I understand the Heap. stack stuff, but then just got lost. Beyond me.
I certainly don't understand how to replace my current code with something other than Strings.
My phone numbers for example.
They are read from 12x EEPROM addresses at the start of the code and put into the Users phone number String.
They can only be changed for a digit 0-9 in the users setup routine (which will very rarely be accessed - you only set your phone number once) and then written back to the same EEPROM address.
From then on, they are only ever recalled once at the boot to create the initial String. Is that going to cause an issue? They are not constantly changed.
I might throw this over to a Teensy, where I have more memory anyway.
I might have a go at changing the GSM code, but I just had a go and it didn't go well
Below is a snippet of the code. This part if anything is more likely to cause issues, as it's reading data from the GSM module:
Search for Robin'2's serial input basics tutorial. It shows how to read serial data into a string without using delays or blocking functions like readStrin().