This code was previously passing a pointer to stack
data into PIOS_USBHOOK_CtrlTx() which may be sending
this data asynchronously. Now pass a pointer to
static data so that the asynchronous send doesn't
tx random stack contents.
This code was mistakenly tracking the IN (device-to-host)
requests with data stages. It should have been tracking
the OUT (host-to-device) requests with data stages.
This tracking data is important now that CDC is supported.
CDC actually uses OUT requests with data stages whereas HID
does not. This bug only triggered once CDC was enabled.
CDC and USART device drivers were not all clearing their
device structs before using them.
This specifically caused crashes in the case where the upper
COM layer was binding only a Tx path. The Rx path callback
in the lower driver was uninitialized random data and would
result in the lower driver faulting when it tried to call the
callback.
Conflicts:
flight/PiOS/STM32F30x/pios_usart.c
flight/PiOS/STM32F30x/pios_usb_cdc.c
flight/PiOS/STM32F30x/pios_usb_hid.c
The CDC layer on F1, F3 and F4 now always acts like an
infinte data sink whenever *either* there is no DTE present
(ie. no terminal program listening) *or* the USB cable is
disconnected.
F1 and F4 were previously checking the cable but not the DTE.
F3 didn't check anything. The COM layer didn't even ask the
lower layers.
All of this used to mean that any time a caller did a blocking
send to a CDC device without a DTE, it would eventually block
for up to a 5s timeout waiting for space in the Tx buffer.
Conflicts:
flight/PiOS/STM32F30x/pios_usb_cdc.c
The req parameter is passed to the OUT stage as a convenience.
Since the OUT callback is called *after* the transfer has occurred,
modifying the req would have absolutely no effect. Marking this
as const makes this expectation clear.
Previously, the IN stage on the CTRL interface would write (and
send) its data via the buffer owned by the DATA endpoint. This
would probably have overwritten any data being sent at that
moment. This may have caused data corruption from FC -> GCS.
Now that multiple filesystem partitions are supported,
the UAVO manager needs to be specific about which partition
to load/save its objects to.
Conflicts:
flight/targets/CopterControl/System/pios_board.c
flight/targets/DiscoveryF4/System/pios_board.c
flight/targets/FlyingF3/System/pios_board.c
flight/targets/FlyingF4/System/pios_board.c
flight/targets/Freedom/System/pios_board.c
flight/targets/Quanton/System/pios_board.c
flight/targets/RevoMini/System/pios_board.c
flight/targets/Revolution/System/pios_board.c
flight/uavobjects/uavobjectmanager.c
***** PLEASE NOTE ***** From this revision all F4 based boards (Revolution/OSD) needs bootloader version 5 to boot properly
Conflicts:
flight/pios/stm32f4xx/libraries/CMSIS2/Device/ST/STM32F4xx/Source/osd/system_stm32f4xx.c
flight/targets/boards/osd/board-info.mk
make/boot-defs.mk
make/common-defs.mk
