if we can't save a parameter due to the queue size not being large
enough then there is a coding error, likely the code trying to save
large numbers of parameters while armed
the cygwin build is not generating binaries failing with:
undefined reference to `AP_Param::load_param_defaults(char const volatile*, int, bool)
there is a 2nd problem that the CI test for cygwin doesn't fail when
the build fails. That will be addressed separately
when we load a VARPTR subtree we need to re-scan the parameter
defaults file from @ROMFS/defaults.parm in case there are defaults
applicable to this subtree
this fixes an issue with resetting of parameters when going between
4.4.x and 4.5.x on MatekH743, and on any other board using flash
storage where the storage size has increased from 16k to 32k between
4.4.x and 4.5.x
The problem is that when you update to 4.5.x the parameter code stored
a backup of parameters in the StorageParamBak storage region which is
in the last section of storage. When you downgrade to 4.4.x the
AP_FlashStorage::load_sector() code tries to load this data and gets
an error as it is beyond the end of the available 16k storage. This
triggers an erase_all() and loss of parameters
* This was undefined behavior in the C++ standard
* Use the safer options in AP_Common
* Removes a compiler warning
Signed-off-by: Ryan Friedman <ryanfriedman5410+github@gmail.com>
when a parameter is removed it leaves a gap in the index numbers. We
need to cope with that gap when we add the parameters in the script to
allow params to be re-ordered or removed
param class conversion was unconditionally overwriting the parameter
from the old parameter. This meant if the user has set a value in an
old firmware they could not change it in a new firmware.
I hit this with ARSPD_TYPE. I had previously set this to 0 in a
previous use of the board, and found that it kept resetting to 0 on
the new firmware when I tried to enable airspeed