new event-based update() loop for iomcu to allow for DMA channel sharing
spin event loop at 2Khz to give dshot thread ample access to DMA channels
correct transmission complete callbacks
ensure peripheral is re-enabled on DMA resumption
ensure DMA transactions do not get clobbered by locking
restructure callbacks for shared and non-shared DMA cases
ensure RC updates happen at 1Khz
increase expected delay at startup
implement dshot ESC telemetry
add support for channel enablement/disablement
add stack checks and reporting for MSP stack
wait correct timeout in tickless mode
ensure that dshot sees all pwm updates as the occur in order to maintain periodicity
ensure dshot options are propagated on reset
implement dshot commands
ensure oneshot/125 and mode are setup correctly
add instrumentation for process stack
prevent illegal recursive locks
ignore requests for dshot 600
add support for soft reboot of iomcu
this fixes an issue where when you lose R/C input on IOMCU that you
may not regain it when R/C comes back.
The issue stems from us still processing the DSM uart when we are
using the SD3 "SBUS" uart for RC input, and still doing the switch of
the SD3 config every 2 seconds.
When we are not searching for a new protocol we should not be changing
UART config
if the IOMCU resets twice in quick succession then the code that
restores the safety state while flying can fail, leading to the
aircraft trying to continue flying with safety on
This results from two issues:
- a race in handling the last_safety_off variable
- the fact that plane sets the soft_armed state based on safety state
if a a message send fails to IOMCU then we were discarding all
currently pending non-recurring events. This means that states like
oneshot enable would be lost if the IOMCU reset.
We now re-trigger all events that have not yet been handled
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
