aboutsummaryrefslogtreecommitdiffstats
path: root/support/ld/stm32/series/stm32f2
diff options
context:
space:
mode:
authorMarti Bolivar <mbolivar@leaflabs.com>2012-06-03 06:00:41 -0400
committerMarti Bolivar <mbolivar@leaflabs.com>2012-06-03 22:40:39 -0400
commit378c3a70f81ddfbbddf3656977f81b7dfd8f96cd (patch)
tree0d2853cf5d739cdba5a596387e8709eb1969e185 /support/ld/stm32/series/stm32f2
parentb522a442b805507e7a8fc93ba8011068b8b57d96 (diff)
downloadlibrambutan-378c3a70f81ddfbbddf3656977f81b7dfd8f96cd.tar.gz
librambutan-378c3a70f81ddfbbddf3656977f81b7dfd8f96cd.zip
Slightly improve and generify the USB infrastructure.
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>
Diffstat (limited to 'support/ld/stm32/series/stm32f2')
0 files changed, 0 insertions, 0 deletions