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.
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.
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.
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.
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 will is known to not work on WinXP without service pack 3.
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.
