aboutsummaryrefslogtreecommitdiffstats
path: root/libmaple/stm32f1
Commit message (Collapse)AuthorAgeFilesLines
...
* Move Flash support for STM32F1 to libmaple/stm32f1/.Marti Bolivar2012-04-113-0/+178
| | | | | | | | | | | | | | | This is a backwards-compatible change. The Flash registers on the STM32F2 line are different than on STM32F1. Therefore, move the register map and bit definitions to new libmaple/stm32f1/include/family/flash.h. Move flash_enable_prefetch() from libmaple/flash.c to new libmaple/stm32f1/flash.c. The remaining pieces of libmaple/flash.c use a common subset of the Flash registers, so they're's portable to F2, and that's all we're currently interested in. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Move RCC support for STM32F1 to libmaple/stm32f1/.Marti Bolivar2012-04-113-1/+766
| | | | | | | | | | | | This is a backwards-compatible change. Modify libmaple/rules.mk to include the family's include directory. This allows libmaple/include/libmaple/rcc.h to include the STM32F1 RCC header with #include <family/rcc.h>. We'll use this convention henceforth to distinguish between top-level and family-specific headers. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Remove "CS3" prefix from libmaple symbol names.Marti Bolivar2012-04-111-6/+6
| | | | | | | | | | | | | | | | | | | We're no longer even marginally compatible with CS3, so it's inappropriate to use that prefix in our names. Rename: __cs3_stm32_vector_table -> __stm32_vector_table. __cs3_stack -> __msp_init __cs3_reset -> __exc_reset __cs3_start_c -> start_c Also add an MIT license header and assert LeafLabs copyright over wirish/start.S and wirish/start_c.c. These files are modified from the original CodeSourcery versions, which were distributed under a license that permits modifications to be distributed under a different copyright and licensing terms than the originals. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Remove CS3-style initialization.Marti Bolivar2012-04-113-0/+348
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>