MissionBase did not initialize its mission data, thus could enter an
infinite loop in updateDatamanCache() if the initMission() failed to
read the mission off, for example, due to the SDCard storage task taking
longer than the timeout to respond.
This change constrains the loading loop and resets the mission data even
if the data write failed.
When the CPU load monitor is started while already running, then the
idle thread last_times[0] is reset to the last 1 second, rather than
since when the CPU load monitor was last started. The remaining threads
are not impacted, since their last_times[i] is reset to zero here.
This results in the idle thread having a lower than real CPU load, with
the remaining CPU time being wrongly attributed as scheduler load.
The UART7 TXDMA services TELEM1 with flow control. If CTS is high, the
transmitting thread will wait on a semaphore, which may block other
threads from acquiring necessary resources to make progress, for
example, preventing MAVLINK instances from transmitting.
This change in NuttX makes the TXDMA acquire the semaphore in a
non-blocking way, preventing this issue.
We provide a latency measurement in the input capture handler.
However, since the timer was not enabled, none of the counter were
running therefore all counters were zero, thus latency was also zero.
Since the HRT is used to provide a timestamp, the lack of the running
timer was never noticed. After enabling the timer, latency now correctly
shows 9-10 counts.
This prevents the mavlink transmit loop from waiting on the module mutex
thus not stopping transmissions when the mutex is already taken.
This can happen when calling `mavlink status` from the mavlink shell,
where `Mavlink::get_status_all_instances()` takes the mutex and then
prints the status via pipes to the mavlink transmit buffer.
If that pipe cannot be emptied a deadlock happens.
Since the MavlinkReceiver thread also waits on the module mutex, both
reception and transmission of Mavlink packets are then prevented thus
disabling communications entirely.
Our serial_test showed only ~84kB/s with the default 256 RX buffer size
with significant ~2.5ms periods of the flow control RTS pin being
asserted. Increasing size to 600 (same as FMU-v5x) brings the throughput
only to ~190kB/s, while a size of >1500 achieves ~350kB/s. Larger RX
buffers do not increase throughput anymore, while the theoretical
maximum is 375kB/s.
Transmit buffer size is increased to 10kB same as on FMUv5x to prevent
any future differences in queue behavior and throughput. serial_test
showed ~350kB/s throughput at 3kB TX buffer size, so this is just a
precaution.
Niklas Hauser