mavlink log reads fail randomly, and you end up with a very large number
of log files as we keep closing logs off and then discovering we should
be logging
this prevents logging garbage for strings that are shorter than the
length specifier (eg. 'Z'). This assumes we will not want to log
binary data as strings
add support for log time to block logger
refactor rotation into backed. Don't start logs when erasing
correct log start logic
separate read and write points so that requesting log information does not corrupt the current log
when starting a new log stop logging first
clear the write buffer when starting a new log
insert utc time when requesting info for the current log
stop logging and request formats again when starting a new log
cope with erase happening while we are logging
keep pushing out startup messages even when format messages are done
don't log to the gcs in the io thread
don't start new logs in the io thread
don't validate logs while erasing
flush logs when stopping logging
account for page header when calculating logs sizes
don't return data when asked for more data than in the log
optimize locking and use separate semaphore to mediate ring buffer access
stop logging when the chip is full and send a notification
calculate logs sizes correctly even when they wrap
read log data correctly even when it wraps
add stats support to block logger
reset dropped when starting a new log
fail logging when the chip is full
refactor critical bufferspace checks
increase messagewriter budget to 250us and to 300us for FMT
Instead of creating a MessageWriter explicitly to log uploaded missions
we fiddle the state of the one stored in the startup message writer.
This has the advantage of being much more likely to log the entire
mission (as the buffer constraint is removed), and with the addition of
a time-remaining check much less likely to cause a timing glitch.
Previously tridge found that using const char * here meant that the
data segment (and thus RAM usage) would increase.
This doesn't seem to be a problem now.
this logs critical messages while disarmed if we have logged any
messages while armed. This fixes issue #7010 where log files show the
incorrect mode if the log includes any portions where the user
disarmed. It makes analysing users logs very difficult. It also
affects parameters, so we don't always know the true parameter values
in logs from users.
RC_Channel: To nullptr from NULL.
AC_Fence: To nullptr from NULL.
AC_Avoidance: To nullptr from NULL.
AC_PrecLand: To nullptr from NULL.
DataFlash: To nullptr from NULL.
SITL: To nullptr from NULL.
GCS_MAVLink: To nullptr from NULL.
DataFlash: To nullptr from NULL.
AP_Compass: To nullptr from NULL.
Global: To nullptr from NULL.
Global: To nullptr from NULL.
WriteBlockCheckStartupMessages returned true if finished writing out
all startup messages. However, that may have allowed the caller to
then write out their message - but the timestamp on that message would
almost certainly be lower than the messages we've just written out.
Peter Barker
Andrew Tridgell
bugobliterator
Patrick José Pereira
Andy Piper
Tom Pittenger
murata
Francisco Ferreira