aboutsummaryrefslogtreecommitdiffstats
path: root/support/make
Commit message (Collapse)AuthorAgeFilesLines
* stm32f4: 32bit-float-friendly GCC flagsbnewbold2015-03-031-1/+2
| | | | | | | | | | | | | | This commit makes 'float' (32-bit) the default for floating point constants in the source code, instead of the defaults 'double' (64-bit). Floating point performance is very sensitive to the float vs. double distinction on 32-bit processors, especially Cortex-M4s with a VFP unit for floats but not doubles. In the future it may be wise to make this change for non-hard-fp chips (aka, all the other STM32s) as well, for behavioral consistancy. The warning flag ensures that the frequently used parts of the code base will be less ambiguous, but doesn't cover series-specific code.
* stm32f4: series-specific linker flagsbnewbold2015-03-031-1/+3
| | | | Also refactors STM32F2-F4 linker files into sub-series directories.
* board support: stm32f401c_discovery -> st_stm32f401cdiscoverybryan newbold2015-03-011-0/+0
|
* stm32f401c_discovery.mk: fix typo and use short MCU name conventionbryan newbold2015-03-011-1/+1
|
* stm32f4: add support for stm32f401CDiscovery boardPerry Hung2015-03-011-0/+7
| | | | Add support for stm32f401CDiscovery board running an STM32F401VGT6
* board support: opencm904 -> robotis_opencm904bnewbold2015-02-281-0/+0
|
* board support: cm900 -> robotis_cm900bnewbold2015-02-281-0/+0
|
* board support: nucleo -> st_nucleo_f103rbbnewbold2015-02-281-0/+0
| | | | Also correct attribution in Wirish board.h
* board support: rename VLDiscovery -> st_stm32vldiscoverybnewbold2015-02-281-0/+0
|
* Adding support for NUCLEO-F103RBGrégoire Passault2015-02-281-0/+10
| | | | Signed-off-by: Grégoire Passault <g.passault@gmail.com>
* Rename various "stm32f2" directories "stm32f2-f4".Marti Bolivar2014-11-241-7/+15
| | | | | | Preparatory patch for adding STM32F4 support. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Adding BOOTLOADER option to support Robotis bootloader different ROMGregwar2014-04-232-0/+10
| | | | Signed-off-by: Grégoire Passault <g.passault@gmail.com>
* Adding support for cm900 and opencm904 boards (robotis)Gregwar2014-02-202-0/+20
| | | | Signed-off-by: Grégoire Passault <g.passault@gmail.com>
* build-rules.mk: allow user to override dfu-util path.Marti Bolivar2013-07-191-1/+1
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* build-rules.mk: Add CROSS_COMPILE env var supportDaniel Nyström2013-06-041-9/+11
| | | | | | | | | Since toolchains other then older Code Sourcery (Mentor Graphics) might not use the arm-none-eabi triplet, make it possible to use any triplet by just setting the CROSS_COMPILE environment variable accordingly. Signed-off-by: Daniel Nyström <daniel@nystrom.st>
* Add fix to support Summon/Linaro GCC ARM embedded toolchain.Dmitry Prokhorov2013-01-051-0/+4
| | | | Signed-off-by: Dmitry Prokhorov <dipspb@gmail.com>
* Makefile: Don't assume Cortex M3.Marti Bolivar2012-08-051-1/+11
| | | | | | | | | 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 <mbolivar@leaflabs.com>
* Add support for ARM's GCC ARM embedded toolchain.Marti Bolivar2012-08-051-0/+13
| | | | | | | Based on patches provided by Hanspeter Portner: http://forums.leaflabs.com/topic.php?id=1717#post-11812 Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Fix botched TARGET_LDFLAGS.Marti Bolivar2012-06-261-3/+3
| | | | | | | Works with officially supported CodeSourcery toolchain. May need tweaks for users with a more modern arm-none-eabi-g++. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Merge branch 'wip-family-support'Marti Bolivar2012-06-2610-66/+83
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <mbolivar@leaflabs.com>
| * Rework linker scripts.Marti Bolivar2012-06-078-24/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <mbolivar@leaflabs.com>
| * Move OpenOCD stuff into contrib/.Marti Bolivar2012-06-071-1/+0
| | | | | | | | | | | | This has gone unmaintained for long enough. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
| * Makefile: add list-boards target.Marti Bolivar2012-06-071-1/+1
| | | | | | | | | | | | | | | | | | 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 <mbolivar@leaflabs.com>
| * Slightly improve and generify the USB infrastructure.Marti Bolivar2012-06-037-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * STM32VLDiscovery support filesAnton Eltchaninov2012-05-031-0/+5
| | | | | | | | | | Signed-off-by: Anton Eltchaninov <anton.eltchaninov@gmail.com> Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
| * stm32.h: Various updates, mostly to help STM32F1 line support.Marti Bolivar2012-04-245-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add STM32_HAVE_USB feature test macro requirement for <series/stm32.h>. This will let us test if we've got a USB peripheral. wirish/stm32f1/boards_setup.cpp is set up to use this when turning on USB CDC ACM support at init() time. Rework the STM32F1 <series/stm32.h> to make it easier to support the various lines that subdivide that series. We don't really support anything besides performance line yet, but there's been enough enthusiasm for value and connectivity line support in the past that these hooks seem worth adding. This means adding an STM32_F1_LINE macro and STM32_F1_LINE_[PERFORMANCE,VALUE,ACCESS,CONNECTIVITY] macros for values that STM32_F1_LINE can take, and generalizing the rest of the file to begin taking this into account. Some TODOs remain, but filling these in is the responsibility of future libmaple porting efforts. One pleasant consequence of the F1 stm32.h rework is that the build system no longer has to tell us what density of F103 we're building for, so remove that from the relevant support/make/board-includes/ files. Add some tweaks to <libmaple/stm32.h> and the STM32F2 stm32.h header to make sure this went through properly, and continues to go through properly in the future.
| * ld/make: Add support for STM3220G-EVAL board.Marti Bolivar2012-04-111-0/+4
| | | | | | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
| * Add build support for targeting multiple STM32 series.Marti Bolivar2012-04-116-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * build system: Add board include files for target-config.mk.Marti Bolivar2012-04-116-45/+33
| | | | | | | | | | | | | | | | | | | | | | | | 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 <mbolivar@leaflabs.com>
| * Great renaming: use "series" instead of "family".Marti Bolivar2012-04-111-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Rename GLOBAL_FLAGS to TARGET_FLAGS, remove from Makefile.Marti Bolivar2012-04-111-0/+15
| | | | | | | | | | | | | | | | 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 <mbolivar@leaflabs.com>
| * Revert "Added libs in libraries/ to the include path"Marti Bolivar2012-04-111-1/+0
| | | | | | | | | | | | | | | | This reverts commit 628750bf82135cc1ca25784c8b39eb771ae87024. Don't mess with LIBMAPLE_INCLUDES. This variable comprises include directories for libmaple proper, not for libraries that depend upon libmaple.
| * target-config.mk: Remove FLASH_SIZE, SRAM_SIZE settings.Marti Bolivar2012-04-111-10/+0
| | | | | | | | | | | | Unused. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
| * Tweak family-specific linker file layout.Marti Bolivar2012-04-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Move support/ld/stm32/f1/performance/vector_symbols.inc to support/ld/stm32/family/f1/performance/vector_symbols.inc Creating directory "family" under support/ld/stm32 will allow parallel directories (e.g. support/ld/stm32/mcu) to exist, which allows an eventual linker script cleanup to go much more smoothly. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* | Tweak build system to allow out-of-tree projects.Marti Bolivar2012-06-142-0/+22
|/ | | | | | | | | | | | | | | | | | | | | | | 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 <mbolivar@leaflabs.com>
* Remove CS3-style initialization.Marti Bolivar2012-04-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove libcs3-related bits from support/ld. Break them out into libmaple proper and Wirish as appropriate: vector table definition and ISR declarations go into libmaple proper, and startup code goes into Wirish. Vector table symbols are included into common.inc from an STM32 family-specific directory under support/ld/stm32. This is a combination of 5 commits. Individual commit messages follow: libcs3_stm32_src: Don't depend on cs3.h. So we can use the existing toolchain. Move ISR decls/vector table into libmaple proper. This allows us to configure the vector table on a per-family basis. - Move support/ld/libcs3_stm32_src/stm32_isrs.S stm32_vector_table.S to libmaple/stm32f1/isrs_performance.S vector_table_performance.S, respectively. The directory libmaple/stm32f1/ is intended to hold all STM32F1-specific code within libmaple. Obviously, there's a lot of work to do before this becomes true. - support/ld/libcs3_stm32_src/Makefile: Don't try to compile stm32_isrs.S and stm32_vector_table.S anymore. - Add libmaple/stm32f1/rules.mk to include these new files in the standard libmaple build. - support/make/target-config.mk: Add LIBMAPLE_MODULE_FAMILY, which selects a directory to use as a family-specific libmaple submodule. - Makefile: Add LIBMAPLE_MODULE_FAMILY to LIBMAPLE_MODULES. Remove support/ld/libcs3_stm32_src and derived object files. From support/ld/libcs3_stm32_src, move start.S and start_c.c into Wirish. Modify wirish/rules.mk accordingly. Delete support/ld/libcs3_stm32_*_density.a. These are no longer necessary, as the relevant objects are included in the standard Wirish build. Remove the GROUP statements from the board linker scripts accordingly. Remove SEARCH_DIR(.) from common.inc; it's no longer necessary. Also fix up some comments that are now out of date. wirish/start_c.c: Don't use CS3-style memory initialization. Switch memory initialization to a simpler style of initializing .data if necessary, then zeroing .bss. Initializing .data is only necessary during Flash builds, since during RAM builds, LOADADDR(.data) == ADDR(.data). This makes libmaple completely incompatible with the CS3 startup sequence. Subsequent commits will clean up the namespace to reflect that fact. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Make vector table symbols family-specific during linking.Marti Bolivar2011-11-151-0/+8
| | | | | | | | | | | | | | | | | - support/make/target-config.mk: add LD_FAMILY_PATH, the directory to search for STM32 family-specific link configuration files. For now, this is just a stub which points to support/ld/stm32/f1/performance, since that's all we currently support. We can add the logic to support different STM32 families here later. - Makefile: Pass -L $(LD_FAMILY_PATH) to linker. - Rename support/ld/names.inc to support/ld/stm32/f1/performance/vector_symbols.inc. - common.inc: INCLUDE vector_symbols.inc instead of names.inc. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Add support for the Olimex STM32 H103 board.David Kiliani2011-09-271-0/+10
| | | | | | | | Pin layout and header files for the STM32 H103 prototype board from Olimex featuring an STM32F103RBT6 chip. This commit contains all necessary changes to compile with BOARD=olimex_stm32_h103. Signed-off-by: David Kiliani <mail@davidkiliani.de>
* [make] Factor out target/board configuration.Marti Bolivar2011-09-131-0/+56
| | | | | | | | | Comment the Makefile more verbosely. It's been causing confusion on the forums. Add target-config.mk, this contains build configuration depending on the BOARD and MEMORY_TARGET variables. Its contents were cluttering up the Makefile and making it harder to read.
* Added libs in libraries/ to the include pathCamille Moncelier2011-06-021-0/+1
| | | | | | | | - This allows to including of libs headers eg: #include <Servo.h> which wasn't possible for some reason.
* openocd: Detect openocd versionPerry Hung2011-05-261-1/+1
| | | | | Small script to detect the openocd version and choose the appropriate debug/flash script for use with JTAG debugging.
* Enable USB auto-reset in a hard fault.Perry Hung2010-09-171-2/+5
| | | | | | | | Redirect thread-mode execution to a fail routine which throbs the LED to indicate a hard fault. Because the fail routine runs in thread mode with interrupts on, USB auto-reset should now work. Test by executing some bogus instruction (e.g. *(volatile int*)0xf34fdaa = 0;) and check that the auto-reset continues to work.
* exposed build-targets.mkMarti Bolivar2010-09-131-35/+0
|
* Various fixes, working with Maplebnewbold2010-09-011-3/+4
|\
| * Portability fixesbnewbold2010-08-311-2/+3
| | | | | | | | Still not working but fixed a lot of merge errors
| * MEMORY_TARGET not MAPLE_TARGETbnewbold2010-08-251-2/+2
| |
* | fix reset.py to work on OS X,; .gitignore leaves out ~ files; cleanupMarti Bolivar2010-08-291-3/+0
|/ | | | support/make/build-rules.mk
* makefile: fix install targetPerry Hung2010-07-081-2/+3
| | | | | The makefile 'install' target should upload to whatever the last build target was, regardless of the environment's value of MAPLE_TARGET.
* more codeblocks fixes; verbose build outputbnewbold2010-07-081-2/+5
|
* make: Modularize makefiles, add dependency tracking, build-type trackingPerry Hung2010-06-253-0/+76
Major build system rewrite. New and exciting: 1. Proper dependency tracking. All source files including header files should be properly tracked and recompiled as necessary when they are changed. 2. Build-type tracking. If the target changes from 'ram' to 'flash,' for example, the build system will force a rebuild rather than incorrectly link modules to a different address. 3. New targets: The old 'ram,' 'flash,' and 'jtag' targets have been replaced with the environment variable MAPLE_TARGET, which controls the link address. Users can either export it to their environment, or pass MAPLE_TARGET on the command-line. Once this is set, sketches can be compiled with 'make sketch,' or simply 'make.' Note: the default is MAPLE_TARGET='flash.' The target 'install' now automagically uploads the sketch to the board using the appropriate method. The 'run' target has been renamed to 'debug.' It starts an openocd gdb server. 4. Odds and ends: -Verbose and 'quiet' modes. Set V=1 for verbose compilation, the default is quiet. -Object file sizes and disassembly information is generated and placed in build/$(BOARD).sizes and build/$(BOARD).disas, respectively. -Parallel make with -j should speed things up if you have multiple cores.
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-22 12:51:52 +0000