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.
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
* added comment
* replaced "~0" with the appropriate macro
* resolved -Wconversion
* saved some space by modifying AP_Param::add_vector_suffix (writing
behind buffer could happen, if buffer_size is almost uint16_max but this
can surely be ignored)
further reading:
http://stackoverflow.com/questions/809227/is-it-safe-to-use-1-to-set-all-bits-to-true
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!
- Allows use of hardware floating point on the Cortex-M4.
- Added "f" suffix to floating point literals.
- Call floating point versions of stdlib math functions.