different icon to it. The description is still "CC3D" for "CopterControl".
The whole names/board types/etc really needs centralizing into
devicedescriptorstructure which should become a general class for checking if
firmware is good etc.
gained the parameter. However, objects that had overriden that method were now
creating a new method and not getting called at the right time. This fixes the
Output and Aircraft type panels
LED support was dropped from the BU images due to a lack
of proper abstraction for LED definitions between CC and
CC3D HW variants in the CopterControl board family.
Use the new LED abstraction to hide board revision details
from the BU image so it can once again flash some LEDs.
Every board has at least one LED (HEARTBEAT). Not all
users of LEDs need to be directly aware of which LED
configuration to choose when there may be more than one
possible configuration.
Hide the details of the differences between LEDs used in the
different HW revs for CC. This will allow generic code to
run on CC and CC3D without being exposed to the details of
the different pins used for the LEDs.
Added "Average" as scope math function.
Changed averaging window size text edit box to be active only when math functions are selected.
Fixed bug introduced immediately prior by removing child redefinition of saveConfig.
Tried installing scroll wheel event filter for scope config plugin, but is not currently working.
CC and CC3D boards share the same FW image. This is accomplished
by checking the BOARD_REVISION field in the board_info_blob
that is stored in the BL partition in flash as we init the FW.
Make sure that the BU image only writes a BL image that has
the same BOARD_TYPE and BOARD_REVISION fields in the embedded
image as the ones currently in flash on the board.
This ensures that we never write a CC3D BL image onto a CC board
and vice versa. This check should prevent "bricking" a board.
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.
