| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| |
| |
| |
| | |
This is straightforward. Do it in a verbose style with lots of
comments, so we can use this patch as an example for how to port
existing DMA code.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To prepare for STM32F2/F4 DMA support, introduce a new libmaple DMA
API, and move some code around to make priority level and interrupt
handling more generic.
The new API is based on a new set of types (dma_tube, struct
dma_tube_reg_map, enum dma_request_src, enum dma_cfg_flags, and struct
dma_tube_config).
The central abstraction is the dma_tube type. STM32F2/F4 use DMA
streams to control dataflow, and STM32F1 uses channels. dma_tube
stands for whichever is appropriate for the current target. Dealing
with tubes allows for configuring and using DMA with opaque tube
values in the same source, instead of (as with ST's firmware)
requiring two separate codebases.
The new API is also more user-friendly, as it doesn't require knowing
which DMA address registers to set and which configuration register
flags go along with them. It now suffices to specify the source and
destination for the DMA transfer, along with their sizes. This avoids
confusion (e.g. for memory-to-memory transfers, data flows from the
peripheral address register to the memory register, which might be
surprising on F2, which has two memory address registers).
The old API (based on enum dma_mode_flags and dma_setup_transfer()) is
still available on F1, but deprecate it.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| | |
Touch up comments, change some function names, and don't set something
to zero which already is.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Someone pointed to this example on the DMA page in the wiki, so it's
probably worth making it more clear what's going on. Remove unused
code, add comments, and move things around for better exposition.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| | |
This is analagous to std::string::c_str().
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This will hold STM32-related things that I'm not sure are well-thought
out enough to go into <libmaple/stm32.h>. Currently, it contains an
accessor routine that tells you the purpose of the memory block
containing an address.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| | |
F2 doesn't work yet.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| | |
We derive SYSTICK_RELOAD_VAL from CYCLES_PER_MICROSECOND now, so let's
hide it for expert use.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of requiring everyone to figure it out for themselves, add
enumerators specifying the idle logic level and what clock edge
triggers data capture. Yes, it's easy enough to figure it out. It's
also convenient to have these.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a spi_private.h with a SPI_DEV(), for convenience. Use it in the
F1 and F2 implementations. We could probably unify these with an
STM32_HAVE_SPI(n) macro, but we'll leave that for the future.
Most everything from F1 is portable; F2 has some additional bit
definitions and a spi_get_af() routine, but that's about it.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| | |
_sbrk() is new in 2011, and there've been changes in 2012.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| | |
For overriding.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| | |
libmaple takes orders, it doesn't give them.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| | |
Make the Doxygen comments nicer to look at. Some of the docstrings are
out-of-date since F2 support was added, so update them.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The addition of STM32_HAVE_TIMER() allows us to avoid some
repetition. There's still an issue with names on F1 preventing us from
moving the IRQ handlers to libmaple/timer.c, but once that's resolved,
we'll be able to remove even more.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| | |
The current versions of DELARE_*_TIMER() don't play well with cscope,
which is a bad sign. Fix that.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| | |
This is now in contrib/.
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>
|
| |
| |
| |
| |
| |
| |
| | |
This shows people what to do to write boardInit(), but also how to
save work if they don't need it.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| | |
This allows dealing with push-buttons on pins other than
BOARD_BUTTON_PIN.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows boards to override the logic level of a pressed
button. All Maple boards have a pressed button read HIGH, but if the
opposite convention is used, isButtonPressed() will infinite loop.
Make isButtonPressed() respect this setting.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| | |
It's stupid to make everyone keep this around.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's not important whether the MCU is specified. What's important is
that <libmaple/stm32.h> gets everything it needs -- which it now
ensures that it does. Requiring people to do things on a per-MCU basis
hurts hackability and is just asking for trouble.
On the other hand, it's nice to provide a clue as to why
<libmaple/stm32.h> might be giving #errors, so do leave the
warnings. People can always hack the header to shut them up if they
want.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| |
| | |
This lets users override them conveniently if our decisions don't
suit.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| |
| |
| | |
This lets us remove the weak definition in boards.cpp.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
| |
| |
| | |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|