aboutsummaryrefslogtreecommitdiffstats
path: root/support
Commit message (Collapse)AuthorAgeFilesLines
* Rework linker scripts.Marti Bolivar2012-06-0743-368/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-076-351/+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-038-3/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Doxyfile: Add to PREDEFINED to cover libmaple_types.h.Marti Bolivar2012-05-311-0/+4
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Doxygen: add the Evil Mangler.Marti Bolivar2012-05-102-1/+41
| | | | | | | | | | | | | | | | | Whenever Doxygen is running on a series header, make it run an awk script, the Evil Mangler, that pretends the file is enclosed in an appropriate namespace declaration for the series target. Doxygen chokes if two structs have the same name. This is a problem for the series headers, which commonly have data structures with the same name. However, if those structs are in different namespaces, Doxygen has no problems. We obviously can't use namespaces in C headers, so use FILTER_PATTERNS to trick Doxygen into thinking they're there. Ugly, but I can't think of a better way to handle this. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Doxyfile: Disable TYPEDEF_HIDES_STRUCT to work around Breathe issues.Marti Bolivar2012-05-101-1/+1
| | | | | | | This works around a problem we're having getting the XML for the series headers into a form that we can work with in leaflabs-docs. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Change __DOXYGEN_PREDEFINED_HACK to __DOXYGEN__.Marti Bolivar2012-05-091-1/+1
| | | | | | avr-gcc does it this way. Seems ok to me. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Shut up, doxygen.Marti Bolivar2012-05-091-2/+2
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* STM32VLDiscovery support filesAnton Eltchaninov2012-05-034-0/+75
| | | | | Signed-off-by: Anton Eltchaninov <anton.eltchaninov@gmail.com> Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Doxyfile: Allow group documentation.Marti Bolivar2012-05-031-1/+1
| | | | | | | This change allows us to document several members of a group with one Doxygen comment. It's not clear how well this will work out in practice. 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-112-0/+21
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* support/ld: Add STM32F2 vector symbols.Marti Bolivar2012-04-111-0/+98
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Add build support for targeting multiple STM32 series.Marti Bolivar2012-04-117-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-112-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-112-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>
* Fix linking and C runtime initialization on F1.Marti Bolivar2012-04-111-30/+23
| | | | | | | | | | | | Reorder the .data and .rodata sections in common.inc. This seems necessary to get the linker to place the data ROM disk and the pointer to it in the right places. Switch from long long to int in start_c.c. I have no idea why this helps, but it does. F1 will crash if you don't do this. It will probably slow things down unnecessarily on F2, but I don't care. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Remove "CS3" prefix from libmaple symbol names.Marti Bolivar2012-04-112-9/+9
| | | | | | | | | | | | | | | | | | | 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-1121-529/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* copy-to-ide: Remove references to libcs3_stm32_*_density.a.Marti Bolivar2012-04-111-2/+0
| | | | | | These no longer exist. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Make vector table symbols family-specific during linking.Marti Bolivar2011-11-153-4/+15
| | | | | | | | | | | | | | | | | - 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>
* reset.py: Hackishly silence DeprecationWarning.Marti Bolivar2011-10-071-2/+1
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Add support for the Olimex STM32 H103 board.David Kiliani2011-09-272-0/+11
| | | | | | | | 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>
* Add Windows support to DFU installation tools.Marti Bolivar2011-09-261-53/+84
| | | | | | | Tweak Makefile further for cs-make on Windows. Add Windows support to support/scripts/reset.py Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Update support/scripts/copy-to-ide.Marti Bolivar2011-09-131-2/+1
| | | | Oh, copy-to-ide. I long for your death.
* [support/ld] Unify linker scripts.Marti Bolivar2011-09-1315-248/+89
| | | | | | | | | | | | | | | | Add new common.inc, which is common_rom.inc with some DEFINED(_FLASH_BUILD) usages thrown in to allow for RAM builds. It also uses a new REGION_RODATA region alias for read-only data. Move section .USER_FLASH to REGION_RODATA. This means it lives in RAM under RAM builds. Although this might be surprising, not doing so would make RAM builds useless. Modify the individual board linker scripts to properly set REGION_RODATA and _FLASH_BUILD before calling out to common.inc. Delete common_rom.inc, common_ram.inc, common_header.inc, in favor of common.inc. This should fix RAM builds on all boards.
* [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.
* [support/ld] Put Maple Native's heap on external SRAM chip.Marti Bolivar2011-09-123-0/+12
| | | | | | Specify _lm_heap_start and _lm_heap_end in Maple Native's linker scripts to point respectively to beginning and end of FSMC-mapped external SRAM chip addresses.
* [support/ld] Add linker support for reconfigurable heap.Marti Bolivar2011-09-122-2/+16
| | | | | | | | | | | | | | | - common_header.inc: Declare EXTERN symbols _lm_heap_start and _lm_heap_end. - common_rom.inc: Check for _lm_heap_start and _lm_heap_end. If they are defined, preserve their values. Otherwise, _lm_heap_start is starts after .bss, and _lm_heap_end is the end of SRAM. This allows existing linker scripts to continue using the old heap scheme, but allows for customizability elsewhere. - syscalls.c: Respect the addresses of _lm_heap_start and _lm_heap_end as the boundaries of the heap in _sbrk().
* common_rom.inc: More comments.Marti Bolivar2011-09-121-8/+20
| | | | Explain what's going on so unfamiliar readers have more hope.
* common_rom.inc: Eliminate apparently useless sections.Marti Bolivar2011-09-091-8/+0
|
* [support/ld] Rename vector table section.Marti Bolivar2011-09-094-5/+2
|
* Linker scripts: Remove useless junk.Marti Bolivar2011-09-092-16/+1
|
* Linker scripts: Rename section targets.Marti Bolivar2011-09-092-14/+5
| | | | | | Use region aliases in common_ram.inc, common_rom.inc. These are provided by the individual board scripts which include these. Note that the aliases have horrible names. We'll need to fix that up.
* Linker scripts: Indent common_ram.inc, common_rom.inc.Marti Bolivar2011-09-092-148/+149
|
* Tidy up linker scripts.Marti Bolivar2011-09-0712-27/+19
| | | | Comment/whitespace changes only.
* [support/ld] Factor out header from common_rom.inc, common_ram.inc.Marti Bolivar2011-09-073-73/+48
| | | | | | | The linker scripts share an initial section. Factor this out into a new file common_header.inc, and have the main linker scripts include this file. Apart from eliminating a redundancy, this will make it easier to add new linker scripts in the future.
* Doxyfile: add __DOXYGEN_PREDEFINED_HACK to PREDEFINED.Marti Bolivar2011-08-221-1/+2
| | | | | | | Doxygen refuses to trust us when we \def something that it doesn't notice as a #define. To work around this, we put __DOXYGEN_PREDEFINED_HACK into our Doxyfile's PREDEFINED, so that documentation may be inserted for #defines which we know will exist.
* Fix Doxyfile.Marti Bolivar2011-08-031-5/+5
|
* DMA: Fix non-working DMA interrupts.Marti Bolivar2011-06-201-7/+7
| | | | | | | | | | | | | | | | | | | | | | libmaple/dma.c defines DMA interrupts __irq_dma_channel[1-7], consistent with what is specified by support/ld/names.inc. However, names.inc is inconsistent with what support/ld/libcs3_stm32_src/ expects. Specifically, it contradicts the files - support/ld/libcs3_stm32_src/stm32_isrs.S - support/ld/libcs3_stm32_src/stm32_vector_table.S Which use the names __irq_dma1_channel[1-7]. Change names.inc and dma.c to use the correct IRQ names. The original names.inc/libcs3_stm32_src inconsistency was introduced in 43d6921658cd29b8022af4424d340a90fbcb9a7f, but dma.c had the correct names until ec3cf2903f4b03bc1dae5e159495c9e5ef0938ca, where they were renamed for consistency with names.inc. At that point, DMA interrupts stopped working. (This was documented in the commit message). Thanks to forum user robodude666 for tracking this down.
* Remove reST documentation, attendant updates.Marti Bolivar2011-06-112-17/+1642
| | | | | | | | | | | | | | | | | | | | | | The documentation covers topics not specifically relevant to libmaple, so it doesn't make sense for it to be part of the libmaple source distribution. Delete the docs/ tree, and prepare libmaple for use with the new leaflabs-docs repo, which will contain the docs from now on. * README: update to reflect this change * support/doxygen/Doxyfile: This is the old docs/Doxyfile * Makefile: Add a doxygen target * wirish/comm/HardwareSerial.h: fix reference to docs/. The comment informing maintainers that the HardwareSerial interface is documented by hand refers to the docs/ tree, which no longer exists. Update it to refer to the separate leaflabs-docs repository. * support/scripts/copy-to-ide: No longer build the documentation
* 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: Add missing filePerry Hung2011-05-271-0/+16
| | | | | Forgot openocd support script in 0e5eb75c80bd8036bf85bfe0cce09d1fce56f50a.
* openocd: Fix repeated JTAG flash failure, use alternate reset configPerry Hung2011-05-262-7/+13
| | | | | | | | | | | | | | | | | | 1) Reset, halt, and unprotect the the flash before writing to it. This fixes a bug in which every other flash attempt would fail. 2) Maple R5 and below have NRST and JTNRST erroneously tied together, resulting in a full TAP and system reset when a reset is asserted. This prevents the 'reset halt' command from working. This can be fixed hard-hack style by cutting the trace out of JTNRST. Users of the Leaf Maple JTAG adapter will also need to cut the trace between TRST and SRST. 3) Assuming you have a functioning 'reset halt' setup (see 2), the 'make debug' command now halts the chip and waits for a gdb connection before proceeding execution.
* openocd: Detect openocd versionPerry Hung2011-05-265-1/+1
| | | | | Small script to detect the openocd version and choose the appropriate debug/flash script for use with JTAG debugging.
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-01 07:02:02 +0000