I'm not sure how to put this right, but I have always liked the way with LP firmware how memory requirements are determined at boot time, and no additional memory allocations are done after that. There is actually only single place that what I have found that does allocate memory from heap after the system has booted, and that is, ironically at place where system is preparing for reboot.
Now this PR breaks that fine behaviour, however I have no idea or solution to offer that would keep the boot time memory allocation and also allow modules to be started later.
On the other hand, is it really necessary to start the modules on settings change, or would it be maybe better/less intrusive solution to somehow allow saving of uninitialised UAVOs as sent by GCS?
Changes give a chance to modules for start when needed and store settings without lost something.
The nice behavior you describe still required assuming the Boot alarm is always active for every HwSettings change and in fact need a reboot for normal / safe usage - arming / flight.
If you prefer not starting module it can be easily done by only initialize moduleSettings UAVO with 'live' module enabled and prevent module starting if Boot alarm is triggered
Enabling all settings objects is currently an issue with f1 only, but with simple fix in LP-432, it might even be okay to initialize them all. There should be a way to automatically init all objects marked as settings and I can look into it, but have no cc3d with me to verify the memory usage.
Anyway, I have tested the approach of automatically initializing all objects marked as settings, and that indeed works very well. F4 targets have no problems with ram usage of course, and F1 is good to go with LP-432 + removal of otherwise unused faultsettings uavo (??). The problem remains with F3, where ram usage increase does have significant impact, leaving quite less than without initializing all settings objects.
I have tracked down the ram usage, and while the uavo itself takes slightly more memory than data field size itself, it is the telemetry module which subscribes to changes in (all) uavos that consumes most of the ram.