add UART6 and VBUS to BETAFPV F405
add alt config to BETAFPV-F405 to support RELAY2 instead of UART6_TX as per betaflight
enable SBUS input on BETAFPV-F405 on UART5_RX
enable IMU temperature calibration for BETAFPV-F405
correct current scale on BETAFPV-F405.
BETAFPV-F405 SPL06 Baro
correct baro SPI read rate on BETAFPV-F405
use SPL06 with background updates on BETAFPV-F405
AP_ADSB: uAvionix Transponder Status V3
+ Current version of ping200X sends the v1 status message periodically and the v3 status message in response to the transponder control message, so ardupilot needs to handle both gracefully; version 1 and version 3 are very different in structure and naively assuming one version over another will cause errors.
AP_ADSB: Process additional xpdr status v3 fields
AP_ADSB: Send GCS xpdr status at least every 10s
AP_ADSB: Send ping200X estimated HPL
+ When AP sends the ping200X the GPS data GDL90 message, it needs to provide a valid HPL for the ping200X to report a valid NIC.
AP_ADSB: Don't send unsolicited transponder status
AP_ADSB: Better initialization of xpdr id/config
AP_ADSB: Better initialization of frontend status
AP_ADSB: Suggestions from review
Lua opens scripts to load them into memory, then the logger opens them
after to stream them into the dataflash log. When loading multiple large
Lua scripts from ROMFS, decompression takes a significant amount of
time. This creates the opportunity for the Lua interpreter and logging
threads to both be inside `AP_Filesystem_ROMFS::open()` decompressing a
file.
If this happens, the function can return the same `fd` for two different
calls as the `fd` is chosen before decompression starts, but only marked
as being used after that finishes. The read pointers then stomp on each
other, so Lua loads garbled scripts (usually resulting in a syntax
error) and the logger dumps garbled data.
Fix the issue by locking before searching for a free record (or marking
a record as free). Apply the same fix to directories as well. This
doesn't protect against using the same `fd`/`dirp` from multiple
threads, but that behavior is to be discouraged anyway and is not the
root cause here.
We're using a value off the wire before it has been validated. That value is used to limit indexing into a buffer, and that buffer isn't big enough to handle all possible "bad" values that index could take on. Note that "read" here returns int16_t....
