protect Config

[elral]

Small change but a longer explanation:

Within readConfig() readBuffer[MEM_LEN_CONFIG + 1] is defined and a RAM area is reserved. Then the config (String cfg) is copied to readBuffer[].
In the nexr steps readBuffer[] is processed, all "." and ":" are exchanged to NULL (string termination) and for each device pointers are defined which are pointing to this reserved RAM area.
At the end of the function readBuffer[] this RAM area is released, but the pointer are sstill pointing to this RAM area.
In the following program it can happen, that additional RAM is required and that the remaining RAM area is not sufficient. In this case the released RAM area from readConfig[] is used and the config is mixed up.

Defining readBuffer[MEM_LEN_CONFIG + 1] globally will avoid that this RAM area will be used again.

I have an other idea not to double the config but still to use the original buffer. This would save additional 256 Bytes of RAM. Most is working but I need some more time to finish this. But for now I would stay with this change.

/edit: 256 Bytes for the ProMicro which is already short of memory

Fixes #14

[neilenns]

Nice catch. Just need Doc to review this too!

[MobiFlight-Admin]

If it is inside the method, my understanding is that the memory is allocated on the stack and on leaving the method the memory is freed.
Where do you see pointers pointing to the memory area?

[elral]

Mmmhhhmmm,
maybe I have a complete misunderstanding...
char readBuffer[MEM_LEN_CONFIG + 1] = "";
reserves a memory area for readBuffer[]. With
cfg.toCharArray(readBuffer, MEM_LEN_CONFIG);
the config (String cfg) is copied to this area.
char *command = strtok_r(readBuffer, ".", &p);
command gets a pointer to the first adress, the first "." is replaced by NULL
If the device is a button
params[0] = strtok_r(NULL, ".", &p); // pin
params[0] gets the adress after the first "." and the next "." is also replaced by a NULL
params[1] = strtok_r(NULL, ":", &p); // name
params[1] gets the adress after the second "." and replaces the coming ":" by a NULL
AddButton(atoi(params[0]), params[1]);
the function AddButton() gets the number of the button and a pointer which points to the memory area from readBuffer[].
In AddButton() this pointer to the name is stored in
buttons[buttonsRegistered] = MFButton(pin, name);
Isn't this still pointing to the memory area of readBuffer[]?
Or where is my msitake?

[MobiFlight-Admin]

You probably are completely correct. Maybe this was also not such a big deal in the past because I remember that I used to use String as parameter and later changed it for const char * wherever possible to save memory too... but it could lead to garbled names which in fact i have seen.

[MobiFlight-Admin]

Is there a need at all to copy the config buffer into another buffer? Hmm... thinking out loud here... while I am checking the code...

Yes, there is: from the strtok_r documentation
Each delimiter in the original string is replaced by a null character, and the pointer to which lasts points is updated.

So we have to duplicate the string... ok. This is also true for the strtok version (non re-entrant)

[elral]

@danecreekphotography, a copy of the config Buffet is not really required, I have a branch where I already tested it. But there is still some work required (after writing a config the Connector gives an error) I know what to do but is a little bit difficult during my vacation ;)
One disadvantage is flickering of the LCD if the Connector connect....
@MobiFlight-Admin, I think it is how Memory is used during run time. I am not the best in this, but my understanding is that this Memory area is only used a second time if now more Memory is available. So it is difficult to forecast...

[github-actions]

Firmware for this pull request:
Firmware.zip

[github-actions]

Firmware for this pull request:
Firmware.zip

[MobiFlight-Admin]

superseeded by #45 or #46