This is a change in bevaiour. The previous behaviour was to check for a
NACK, and if it wasn't a NACK it was assumed to be an ACK. This is a bad
assumption to let people get away with, because in the future if we ever
add other options to the enum we are more likely to have to cope with
bad implementation in the wild
add separate driver for W25N01GV triggered via HAL_LOGGING_DATAFLASH_DRIVER
move flash_test() into AP_Logger_Block.
cleanup use of 4k sector commands to account for chips that only have block commands
on each boot write crash_dump.bin to the microSD if it is available
this makes it easier for users to send in their crash dumps, and less
likely they will overwrite it with a fw update
this fixes two issues:
The first issue that if we are missing a log file in the middle of the
list then it was not possible to download recent logs, as we get the
incorrect value for total number of logs. This happened for me with
107 logs, with log62 missing from the microSD. It would only show 45
available logs, so the most recent logs could not be downloaded.
The second issue is that get_num_logs() was very slow if there were a
lot of log files in a directory. This would cause EKF errors and ESC
resets. Using a opendir/readdir loop is much faster (approx 10x faster
in my testing with 107 logs on a MatekH743).
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
the key fix is the reset of the fd to -1. Without that fix we only
ever log @SYS/uarts.txt
The timing change is needed to get the files out in a reasonable
time. The function is actually getting called at 100Hz or less, not
1kHz (measured on MatekH743 copter at 400Hz). So we need to run it
faster to get the files logged in a reasonable time