For the process usage: we need to measure over a certain period of time,
then we can use the results. To avoid blocking, this does:
- after log is started, initialze the load counters, then one second later
add the results to the log
- after disarming: continue logging for one more second, then add the process
load to the log and stop logging.
- to avoid a delay, 'logger stop' will stop immediately and not log
postflight process usage.
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.
Just to make sure that it will never be used on NuttX. This is not an
architectural limitation, just a memory optimization, since we call
clearenv() on NuttX.
change fmu to task
increase fmu_servo task priority to max and enable true oneshot
use lowest FMU priority which minimizes jitter
constrain oneshot updates to control group 0 events
* mc_pos_control: use just float for vel and cruise in xy
* mc_pos_control: stick map saturate magnitude to 1
* mc_pos_control: take minimum cruising speed for auto
* mc_pos_control: cruise speed triplet higher than from mc_pos_control
mc_pos_control: fix if for cruise in auto
* mc_pos_control: use PX4_ISFINITE criteria
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.
* UAVCAN ESC output: removing ESC output channels from published message that are always zero. This allows the UAVCAN stack to always transfer only the minimum number of output values, avoiding redundant zeroes and the associated increase in bus load and CPU time
* Added a separate mixer file for CAN quadrotor
* Sampling profiler improvements
* PMSP: Output more endpoints
* Matrix update
* libc usage workaround
* Removed UAVCAN perfcounters
* Matrix submodule update
