The SET_LINE_CODING request contains data and must be
handled as such.
Previously, the only requests that had data were IN
requests. SET_LINE_CODING is an OUT request so it
required additional changes to support a new type of
data request.
The CDC interface is always advertised in the FW USB
descriptors. It is NOT always enabled/initialized at
runtime. Specifically, it can be Disabled in HwSettings.
Previously, any CDC-related query that the host would send
resulted in an assert and a watchdog.
Now, a suitable return code indicating that the request is
unsupported is returned in this scenario.
Scales each channel only based on max and min calibrated values.
The neutral value is now ignored so the joystick sees a linear
range between min and max.
This is particularly useful to allow the full range of values for
throttle to be passed through to the joystick.
Adds a new RCTransmitter setting for the USB HID interface which
emulates a USB HID joystick. The scaled RC receiver channels
from any RCVR protocol are passed through to the various emulated
joystick controls.
The main use for this feature is to allow you to use your own RC
transmitter with any RC simulator on a PC.
This is known to work with CRRCsim but should work with any simulator
that supports joystick input.
PIOS_Flash_Jedec_EraseChip is called during early
init when the table_magic has changed. This call
happens on CC/CC3D prior to the OS being initialized
so it is not OK to call vTaskDelay() yet.
This was leading to boards locking up (no flashing blue
LED) immediately after jumping to the application when
the table_magic had changed or was being init'd for the
very first time.
flash so it says completed. However, it still blocks the system for a long
time. During an erase the heartbeat will flash at 10 Hz to indicate what's
happening.
This still blocks telemetry even after lowering hte system priority (and there
is a vTaskDelay) which makes me think that the SPI bus being locked is blocking
Sensors or somethign else. This should not be permited when the system is
armed.
The reason the system locks up during the erase is that the file system
operations occur within the event dispatcher thread. It is very bad practice
for anything to block this (i.e. callbacks should never take very long). We
should probably move the object persistence handling into the system thread or
something but that can be a separate issue.
The bootloader needs to understand whether the USB cable
is connected. The HID and CDC drivers need to know if
the cable is connected _and_ the device has been enumerated
already. Separate these two concepts in the API.
Combining these was resulting in the BL not properly
detecting that the cable was plugged in, and trying to boot
the firmware image immediately. This effectively bricked
the board if you ever had an invalid firmware image.
It also happens to be the case that the BU images automatically
invalidate themselves after updating the BL so they don't run
again. The cable detect bug + this intended behaviour of the
BU image resulted in a bricked board after upgrading the BL.
