aboutsummaryrefslogtreecommitdiffstats
path: root/support/ld/stm32/series
Commit message (Collapse)AuthorAgeFilesLines
* Rename various "stm32f2" directories "stm32f2-f4".Marti Bolivar2014-11-241-0/+0
| | | | | | Preparatory patch for adding STM32F4 support. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Slightly improve and generify the USB infrastructure.Marti Bolivar2012-06-031-0/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* support/ld: Add STM32F2 vector symbols.Marti Bolivar2012-04-111-0/+98
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Add build support for targeting multiple STM32 series.Marti Bolivar2012-04-111-0/+0
| | | | | | | | | | | | | | | | | | | Add an MCU_SERIES variable to each of the files under support/make/board-includes, which declares the series as "stm32f1" in each case. Use this in target-config.mk when determining LD_SERIES_PATH (with a hack since we only support performance line) and LIBMAPLE_MODULE_SERIES. We must move support/ld/stm32/series/f1 to .../series/stm32f1 as a side-effect. Adding support for other series (e.g. "stm32f2") should now be a matter of filling in the contents of libmaple/<series>/ and support/ld/stm32/<series>/ appropriately (along with moving the rest of the nonportable code out of the libmaple core and into the STM32F1 series submodule). Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Great renaming: use "series" instead of "family".Marti Bolivar2012-04-111-0/+78
This is for greater consistency with the ST application notes, which refer to migrating "across" series (e.g. F1 to F2), but compatibility "within" a family (e.g. F1). So: - Move libmaple/stm32x/include/family to .../include/series/ and fix up includes appropriately. - Refer to "family" headers as "series" headers in comments. - Make similar "find and replace"-style changes to build system variable names and comments. - Move support/ld/stm32/family to .../stm32/series. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>