this prevents a race in sub where a set_default_by_name() directly
follows a parameter conversion for ARMING_CHECK. Without the flush the
default is written to storage by the IO queue draining after the set()
This stopped CUAVv5 from booting.
Also add some protection against having different parsers for the same
file format used for counting parameters and actually using them.
this moves both the storage scan and the save code out of the main
thread and into the IO thread. It means that if we have more than 30
parameters saves in very rapid succession while armed that we can lose
parameter changes, but that is extremely unlikely.
This fixes an issue where parameter saves in flight can cause
considerable scheduling problems, sometimes several milliseconds
Do not warn about unknown parameters on the first pass, i.e. when
AP_Param:load_all() is called. This is because we may still not know
about dynamically loaded parameters. When we call the second (last)
time, we expect to already know all possible parameters, so print a
warning to both console and the debug terminal.
Our track record on keeping parameters up to date with master is not
great and panic()'ing when loading them apparently is not helping
because every and each vehicle has a different file.
On aerofc load_defaults_file() is used in the same way as
load_embedded_param_defaults() is in which the panic() behavior has been
previously removed.
This finishes the removal of the panic param and add warnings to the
debug console when reading the parameters (rather than when counting
them).
this fixes a bug in how default file values are handled that affects
any common sub-objects. When we had a default value for something like
SERVO12_FUNCTION then configured_in_defaults_file() would return true
for SERVO1_FUNCTION as it shares a common default value pointer
this changes the implementation to use the object pointer instead
RC_Channel: To nullptr from NULL.
AC_Fence: To nullptr from NULL.
AC_Avoidance: To nullptr from NULL.
AC_PrecLand: To nullptr from NULL.
DataFlash: To nullptr from NULL.
SITL: To nullptr from NULL.
GCS_MAVLink: To nullptr from NULL.
DataFlash: To nullptr from NULL.
AP_Compass: To nullptr from NULL.
Global: To nullptr from NULL.
Global: To nullptr from NULL.
if we load an element other than the X element of a Vector3f via
MAVLink then the value reported back to the GCS would be at the wrong
offset in memory. This led to some very confusing results for users
Cast to the original type to use get function.
Still a hack but better than casting a pointer to an object which
memory mapping we are not supposed to know
"%S" is used for wide string, but we are passing a char*. Use lowercase
in this case to remove warnings like this:
libraries/AP_InertialSensor/AP_InertialSensor.cpp: In member function
'bool AP_InertialSensor::calibrate_accel(AP_InertialSensor_UserInteract*, float&, float&)':
libraries/AP_InertialSensor/AP_InertialSensor.cpp:620:61: warning:
format '%S' expects argument of type 'wchar_t*', but argument 3 has type 'const char*' [-Wformat=]
"Place vehicle %S and press any key.\n", msg);
^
Most of AP_Progmem is already gone so we can stop including it in most
of the places. The only places that need it are the ones using
pgm_read_*() APIs.
In some cases the header needed to be added in the .cpp since it was
removed from the .h to reduce scope. In those cases the headers were
also reordered.
prog_char and prog_char_t are now the same as char on supported
platforms. So, just change all places that use them and prefer char
instead.
AVR-specific places were not changed.
The PSTR is already define as a NOP for all supported platforms. It's
only needed for AVR so here we remove all the uses throughout the
codebase.
This was automated with a simple python script so it also converts
places which spans to multiple lines, removing the matching parentheses.
AVR-specific places were not changed.
This commit changes the way libraries headers are included in source files:
- If the header is in the same directory the source belongs to, so the
notation '#include ""' is used with the path relative to the directory
containing the source.
- If the header is outside the directory containing the source, then we use
the notation '#include <>' with the path relative to libraries folder.
Some of the advantages of such approach:
- Only one search path for libraries headers.
- OSs like Windows may have a better lookup time.