allow DIRECT_PWM pages to be smaller than max channels
correct some over-eager register clearing in the global interrupt handler (NFC)
only sent TX events when using shared DMA (NFC)
zero out rx packet code and size to prevent errors with spurious callbacks
add a comment and check for offsets that are codes
make ADC readings interrupt driven
turn off iomcu updates when debugging
allow for correct number of telemetry channels
cycle between vservo and vrssi when reading adc
build adc with O2
prevent repeated rcout mode sets
add ESC telemetry if compiled in
add infrastructure to support propagating erpm and telemetry from iomcu
add support to propagate bdmask to iomcu
add support for EDT
scale voltage and current correctly when reading EDT data
ensure that telemetry data is reset
reset ESC telemetry data to zero if stale
ESC type and bdmask must be setup before the output mode
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
Andy Piper
bugobliterator
Andrew Tridgell
Peter Barker
Hayden
murata
Randy Mackay
TunaLobster
Iampete1
Jaaaky