The debug messages are too verbose to be run in a production vehicle and inherently were something that should only be run in SITL / debug sessions on hardware. Switching the flag to the PX4_DEBUG() macro does not only make this more explicit, but also saves a lot of flash space that otherwise was consumed by the strings.
This bound can be quite tight, because:
- The system still behaves well, even if all FD's are used (as opposed to
a stack overflow)
- The amount of used FD's is typically only increased one at a time
(e.g. adding new logged topics, adding a mavlink stream, ...)
- reducing CONFIG_NFILE_DESCRIPTORS to the minimum frees up a considerable
amount of RAM on systems that need it
it's a lot more readable and battery draining stops exactly at the empty battery voltage which makes debuging easier because it's directly predicatable
In rare circumstances, the buffer size was too small by 1 byte, leading
to a param export failure. And leading to a reset of all params!
This could only happen when the last saved param was a float.
Also the realloc_ok initialization is not needed.
Some modules call this (and maybe in rare circumstances), which could lead
to stack overflows. With our current headroom of >= 300bytes, 256 should
be ok.
This increases the export time from ~28ms to ~34ms in my case (on a
Pixracer)
No functional change, but this avoids numerical issues in the check routine. Since the routine will tend to false positives, we will tend to send more param updates than required in case of numerical noise of the float representation. This is desired, as we prefer to send two updates rather than not sending one.
Volatile parameters are ones that do not represent a fundamental configuration change but rather than incrementally changing settings. These include logged flight hours or sensor offsets. Marking them as volatile avoids these parameters forcing time-consuming telemetry updates.
Parameters can change not just based on GCS request, but also due to internal code or requests by a different valid connected control authority such a cloud service. This change ensures that all connected systems get updated via MAVLink asynchronously.
This helps subscribers to understand if they should update their parameters or not. We will extend this with other flags such as the current save status and alike.
Daniel Agar