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.
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.
Bootloader updaters were all broken due to recent
changes in LED configuration handling. Removing
LED support from the BU loads allows them to build
again, but they provide no feedback about when they're
finished writing flash.
The bootloader has been enabling pull-ups on all GPIO
pins during early init. These pull-ups are disabled
immediately before jumping to the firmware. This transition
results in all servos seeing a wide pulse as the board
resets making them jerk sideways aggresively and then snap
back to neutral.
All channels at max when using the FrSKY 4ch D4FR in PPM
mode results in the frame pulse shrinking well below our
threshold of 3800us and we lose frame.
With all 8 channels at max, the frame pulse becomes
indistinguishable from the other channels. Using all 8
channels with the FrSKY in PPM mode is NOT recommended
even after this change.
Recommend using at most 7 active channels in this mode so
we can still find the frame pulse.
The Entire Flash (EF) image for revo has a gap between
the end of the BL bank and the start of the FW bank.
This fills the gap with 0xFF and properly aligns the
FW image in flash.
