feurig/libmaplemidi-cma/support/make, branch master

create board files for maple_midi

2013-04-25T23:52:44+00:00

Add fix to support Summon/Linaro GCC ARM embedded toolchain.

2013-01-05T19:25:14+00:00

Signed-off-by: Dmitry Prokhorov

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

Add support for ARM's GCC ARM embedded toolchain.

2012-08-05T17:27:13+00:00

Based on patches provided by Hanspeter Portner: http://forums.leaflabs.com/topic.php?id=1717#post-11812 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

Tweak build system to allow out-of-tree projects.

2012-06-15T03:43:48+00:00

It's very annoying to have to build libmaple projects in-tree. Users are just copying the repository everywhere. That's stupid. So I made this: https://github.com/mbolivar/example-libmaple-project It needs these patches to work. Add a header and footer for rules.mk files, so we can change them around and things will continue to work for the users, who just include them. In Makefile, add USER_MODULES to LIBMAPLE_MODULES if it's nonempty. This is the hook you use to get your code compiled and linked correctly. Hack build-targets.mk for stupid reasons I hope to fix later. For now, you'll need an empty main.cpp in BOTH the libmaple directory and your directory if you want things to work the way you'd expect. 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

Move OpenOCD stuff into contrib/.

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

This has gone unmaintained for long enough. 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