In case a log ends abruptly, we will know that we have everything up to the
last second.
A test showed that CPU load and the amount of logging drops are unaffected
by this.
_uorb_topics_list was marked as 'const char *' array, which means the data
of the array was not actually const and thus landed in the data section
(so in RAM instead of FLASH).
The size of the array is 436 bytes.
When the timer callback is called at a higher rate than the logger can
execute the main loop (which is never the case under normal conditions),
the semaphore counter will increase unbounded, and eventually lead to
an assertion failure in NuttX.
The maximum semaphore counter is 0x7FFF, and when the logger runs at
default rate (3.5ms), the logger task must be blocked for 0x7FFF*3.5/1000
= 114 seconds continuously for an overflow to happen.
I see 2 cases where that could happen:
- the logger execution blocks somehow, or busy-loops in an inner loop
- a higher-prio task runs busy and hogs the CPU over a long period of time
_should_stop_file_log is set after disarming: logging continues for 1s
to measure the CPU usage.
During that time, other modules might change params (such as ekf), and
we don't need to have these the log. However currently all modules do
not notify the system when setting params after disarming.
Meaning this patch is not strictly needed, it's more a preventive
measure.
If logger is started very early, orb_exists() will fail for a lot of
topics, they will be advertised within the next few seconds.
Logger already dynamically adds subscriptions during logging, but if we
do that before as well, we'll avoid any delays and having to subscribe
to a lot of topics all at once.
To keep track of the configured interval, we store it as negative file
descriptor, until we do the subscription.
This frees up a considerable amount of file descriptors in most use-cases.
Daniel Agar