The code here was never meant to maintain an "average" streamrate. It
was designed so that we would maintain a consistent clock in the face of
minor scheduling anomalies (like an EKF fusion step).
The way this is written, however, makes us spit out a message for each
of the intervals we missed - clearly not intended behaviour.
This was tested by inserting the following code:
void GCS_MAVLINK::update_send()
{
+ const uint32_t xnow = AP_HAL::millis();
+ if (xnow > 10000 &&
+ xnow < 20000) {
+ return;
+ }
+
this fixes an issue seen on one board which caused a watchdog on high
uart DMA load. We have reproduced the issue on another board by
forcing a very high DMA transfer rate on the same DMA channel while
also requesting very high transfer rates on the UART. The likely race
is in the DMA transmit timeout code, and the simplest fix is to lock
out interrupts during the DMA setup to ensure the tx timeout cannot
trigger during the setup
- Add an uint64_t header to allow easy detection of struct
- Add an uint16_t version
- MSB is for major release, compatibility break
- LSB for minor version, no compatibility break
- Add pointer size variable to allow decode of pointers
- Add vehicle type information
- Add board type and subtype to allow hardware identification
- Set type of fw_type to uint8_t since enum is declared as int
- Organize struct to be packed inside 32bits system
Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>
when we are looking for FPort input, we normally switch UART3 on the
IOMCU to 115200 to look for inverted inputs at 115200 baudrate. We
need to disable this switching when we have SBUS output enabled to
prevent a change in the SBUS output baudrate
Many thanks to afishman for finding this bug
Fixes#15522
this improves the display on the GCS when the GPS has not yet been
found. This is particularly important after a reboot, as otherwise the
GCS may display stale information from the previous boot