if you have a mission item for engine control with delayed start at
height and the engine is already running them it would put the ICE
subsystem into a state where it would no longer start the engine
It was actually 2 bugs:
- an engine control to do a height delayed start should be ignored if
the engine is already running. This prevents an engine control to
start the engine from stopping the engine
- a start_chan high should always try to start the engine
immediately, even if in the wait state
we need to tell the IO firmware that a byte was consumed when we first
detect a protocol as otherwise the next bad byte on DSM will lock us
on the DSM port
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
this sets the logging rate max when disarmed. In combination with
LOG_DISARMED=3 it gives a very nice setup to get always on logging
with very little addition to the log sizes. It is particularly useful
in combination with LOG_REPLAY=1
when LOG_DISARMED is set to 3 then we log while disarmed but if we
reboot without ever arming the log is discarded. This allows for using
LOG_DISARMED without filling the microSD.
LED processing on a separate thread allows much longer LED lengths to be handled without
compromising dshot timing or timeouts. The thread is also run at a lower priority to
reflect its lack of flight criticality
this was at 2 to reduce CPU load.
But particularly when CubeOrangePlus is playing around with auxiliary IMUs we really want to be running on SimOnHardware just what we're running on the normal firmware. We can find CPU cycles elsewhere....