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.
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.
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)
* logger: prevent logpath buffer overflows
The handling of the log path had the potential to cause buffer
overflows, especially on POSIX platforms where the paths are often much
longer than just 64 chars.
* sdlog2: prevent logpath buffer overflows
When the log folder path was created, this was done with the unsafe
sprintf function instead of snprintf. This caused buffer overflows in
SITL but the overflow was usually not detected until recent testing of
some work in progress.
* logger: disable some default topics, which are most likely not used
This is also to safe CPU and lower the amount of file descriptors used.
* logger: use the hrt timer for more accurate scheduling
Under NuttX with the default rate of 285Hz, the actual measured rate was
only 200Hz while on Linux it was ~280Hz. The reason is that NuttX only
uses a usleep() granularity of 1ms, so that the typical sleep time is
longer than what we set.
Now the logger waits on a semaphore, which gets activated periodically
with a hrt timer. With this the measured rate is exactly the expected one,
285Hz.
Also, it's not clear where the allocation was. It looks like it was on
the heap, but the compiler could decide to put it on the stack. This is
very bad for us because we use fixed size stacks with tights bounds. So if
a user specifies a large topic to log, it could have crashed.
Now the allocation is on the heap and the user can specify any size of
topic to log (as long as there is enough memory).
it's not used in the logger, so don't store it there. It is accessed via
LogWriter::write.
This also makes sure the buffer size is >= _min_write_chunk and handles
allocation failure properly.
Beat Küng