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.
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.
USB device was being accessed prior to being initialized.
This resulted in a hard-fault or NMI when using any endpoint
beyond 0 or 1 which are init'ed by the BL. This broke VCP which
is on endpoint 2 (control) and 3 (data).
This bug was introduced in 5ad37e69 which stopped checking the
transfer_possible variable.
Use new PIOS_USB_UTIL_AsciiToUtf8() function to compose the
USB serial number rather than repeating that code for each
board.
All boards now append "+FW" or "+BL" to their USB serial numbers
to allow the descriptors to differ between FW and BL images.
Some versions of Windows will ignore the USB device serial number
if the string is not delivered with LANGID = English US 0x0409.
This is true regardless of the configured locale of the machine.
The serial number string descriptor was incorrectly null
terminated. The standard clearly states that there should
not be a null terminator.
Use new #defines to ensure that our strings are sized
properly.
BL images now always use hid-only.
FW images can use hid-only or hid+vcp but this is selected
ONLY at compile time based on whether PIOS_INCLUDE_USB_CDC
is defined.
CC uses HID+VCP by default now.
This makes the BL and FW images distinct devices with unique
serial numbers.
Windows (and maybe Mac) remembers the device descriptors and
the associated drivers based on this serial number. Providing
unique serial numbers for the BL and FW images allows us to
provide different sets of descriptors for the BL and FW images
without confusing these OSes.
BL version number is now also bumped to reflect the new
serial number generation algorithm.
Now that we have a USB descriptor for HID+VCP that works
on Ubuntu 11.10, MacOS 10.7.3, Win7-SP1-32bit,
WinXP-SP3-32bit, Win7-SP1-64bit.
VCP is known to not work on WinXP without service pack 3.
were consuming lots of memory. Probably should make a simple adc version that
just queries the line when needed since we are only using this data at 500 ms.
However, the accumulator scheme in place is quite good for averaging over time.
Also add a (temporary) field to allow storing some custom paths to select on
the fly. Later will be replaced with some code to fetch from the flash chip.
hardware revision it cannot know which pios_led_cfg_ structure to use.
Possibly this should be abstracted further into board_hw_defs to create
functions like board_init_led.
Also the BU should probably compare the hw_revision of the original and new
bootloader to make sure the user doesn't break their board.
