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>
Move the sysfs tests for Maple out of unix_get_maple_path() and into a
new linux_get_maple_path(). This prevents unnecessary probing for a
nonexistent /sys on e.g. OS X.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Adds a function to lookup the USB vendor & product id from
the udev info in the sysfs tree. This removes invalid choices
and reduces user queries for the correct ttyACM device.
Signed-off-by: David Kiliani <mail@davidkiliani.de>
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>
Move the actual QUIET setting to above mdebug(); that was
confusing. Rename _wait_for_ask to _wait_for_ack.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Support the extended erase memory command, which replaced the erase
memory command in the bootloader protocol as of version 3.0. This
takes a long time, so tweak _wait_for_ask to take an extra timeout for
special cases like this.
Use this under if __name__ == '__main__' to support F2 and
F4. Additionally, produce a human-readable report of the target chip
from its chip ID.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
- Shut Doxygen up in various places
- Fix some genuine docs bugs
- Ignore sources we're not responsible for
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Use "from __future__ import print_function" so the recent py3k
compatibility patches to reset.py preserve the old output in Python 2.
This increases our minimum Python version to 2.6, but avoids ugly
output Python 2, where print statements with a tuple argument print
the tuple with parentheses etc.
Python 2.6 came out almost four years ago, and it's widely available:
- even on older Linux distros (e.g. Ubuntu 10.04 and Debian Squeeze
have 2.6 default at time of writing),
- on OS X since 10.6,
- and Windows users will probably be installing from python.org
anyway, so they've likely got a reasonably recent vintage.
Dropping 2.5 support thus doesn't seem likely to cause problems.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Make the reset script work for both python2 and python3 by putting brackets around print statements and properly encoding the string sent with ser.write
Signed-off-by: Hanspeter Portner <agenthp@users.sf.net>
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 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>
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>
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>
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>
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>
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>
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.
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 628750bf82.
Don't mess with LIBMAPLE_INCLUDES. This variable comprises include
directories for libmaple proper, not for libraries that depend upon
libmaple.
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>
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>
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>
- 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>
