| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
This has gone unmaintained for long enough.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
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>
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
We'll need to bring this functionality back online piecemeal as we add
F2 support.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
| |
We'll need to bring all this functionality back online piecemeal as we
add F2 support.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add libmaple/usb/rules.mk, which compiles the USB FS device firmware
submodule. Move the logic for compiling the USB stack from
libmaple/rules.mk into libmaple/usb/rules.mk.
Move libmaple/usb/usb_cdacm.h to libmaple/include/libmaple/. Its API
is sufficiently general that we'll be able to port it over to USB
OTG (either FS or HS) eventually, and that lets us include it from
Wirish using the new style for libmaple headers.
Fix the includes for public libmaple headers within libmaple/usb.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move libmaple/*.h to (new) libmaple/include/libmaple/. The new
accepted way to include a libmaple header foo.h is with:
#include <libmaple/foo.h>
This is more polite in terms of the include namespace. It also allows
us to e.g. implement the Arduino SPI library at all (which has header
SPI.h; providing it was previously impossible on case-insensitive
filesystems due to libmaple's spi.h).
Similarly for Wirish.
The old include style (#include "header.h") is now deprecated.
libmaple/*.h:
- Change include guard #defines from _FOO_H_ to _LIBMAPLE_FOO_H_.
- Add license headers where they're missing
- Add conditional extern "C" { ... } blocks where they're missing
(they aren't always necessary, but we might was well do it against
the future, while we're at it.).
- Change includes from #include "foo.h" to #include <libmaple/foo.h>.
- Move includes after extern "C".
- Remove extra trailing newlines
Note that this doesn't include the headers under libmaple/usb/ or
libmaple/usb/usb_lib. These will get fixed later.
libmaple/*.c:
- Change includes from #include "foo.h" to #include <libmaple/foo.h>.
Makefile:
- Add I$(LIBMAPLE_PATH)/include/libmaple to GLOBAL_FLAGS. This allows
for users (including Wirish) to migrate their code, but should go
away ASAP, since it slows down compilation.
Wirish:
- Move wirish/**/*.h to (new) wirish/include/wirish/. This ignores
the USB headers, which, as usual, are getting handled after
everything else.
- Similarly generify wirish/boards/ structure. For each supported
board "foo", move wirish/boards/foo.h and wirish/boards/foo.cpp to
wirish/boards/foo/include/board/board.h and
wirish/boards/foo/board.cpp, respectively. Also remove the #ifdef
hacks around the .cpp files.
- wirish/rules.mk: put wirish/boards/foo/include in the include path
(and add wirish/boards/foo/board.cpp to the list of sources to be
compiled). This allows saying:
#include <board/board.h>
instead of the hack currently in place. We can allow the user to
override this setting later to make adding custom board definitions
easier.
- Disable -Werror in libmaple/rules.mk, as the current USB warnings
don't let the olimex_stm32_h103 board compile. We can re-enable
-Werror once we've moved the board-specific bits out of libmaple
proper.
libraries, examples:
- Update includes accordingly.
- Miscellaneous cosmetic fixups.
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>
|
|
|
|
|
|
|
| |
Tweak Makefile further for cs-make on Windows. Add Windows support
to support/scripts/reset.py
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's been tricky for users to start their own projects while still
using our build system. The current recommended practice to get this
done involves modifying the top-level Makefile to add their module
into LIBMAPLE_MODULES, and include their own rules.mk. Editing the
repository Makefile is stupid and shouldn't be a necessary step.
Instead of that, allow the environment to provide the initial value
for LIBMAPLE_MODULES. This allows users to specify it on the command
line.
Also add WIRISH_PATH to the initial set of "useful" paths.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Remove doxygen from clean; no sense killing the docs just because you
want to change boards.
Add new "mrproper" target to nuke all autogenerated files; currently,
this is just the build/ and doxygen/ directories.
Make a note of BOARD env. variable and doxygen, mrproper targets from
help target.
|
| |
|
|
|
|
| |
example blinky.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
directory
|
|
|
|
|
| |
Small script to detect the openocd version and choose the appropriate
debug/flash script for use with JTAG debugging.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Basic PWM works. Had some problems in testing that might be due to
USART bugs.
HardwareTimer has been removed from the build for now; I will
re-implement it in terms of the new libmaple API, but consider it
deprecated. Let's come up with something better.
Servo is implemented in terms of HardwareTimer, so it also has been
temporarily removed from the build.
pwmWrite() likely got a little bit less inefficient due to
indirection, but the PIN_MAPs shrank by a pointer per PinMapping.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many of the #defines in libmaple.h were board-specific, not
MCU-specific. Most of these were only used by code under
libmaple/usb/. These were moved into usb_config.h, and are clearly
marked as being terrible hacks. I'm going to treat the USB stack as a
black box that we'll deal with later.
Further, instead of having a variety of #defines like "How many USARTS
do I have?", we decide that based on the density of the chip. This is
determined by testing for STM32_MEDIUM_DENSITY or STM32_HIGH_DENSITY
defines. libmaple currently doesn't support low-density chips, so
that suffices. The Makefile will set these automatically based on the
MCU.
Other offending #defines are ERROR_LED_PORT and ERROR_LED_PIN; these
were made optional, but they're set in the Makefile as a hack to keep
things working.
|
| |
|
| |
|
|
|
|
|
| |
Some additional HardwareTimer methods introduced to make this
convenient; ancillary libmaple/timers.h changes resulted.
|
|
|
|
| |
still need usb descriptors to improve, and also nothing else is tested.
|
|
|
|
|
|
|
|
| |
Redirect thread-mode execution to a fail routine which throbs the LED to
indicate a hard fault. Because the fail routine runs in thread mode
with interrupts on, USB auto-reset should now work. Test by executing
some bogus instruction (e.g. *(volatile int*)0xf34fdaa = 0;) and check
that the auto-reset continues to work.
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
Still not working but fixed a lot of merge errors
|
| |
| |
| |
| | |
Sort of ugly changes. Compiles but untested.
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
| |
Updated Makefile to read the directory where libmaple is from the
environment variable LIBMAPLE_PATH, if it exists, defaulting to the
current working directory otherwise.
Updated reset.py to look around in /dev for the Maple serial port,
prompting the user if there appear to be multiple possibilities and
complaining if there aren't any.
|
|
|
|
|
| |
The makefile 'install' target should upload to whatever the last build
target was, regardless of the environment's value of MAPLE_TARGET.
|