the Drotek F9 GPS ships with TMODE enabled, which means we don't get a
3D fix.
This also adds the VALGET/VALSET msgs we will need for automatic
moving baseline config
this fixes the case where we have one rangefinder that can handle
short range and another that is good for long range but no good for
short range (quite common, eg radar and lidar)
If possible we want to use the first rangefinder that is in range for
the right orientation. If none are in range then use the first for the
orientation
this provides a common location for static intermediate variables in
EK2 and EK3. This has a few benefits:
- the compiler can determine the address of the frequently accessed
variables at compile time, making them faster
- by sharing between EK2 and EK3 we save a lot of memory if both EK2
and EK3 are enabled
- we can fill all these with NaN in SITL on every loop, which allows
us to catch cases where the variables are ever re-used between
loops, which guarantees we aren't mixing data between EKF lanes or
between EK2 and EK3
these wait busy loops can take a very long time, and end up causing
interrupts to be lost elsewhere in the system, causing lost bytes on
UARTs
We should not have while loops waiting on peripharals like this. If we
do need to wait for a flag to clear then it needs to be done in a low
priority thread, or we need to check for completion in a timer
CAN still seems to work with this change, but needs flight testing
now that we persist logging for 15s after disarm we need to also delay
the log rotation if LOG_FILE_DSRMROT=1. Otherwise we will put the log
data into the next log, which defeats the purpose of the 15s
persistance
this frees up DMA for USART1_RX, which gives DMA for input over the
SERIAL5 WiFi port, which is important for applications where a
pixracer is being fed vision data over WiFi
when we have corrupt input due to loss of bytes on a UART we can end
up with a u-blox packet with zero payload bytes. When that happens we
need to bypass payload reading as otherwise we will end up keeping
reading bytes until the driver resets at 4 seconds, causing a GPS
outage.
This was causing GPS outages every few hours in copters running 3.6.7,
and was also reproduced in SITL using SIM_GPS_BYTELOSS.