suspect-devices/libmaple/support/make/target-config.mk, branch master

Makefile: Don't assume Cortex M3.

2012-08-05T18:40:03+00:00

Instead, derive -march and -mcpu from the target MCU in target-config.mk. Also (on STM32F4) add the necessary floating point flags. The CodeSourcery toolchains don't support these, so we'll need to prepare alternative toolchains when F4 support is official. Signed-off-by: Marti Bolivar

Fix botched TARGET_LDFLAGS.

2012-06-27T03:16:45+00:00

Works with officially supported CodeSourcery toolchain. May need tweaks for users with a more modern arm-none-eabi-g++. Signed-off-by: Marti Bolivar

Merge branch 'wip-family-support'

2012-06-26T22:32:57+00:00

Merge the long-lived (too long; future changes like these will need to proceed more incrementally) development branch of libmaple, containing experimental STM32F2 and STM32F1 value line support, into master. This required many changes to the structure of the library. The most important structural reorganizations occurred in: - 954f9e5: moves public headers to include directories - 3efa313: uses "series" instead of "family" - c0d60e3: adds board files to the build system, to make it easier to add new boards - 096d86c: adds build logic for targeting different STM32 series (e.g. STM32F1, STM32F2) This last commit in particular (096d86c) is the basis for the repartitioning of libmaple into portable sections, which work on all supported MCUs, and nonportable sections, which are segregated into separate directories and contain all series-specific code. Moving existing STM32F1-only code into libmaple/stm32f1 and wirish/stm32f1, along with adding equivalents under .../stm32f2 directories, was the principal project of this branch. Important API changes occur in several places. Existing code is still expected to work on STM32F1 targets, but there have been many deprecations. A detailed changelog explaining the situation needs to be prepared. F2 and F1 value line support is not complete; the merge is proceeding prematurely in this respect. We've been getting more libmaple patches from the community lately, and I'm worried that the merge conflicts with the old tree structure will become painful to manage. Conflicts: Makefile Resolved Makefile conflicts manually; this required propagating -Xlinker usage into support/make/target-config.mk. Signed-off-by: Marti Bolivar

Rework linker scripts.

2012-06-07T07:44:31+00:00

Having separate linker scripts for all the boards is a bad idea. Most boards really only need to specify MEMORY and the appropriate REGION_ALIASES() so that support/ld/common.inc can do its work. Not having infrastructure for this leads to duplication -- viz. the Maple Mini linker scripts are identical to the Maple's, and the olimex_stm32_h103 linker directory is just a symlink to Maple's. Clearly, the current structure is wrong. To fix it, instead of having per-board subdirectories of support/ld/, add per-MEMORY subdirectories of (new) support/ld/stm32/mem/. The per-board .mk files under support/mk/board-includes/ now reference these directly, and target-config.mk and the Makefile handle this appropriately. We move some other stuff around in target-config.mk to make this all more convenient, and even allow more overriding of the libmaple defaults on a per-board basis. Custom board hacks will be easier now. Unfortunately, lots of duplication under support/ld/stm32/mem/ is necessary, as the LENGTH attribute in a MEMORY region specification doesn't support arithmetic expressions, and ld doesn't seem to have any way to specify MEMORY at the command line (why?!). If we find a better way than this, we should do it. If a board (e.g. Maple Native) _does_ really need special memory-related configuration, you can always put a per-board subdirectory of support/ld/stm32/mem. We do this here to configure the heap. Signed-off-by: Marti Bolivar

Makefile: add list-boards target.

2012-06-07T07:40:08+00:00

As the number of boards increases, it's less practical to keep a list of them in the help target output (notice also that some have been forgotten). This target can't get out of date unless we change how the board-includes/ directory works. Signed-off-by: Marti Bolivar

Slightly improve and generify the USB infrastructure.

2012-06-04T02:40:39+00:00

The good news is that and 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

Add build support for targeting multiple STM32 series.

2012-04-11T20:56:52+00:00

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// and support/ld/stm32// 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

build system: Add board include files for target-config.mk.

2012-04-11T20:56:52+00:00

target-config.mk is getting a little long with all the boards in it. Break out the board-specific bits into individual files under support/make/board-includes. This has the added benefit that adding a new board requires less dirtying of the working tree, which is nice for jumping around branches with an experimental board. Signed-off-by: Marti Bolivar

Great renaming: use "series" instead of "family".

2012-04-11T20:56:52+00:00

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

Rename GLOBAL_FLAGS to TARGET_FLAGS, remove from Makefile.

2012-04-11T20:56:52+00:00

Move into target-config.mk. Build it up bit-by-bit as the build goes on. Repeat the DENSITY defines once per board in target-config.mk, since they don't make sense on STM32F2. Signed-off-by: Marti Bolivar