aboutsummaryrefslogtreecommitdiffstats
path: root/libmaple/usb/stm32f1/usb.c
Commit message (Collapse)AuthorAgeFilesLines
* libmaple/usb/stm32f1/usb.c: fix build error.Marti Bolivar2013-04-291-1/+1
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Preserve previous usb state when suspending / restore on resumeManuel Odendahl2013-04-261-7/+13
| | | | Signed-off-by: Manuel Odendahl <wesen@ruinwesen.com>
* Doxygen hacks and fixups.Marti Bolivar2012-06-281-1/+1
| | | | | | | | - 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>
* Slightly improve and generify the USB infrastructure.Marti Bolivar2012-06-031-0/+381
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>