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.
this allows a HAL_PARAM_DEFAULTS_PATH to be specified for a build to
override the default parameters for a build. This is useful to build a
firmware that has different default parameters
This bug affected parameters where the defaults are overridden in the
object constructor. For example, a PID object may have a default value
for PID_D of 0.0, but have a constructor based default of 0.2. If the
user tries to set the value to exactly 0.0, then the set wouldn't happen,
as the value matches the value in the object default var_info[]
table.
This change ensures we force a save to eeprom if the value is changing
from the current value, regardless of the var_info[] default.
Thanks to Tom Coyle for finding this bug!
This bug meant that setting a parameter in a parent class for a doubly
nested parameter group, where the parameter index in the parent class
is 4 or greater would actually set the first element in that parent
class.
At the moment only one parameter fits these narrow constraints - the
RCn_DZ element of the RC_Channel_aux class. So if someone set RC5_DZ
to 17 in ArduPlane it would actually set RC5_MIN to 17.
this stores the default value for all scalar variables in the var_info
table, which makes it possible to avoid storing default values in
eeprom. That allows us to oversubscribe the eeprom space with a much
lower risk of overrun.
* Eliminates recursive calls inside AP_Param.
This is important to Pat @ Galois, but not the project in general.
Recursion depth on these functions is bounded structurally using
existing nested group constructors (can't create loops in finite space)
and checked at init time
We would like to be able to use Vector3f as a parameter while exposing
the individual elements of the vector as MAVLink parameters. This
change to AP_Param makes that possible, by giving AP_Vector3f a dual
personality
Andrew Tridgell
Lucas De Marchi
Peter Barker
Jonathan Challinger
Grant Morphett
Gustavo Jose de Sousa
tcr3dr
Tom Pittenger
Andrew Tridgell
tobias
Pat Hickey
Pat Hickey
Amilcar Lucas