coordinate system
Previously there were hacks spread throughout to deal with various ways of
positioning the chips. Now the driver structure specifies the rotation
of the chip relative to the board layout and the output X/Y/Z are already
in OP convention.
This flag seems to do the right thing for Revolution, CC3D, and RevoMini
Adds a new RCTransmitter setting for the USB HID interface which
emulates a USB HID joystick. The scaled RC receiver channels
from any RCVR protocol are passed through to the various emulated
joystick controls.
The main use for this feature is to allow you to use your own RC
transmitter with any RC simulator on a PC.
This is known to work with CRRCsim but should work with any simulator
that supports joystick input.
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.
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.
for sensing and then load different config for CC and CC3D. Updated the
bootloader as well. Also changed the PIOS_USB_CheckAvailability function to
only return the sense signal and not the transfer_possible flag as this is not
set in time for the bootloader on CC3D for some reason.
Board specific HW configuration is now collected in a single .c
file for each board. This HW configuration is #include'd into
the FW, BL and BU builds for each board.
These new .c files are found in:
flight/board_hw_defs/<board_name>/board_hw_defs.c
Parts of this information were previously duplicated between
the BL and FW builds. This commit cleans up the duplication.
Using a #include on a .c file is a bit ugly but it allows us
to ensure that all of the symbols in the board_hw_defs.c file
are *ONLY* used in the PIOS_Board_Init() function for each
software build.
Summary of changes:
* USB CDC and HID drivers are completely split apart.
* This will allow different max buffer sizes for HID and CDC.
* USB descriptors have been overhauled:
* Proper structs/macros/enums declared for USB (see pios_usb_defs.h)
* Two common descriptor definitions. One for HID+CDC another for HID only.
See pios_usb_desc_{hid_cdc,hid_only}.c for details.
* Long standing bugs in OP USB descriptors became much more obvious with the
new struct definitions.
* Board specific USB initialization is now in pios_usb_board_data.h in each build target.
* Definition of USB descriptors is now entirely indpendent of STM32 libs.
Glue into STM32 libs is provided by pios_usbhook.c.
* Removed a lot of stale/irrelevant USB #defines throughout the tree.
* Improved naming consistency throughout USB code:
* PIOS_USB_HID_* now refers to the HID endpoint code.
* PIOS_USB_CDC_* now refers to the CDC endpoint code.
* PIOS_USB_* now refers to the low-level USB code.
* PIOS_USB_BOARD_* now refers to board-specific USB data
* PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs.
* struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec.
* Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM.
* Made a few more USB related variables static to save some RAM.
This detects a locked out state and fails the init. The new
bootfault detection code will automatically drop to default
hwsettings after 3 consecutive boot failures. That will put
the board back into an unlocked state where the user can now
enable a telemetry link using the GCS and everything will be
OK.
NOTE: Any configured telemetry link will be considered enough
to boot up. If you only configure a serial telemetry
link but don't know how to hook anything up to it, this
will not save you.
As the ultimate recovery, you can always load firmware on the
board that wipes the settings entirely and start over.
After 3 failed warm start attempts, the init sequence
will force the RAM version of the HWSettings object
to its defaults. This should allow a user to regain
connectivity to a board that is continually faulting
during init.
This is accomplished by:
- Incrementing a boot counter that is stored in the
STM32 BKP registers. These registers survive a
warm start but are cleared on a cold start (ie. powerup).
- On multiple failures, force hwsettings to defaults
and raise the (new) BootFault alarm to prevent arming.
- Resetting the boot counter whenever the system manages
to successfully run the System Module task.
NOTE: This does not actually change the hwsettings object in
flash. That's up to the user.
This is intended to catch ONLY faults during early initialization.
It should not be used to recover from faults after the application
is up and running.
The GCS hwsettings config widget now disallows any
configuration that disables both HID and VCP telemetry
over the USB port.
The firmware will allow it if the UAVObj is set manually.
This allows a mechanism to reduce RAM usage by another
500 more bytes if USB telemetry can be sacrificed in
certain configurations.
This allows the HID and VCP functions to be configured
separately so that additional functions can be more easily
bound to the VCP port.
This change also provides a safety net that forces either
the HID or VCP to be configured for USB Telemetry. This
safety net may vanish in the future once the GCS can check
it. Disabling USB Telemetry entirely would save more than
400 bytes of RAM.
