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.
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.
param save is an expensive operation that can take several 100ms. And
previously it was possible that a param_get() caller was blocked on a
save operation. If this happened due to a param change notification,
important modules, such as sensors, could have been blocked for a longer
period (and affecting the flight performance).
With this patch, this situation is not possible anymore, because a param
save now uses the reader lock and a separate file lock.
However it is still possible that a param_set() needs to wait for a save
operation, thus blocking for a longer time. param_set() thus needs to be
avoided in important modules when the system is armed.
In the case of mavlink it works, since it does not affect the flight if
the mavlink receiver is blocked over a longer time. It is only problematic
if a joystick is used as input or in offboard control.
This can happen for example when a param type is changed from int32 to
float. The type check will then fail if the param is stored and the param
import will be aborted.
Now we just skip the entry and continue loading the rest.
The ramtron driver already calls SPI_LOCK when accessing the
FRAM.
Removed the interrupt lockout and anabled the SPI_LOCK
in the ms5611 driver on any HW where the
PX4_SPI_BUS_BARO == PX4_SPI_BUS_RAMTRON
This allows concurrent read access, which are much more common; reducing
potential lock contention and increasing concurrency.
Taking a lock is expensive, and the reader lock is now even more expensive.
An RCU synchronization scheme would reduce the overhead of the readers to
increasing/decreasing an atomic counter.
Thus this should only be an intermediate step until we move towards RCU.
Tested on SITL & Pixracer.
param_t is only used as an offset and we have <1000 params, so an uint16_t
is enough.
This saves roughly 1KB of RAM. We only do that on NuttX because normal
integers have better performance in general.
Previously on amd64, this was even 64bits because it was an uintptr_t.
If param_find() returned PARAM_INVALID, and this was directly passed to
param_get(), param_get_value_ptr() returned null and we read garbage data
(or segfaulted on systems with virtual memory).
On px4fmu-v2, this happened for the param ATT_VIBE_THRESH in sensors.
Because of the recently added parameter scoping, this param got pruned, as
it's defined in attitude_estimator_q.
credits for finding this go to Jeyong Shin (jeyong).
We need to protect access to the param_values array. This is dynamically
allocated and resized (utarray_reserve() calls realloc). If some thread
was iterating the array while another was resizing the array, the first one
would iterate on a freed array, thus accessing invalid memory.
On NuttX this could lead to hardfaults in rare conditions.
Unfortunately we need to initialize the semaphore on startup, by calling
sem_init(). This adds a param_init() method called by every board/config
that uses the params (at least I think I've found all of them)
Lorenz Meier