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
sched_note_{suspend|resume} were calling hrt_absolute_time before
it hrt_init is called. This can lead to register access before
clocking is enabled. The result is a hardfault.
Previously load stats were stored outside of the printloop, but
with the refactoring to save memory state was reset and used in
the first loop before the actual load calculations were valid.
Fixed by moving the summary info to the bottom of the top printout
after everything is computed. Also restructured the callback to
not depend on a line counter and fixed astyle glitches.
perf_counters is read from and written to by different threads and thus
requires synchronization. Without it we risk accessing invalid memory.
There are still remaining issues (see comment in code), they will not lead
to a crash however.
Instead of printing to an fd, this prints to a buffer and calls a callback
for each line. To avoid code duplication, the print_load has been refactored
to print to a buffer first, then print to an fd. The overhead is not
noticable, and the behavior of print_load is unchanged.
what could have gone wrong before? A scheduling switch during the printload
could have led to a task exit, rendering the tcb invalid. After switching
back, printload would access invalid memory.
This keeps the sched_lock() section as small as possible, just grabbing the
tcb variables we need.
32 bits are still enough to measure elapsed times up to 1 hour.
Testing on Pixracer: I counted 73 allocations and 39 frees during bootup,
resulting in 2kB RAM usage after boot. This patch reduce this by ~0.5kB.
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.
We need to differentiate between a level where the user should act and where we are about to fall out of the sky (emergency). This helps performing more suitable failsafe actions.
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)
We will be adding another parameter to set min starting temp, so this name needs to be made less generic.
Fixes typographical errors in the description
