| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
avr-gcc does it this way. Seems ok to me.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
| |
Signed-off-by: Anton Eltchaninov <anton.eltchaninov@gmail.com>
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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>
|
|
|
|
|
|
| |
These no longer exist.
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>
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Tweak Makefile further for cs-make on Windows. Add Windows support
to support/scripts/reset.py
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Oh, copy-to-ide. I long for your death.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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().
|
|
|
|
| |
Explain what's going on so unfamiliar readers have more hope.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Comment/whitespace changes only.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
- This allows to including of libs headers eg:
#include <Servo.h>
which wasn't possible for some reason.
|
|
|
|
|
| |
Forgot openocd support script in
0e5eb75c80bd8036bf85bfe0cce09d1fce56f50a.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Small script to detect the openocd version and choose the appropriate
debug/flash script for use with JTAG debugging.
|
|
|
|
|
|
|
| |
Committing the results of running the following on the libmaple root
directory:
$ fromdos `grep --exclude-dir='[.]git' -Ilsr $'\r$' .`
|
| |
|
| |
|
| |
|