| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
| |
Unused.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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>
|
| |
|
|
|
|
|
|
| |
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>
|
|
|
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.
|
