setting HAL_USE_CAN uses the ChibiOS CAN driver instead of the AP_HAL
CAN driver. This is only used on the f103-periph as it significantly
reduces the size of the bootloader, which allows for f103 builds to
fit in the limited flash
on all other builds we are much better off using the HAL CAN driver as
it is much faster
refactor rcout into separate thread and process all dshot requests there
move uart DMA completion to event model
process dshot locks in strick reverse order when unlocking
convert Shared_DMA to use mutexes
move UART transmit to a thread-per-uart
do blocking UART DMA transactions
do blocking dshot DMA transactions
trim stack sizes
cancel dma transactions on dshot when timeout occurs
support contention stats on blocking locking
move thread supression into chibios_hwdef.py
invalidate DMA bounce buffer correctly
separate UART initialisation into two halves
cleanup UART transaction timeouts
add @SYS/uarts.txt
move half-duplex handling to TX thread
correct thread statistics after use of ExpandingString
set unbuffered TX thread priority owner + 1
correctly unlock serial_led_send()
don't share IMU RX on KakuteF7Mini
observe dshot pulse time more accurately.
set TRBUFF bit for UART DMA transfers
deal with UART DMA timeouts correctly
don't deadlock on reverse ordered DMA locks
change PORT_INT_REQUIRED_STACK to 128
and use CAN RX buffer size of 64.
This makes for more efficient CPU usage on f3, and fixes an issue with
lost CAN parameter replies causing timeouts in the CAN parameter
download protocol
this appears to be the root cause of the parameter resets on
CubeOrange. We need to ensure the CS pin is not floating or random
noise on the SPI bus for FRAM can cause the FRAM to become corrupt
Peter Barker
Andrew Tridgell
bugobliterator
Andy Piper
Tom Pittenger