| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
The disc pin code was copy-pasted when the CDC ACM pieces were
extracted from the rest of the USB code, and I didn't really
understand what was going on when I moved it over. Having checked the
spec, the comments can be safely improved.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
|
|
|
|
|
|
| |
- Shut Doxygen up in various places
- Fix some genuine docs bugs
- Ignore sources we're not responsible for
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
The good news is that <libmaple/usb.h> and <libmaple/usb_cdcacm.h> did
turn out generic enough in what they specify to go on unchanged.
However, we can't just go on assuming that there's USB just because
we're on an F1. Now that there's value line in the tree, we need to be
more careful (value line F1s don't have USB peripherals). To that end,
make all the F1 board-includes/*.mk files specify what line their MCU
is with an MCU_F1_LINE variable. Use that to hack
libmaple/usb/rules.mk so we only try to build the USB module under
appropriate circumstances.
While we're at it, add a vector_symbols.inc for value line MCUs under
support/ld/. We need this to get the target-config.mk modifications
implied by the addition of MCU_F1_LINE. We'll fix up some other
performance-line-isms under libmaple/stm32f1 in a separate commit.
Also in libmaple/usb/:
- Move everything into a new stm32f1 directory. Due to aforementioned
rules.mk hacks, there is no immediate need for an stm32f2
directory (USB support doesn't exist there).
- Update the README for style and content.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
