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.
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.
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.
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.
Support for receiver configuration (PPM, PWM and DSM)
There are still problems with Flexi port (not sure if related to a problem with my board) and Uart/SBUS that has the input always inverted.
The CC and PipX bootloader updater (BU) builds don't currently
work due to some recent changes in how LEDs are handled.
Remove them from the default BU targets so that the all_flight
target can build clean again.
Also fix a linker warning in OP build.
CPU was being hammered with FIFO empty IRQs if we queued data but
the host wasn't actively draining the FIFO.
This was entirely unexpected so this hack should probably be
removed once we can figure out why this was happening.
This is almost certainly hiding some other issue.
Make sure we don't clobber our endpoint configuration by
double configuring an Rx or Tx buffer against it. Wait for
the completion of the previous operation before allowing
endpoint configuration again.
Upper (COM) layer was calling down into the HID layer before
the HID interface had been enabled. This was leading to
interacting with the endpoint Rx and Tx FIFOs prior to init.
The FIFO config was then being clobbered when we the USB IF
was eventually enabled.
Error flags being set were causing flash erase operations to
fail. Not sure why these flags were set though so this might
be hiding some other problem.
HID driver was incorrectly giving back the HID interface
descriptor when asked for the HID descriptor. This should
let OP boards interact better with generic HID layer drivers
and also gives us nicer output in lsusb once the HID descriptor
is read.
