mirror of
https://github.com/pascallanger/DIY-Multiprotocol-TX-Module.git
synced 2025-11-04 15:01:08 +00:00
64 lines
2.7 KiB
Plaintext
64 lines
2.7 KiB
Plaintext
|
The USB submodule of libmaple is a separate piece of the codebase for
|
||
|
|
reasons that are largely historical.
|
||
|
|
|
||
|
|
Current Status:
|
||
|
|
|
||
|
|
There's only support for the USB device peripheral found on
|
||
|
|
STM32F103s.
|
||
|
|
|
||
|
|
We rely on the low level core library provided by ST to implement
|
||
|
|
the USB transfer protocol for control endpoint transfers.
|
||
|
|
|
||
|
|
The virtual com port (which is exposed via
|
||
|
|
<libmaple/usb_cdcacm.h>) serves two important purposes.
|
||
|
|
|
||
|
|
1) It allows serial data transfers between user sketches an a
|
||
|
|
host computer.
|
||
|
|
|
||
|
|
2) It allows the host PC to issue a system reset into the DFU
|
||
|
|
bootloader with the DTR + RTS + "1EAF" sequence (see
|
||
|
|
leaflabs.com/docs/bootloader.html for more information on
|
||
|
|
this).
|
||
|
|
|
||
|
|
After reset, Maple will run the DFU bootloader for a few seconds,
|
||
|
|
during which the user can begin a DFU upload operation (uploads
|
||
|
|
application binary into RAM/FLASH). Thus, without this virtual com
|
||
|
|
port, it would be necessary to find an alternative means to reset
|
||
|
|
the chip in order to enable the bootloader.
|
||
|
|
|
||
|
|
If you would like to develop your own USB application for whatever
|
||
|
|
reason (e.g. to use faster isochronous enpoints for streaming
|
||
|
|
audio, or implement the USB HID or Mass Storage specs), then
|
||
|
|
ensure that you leave some hook for resetting Maple remotely in
|
||
|
|
order to spin up the DFU bootloader. Please make sure to get
|
||
|
|
yourself a unique vendor/product ID pair for your application, as
|
||
|
|
some operating systems will assign a host-side driver based on
|
||
|
|
these tags.
|
||
|
|
|
||
|
|
It would be possible to build a compound USB device, that
|
||
|
|
implements endpoints for both the virtual COM port as well as some
|
||
|
|
other components (mass storage etc.). However, this turns out to
|
||
|
|
be a burden from the host driver side, as Windows and *nix handle
|
||
|
|
compound USB devices quite differently.
|
||
|
|
|
||
|
|
Be mindful that enabling the USB peripheral isn't "free." The
|
||
|
|
device must respond to periodic bus activity (every few
|
||
|
|
milliseconds) by servicing an ISR. Therefore, the USB application
|
||
|
|
should be disabled inside of timing critical applications.
|
||
|
|
|
||
|
|
In order to disconnect the device from the host, a USB_DISC pin is
|
||
|
|
asserted (e.g. on Maple, this is PC12). Alternatively, the NVIC
|
||
|
|
can be directly configured to disable the USB LP/HP IRQ's.
|
||
|
|
|
||
|
|
The files inside of usb_lib were provided by ST and are subject to
|
||
|
|
their own license, all other files were written by the LeafLabs
|
||
|
|
team and fall under the MIT license.
|
||
|
|
|
||
|
|
TODO:
|
||
|
|
|
||
|
|
- Generic USB driver core with series-provided backends, like
|
||
|
|
libopencm3 has.
|
||
|
|
- Strip out ST code.
|
||
|
|
- Integration with a high level USB library (like LUFA/MyUSB) to
|
||
|
|
allow users to write custom USB applications.
|