This requires support in the parsers, and thus the ULog file version is
increased.
As long as no data is appended, both, existing pyulog & FlightPlot, can
still read the new logs (they will output a warning).
The replay module will print an error, but still continue.
This will avoid file system corruptions in cases where px4_shutdown_request
is used. However it will not help obviously when the battery is pulled
directly.
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.
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.
- use uorb queue to not drop any info, only do 2 tasks per cycle
- also print a warning on low stack (which will be added to ulog)
this allows to gather statistics of each task's stack usage over time.
using scanf with %s reads until the first whitespace, which included the
comma (as per C standard and tested on linux). Behavior on NuttX differs.
This makes it work on both Linux and Nuttx.
in particular:
- SW release version (in addition to the git hash)
- OS version (tag + git hash if exists)
- mcu version & revision & UUID
- toolchain version
The uuid can be disabled via parameter, it's enabled by default.
boards define BOARD_NAME, so board_name() is not necessary. HW_ARCH was
just a wrapper around board_name().
This patch simplifies to having only one common method px4_board_name().
Instead use a single timestamp for subscription checks. This frees up
~800B of RAM.
Also make sure the subscription checks are distributed over time. On each
update, at most 1 topic subscription is checked. Reduces the load of the
logger from 7.3% to 5.8% (Pixracer)
ulog_message_info_header_s *msg = reinterpret_cast<ulog_message_info_header_s *>(buffer);
members of msg could end up unaligned, because of the uint8_t buffer.
tested on Pixracer: 14 still produces some dropouts once in a while, but I
think it's a fair tradefoff between RAM usage & dropouts. The queue needs
about 3.5KB of RAM.
When topic sizes/logging rates change, this will have to be reevaluated.
