mirror of
https://github.com/ArduPilot/ardupilot.git
synced 2026-10-28 04:38:55 +08:00
jaromc
079f8a69dc
AP_Periph was already assuming this behavior by never checking the write result of `select` and instead just sending frames and relying on the mailbox full check. This therefore fixes AP_Periph misordering multi-part messages. Each part is the same priority, so in priority mode the hardware transmits in slot order, which may not equal queue order. bxCAN based flight controllers no longer use priority now, but FDCAN always used FIFO mode so this brings the drivers closer anyway. In all cases before and after this patch, priority is maintained in libcanard so only the highest priority frames are dequeued for transmission by the hardware anyway. But if a high priority message is enqueued in the hardware, it will not be transmitted until lower priority messages in the hardware are sent first. This is against CAN priority semantics, where higher priority messages should be transmitted first. Fortunately, it has worked well in practice. (Though there was still the possibility for a higher priority message to be dequeued and not have space in the hardware even in priority mode).