| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i2c_set_input_clk()'s documentation says that the maximum peripheral
clock frequency is 36 MHz, but that's a hard-coded magic number. The
actual limit is the device's APB frequency or 46 MHz, whichever is
lower (F2 and F4 share the 46 MHz limit).
Fix the documentation to reflect that fact, and add an internal
series-provided function to get the maximum clock frequency for a
device. To help users porting to F2, have i2c_set_input_clk()
assert-check that the provided frequency is less than that maximum
value and the hard 46 MHz limit.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
| |
This is necessary to add series-specific infrastructure to clean up
some F1-isms in <libmaple/i2c.h>'s inline functions.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bring back <libmaple/i2c.h> support on STM32F1 with a view towards how
it'll be implemented on STM32F2. There are still many F1-isms in
libmaple/i2c.c and <libmaple/i2c.h>, to be dealt with subsequently.
Move device declarations and base pointer definitions to a new F1
<series/i2c.h>. The register maps and bit definitions themselves are
identical on both series, so leave them in the libmaple header.
Add i2c_private.h, which contains:
- I2C_DEV(), a convenience macro for defining an i2c_dev, and
- declarations for the event and error IRQ handlers.
The IRQ handlers are large, and I2C is slow anyway, so I see no reason
to make them inline in the private header (as we do for some other
peripherals). We just expose the existing ones that were formerly
static in libmaple/i2c.c, but prefix the names with underscore.
Move the device declarations and IRQ handlers into new
stm32f1/i2c.c. These use the i2c_private.h API.
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Minor variations on F2: DMA underrun interrupts, and a status register
to hold the notification bits.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
| |
I'm sure we can work the compatible subset of F1/F2 GPIO functionality
into the F1 gpio.h interface in a clean way. This is not that clean
way, but I'm short on time.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
| |
Add series headers to keep the base pointers, and (on F2) use SYSCFG
to tell exti_do_select() where the EXTI control registers are. No
surprises.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
| |
Those ugly Doxygen comments have been bothering me since forever. Fix
them up and throw some M-x align around.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tested on Maple Mini with examples/mini-exti-test. Changes to Wirish
are minor: use the new EXTI types exti_num and exti_cfg (see below) in
place of now-deprecated variants in ext_interrupts.cpp.
The way I originally did libmaple/exti.h was stupid, and fixing it
turned out to be a little disruptive.
libmaple/exti.h depends on libmaple/gpio.h (for AFIO), but that's a
classic case of exposed implementation detail. So invert the
dependency: make gpio.h depend on exti.h. Do this by adding exti_num
and exti_cfg to exti.h; these respectively replace afio_exti_num and
afio_exti_port. The afio_* variants are now deprecated. (Throw in a
typedef and some macros at the bottom of the F1 series/gpio.h for
backwards compatibility).
Make exti_attach_interrupt() and exti_detach_interrupt() take
exti_num/exti_cfg arguments instead of the afio_* variants.
Make the EXTI dispatch routines __always_inline to defeat GCC -Os.
Many renames throughout libmaple/stm32f1/ to stop using the deprecated
names. Also move the previously F1-only gpio_exti_port() function into
the public libmaple header. Reimplementing it in terms of rcc_clk_ids
lets us deprecate the gpio_dev->exti_port field, which will save space
in the future.
While we're there, I notice that struct gpio_dev is defined once per
series. That's dumb, as it misses the entire point of having device
structs: they contain what's portable. So put the F1 version (which
has the extra EXTI port field) into libmaple/gpio.h, and add the
necessary exti_ports to libmaple/stm32f2/gpio.c. Sigh. We'll get rid
of it eventually, at least.
Clean up some other mistakes in gpio.h files as well (mostly removing
util.h dependency). Sorry for the messy commit.
For portability, add a new series-specific exti function,
exti_select(). The F1 version in (new) libmaple/stm32f1/exti.c uses
AFIO and some new private functionality in libmaple/exti.c and (new)
libmaple/exti_private.h to make this convenient. We'll be able to do
the SYSCFG equivalent on F2 without any trouble.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stupidly, spi_gpio_cfg() didn't take a spi_dev* argument on F1,
because it doesn't matter there. On F2, where we need to set an
alternate function when configuring GPIOs for SPI, we need to know the
dev.
We can't add break backwards compatibility, so we need a new
function. However, we've since added a bunch of foo_gpio_cfg()
routines, and we don't want confusing asymmetry in the names. So a
global style change is needed. (Fortunately, the new functions weren't
part of a release, so it's no problem to change their names).
Change all foo_gpio_cfg() routines to foo_config_gpios() (or
foo_config_gpio(), if there's only one GPIO to configure). For
backwards compatibility, make spi_gpio_cfg() on F1 an __always_inline
call to spi_config_gpios().
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only semi-alphabetically because peripherals are kept together (so the
UARTs sort as if they were USARTs). Advantages:
- It lets us play numeric comparison and lookup-table hacks, as we now
have the property that the rcc_clk_ids for a given peripheral are a
contiguous range of integers.
- It will hopefully let the compiler emit faster/smaller code for
switches over a dev->clk_id.
- It's better intuitively.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
| |
That was dumb.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Feature-test macros for dealing with the fact that timer support has
holes. STM32_TIMER_MASK is a bitmask where bit n is set when TIMERn is
present. STM32_HAVE_TIMER(n) just tests whether bit n is set in
STM32_TIMER_MASK.
This is necessary because e.g. the STM32F100RB has timers 1-4, 6, 7,
and 15-17. Because of this, the usual STM32_NR_whatever won't work,
and we use a bitmask instead.
For F1 performance line (F103s), STM32_TIMER_MASK can be derived from
the density. For F1 value line, I'm not as sure, so just add it for
the single MCU we support (the STM32F100RB). Same story for F2: add it
for the STM32F207IC. We can fix this up later if necessary.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
| |
The current implementation only disables the first 64 IRQ lines. This
covers all the chips we currently support, but it'll be a nasty
surprise if anyone decides to add e.g. connectivity line MCUs (which
have more IRQs) in the future. We already have the infrastructure to
fix it in a clean way, so we might as well do it now.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
| |
Having a separate struct is stupid.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
| |
Various changes to Doxygen structure, to help leaflabs-docs make sense
of everything.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
| |
Switch from BIT(...) to (1U << ...).
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
| |
Document FLASH_BASE once. This is due to restrictions in the
documentation build system.
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>
|
|
|
|
|
|
|
| |
This will let help us verify that we got the right thing when we pull
it out of of Doxygen XML for the official HTML documentation.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix @file in many places. Also fix up the descriptions where it's
appropriate. This standardizes the @file formatting across the library
to explicitly include any parent directories up to the repository
root.
Besides being nice, this will hopefully let us manage Doxygen's XML
output so as to make extracting series-specific pieces via Breathe in
the leaflabs-docs repo possible.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
| |
Change the values of the STM32_F1_LINE_xxx macros to match the part
number better (so performance line, or F103s, now have
STM32_F1_LINE_PERFORMANCE==3, F100s have STM32_F1_LINE_VALUE==0,
etc.). This will hopefully make debugging or error checking easier for
someone at some point.
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>
|
|
|
|
|
|
|
| |
There are five F1 lines in total. The necessary infrastructure for USB
access line (STM32F102 MCUs) support is missing, so add it.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
| |
We've got some value line values now.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Breaking change set up: struct dma_handler_config is no longer part of
the public API in <libmaple/dma.h>. User code which was touching
these was always mistaken; it should be using dma_attach_interrupt()
or dma_detach_interrupt() instead.
Other than that, just move the nonportable bits in <libmaple/dma.h>
and libmaple/dma.c to the appropriate places under
libmaple/stm32f1/. (Ouch. This is almost everything.) Patch the
(new) STM32F1 <series/dma.h> here and there to make everything
compile; this is mostly limited to forward-declaring struct dma_dev
and providing a hack _dma_dev_regs() declaration so inline functions
in the series header can still access a device's registers.
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Put the section defining MCU-specific values before the other
sections. Surround the density-specific defines with #ifndef/#endif
pairs. This allows any of the settings in the STM32F1 stm32.h to be
overridden on a per-MCU basis. That's hopefully useful to e.g. people
porting libmaple to STM32F100 MCUs, which have slower clocks.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Standard family support refactoring: add STM32F1 series spi.h, spi.c,
and move anything that won't port to STM32F2 there.
As part of a general effort to be cleaner, remove the dependency on
libmaple/util.h from libmaple/spi.h by not using BIT(). Also forward
declare struct gpio_dev for spi_gpio_cfg() to remove that include.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This applies to XL-density STM32F1 devices.
In stm32f1/timer.c, add timer_dev's for the new timers, using the
timer_private API. These definitions are conditionally compiled based
on the target density to avoid wasting space on smaller MCUs. Also add
calls to the appropriate timer_private.h dispatch routines within the
IRQ handlers for these timers. We need to change the IRQ handler names
to reflect this eventually, but put that off for now, as it could
break backwards compatibility in some exotic situations where the user
refers to the libmaple IRQ handlers directly.
In stm32f1/timer.h, add register map base pointers and device
declarations for the new timers. timer_dev* declarations are compiled
in only when the target MCU supports them, in keeping with the above
stm32f1/timer.c changes.
In libmaple/timer.c, update the (static) IRQ enable routines to
account for the additional timers. This adds some code that's
unnecessary on smaller STM32F1s, but it's minimal (40 extra bytes on
my machine), so portability and readability win out.
Size change, using GCC version "(Sourcery G++ Lite 2011.03-42) 4.5.2":
Before:
text data bss dec hex filename
615 0 0 615 267 build/home/mbolivar/leaf/libmaple/libmaple/timer.o
After:
text data bss dec hex filename
655 0 0 655 28f build/home/mbolivar/leaf/libmaple/libmaple/timer.o
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a backwards-compatible change, but it deprecates some existing
functionality.
XL density STM32F1 devices have additional timers 9 through 14. These
share NVIC lines with timers 1 and 8. This scheme is also used on
e.g. STM32F2, so the corresponding nvic_irq_num enumerators on that
series have names like "NVIC_TIMER1_BRK_TIMER9" instead of
"NVIC_TIMER1_BRK". For portability (and XL-density support), it makes
sense to add these enumerators to the F1 version of nvic_irq_num,
which we do here.
For backwards compatibility, we keep the old enumerators (like
NVIC_TIMER1_BRK) around as aliases to the new ones (like
NVIC_TIMER1_BRK_TIMER9). These old enumerators are now deprecated.
Also fix up the Doxygen @file header.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix copy-paste errors in, and add missing, register bit
definitions. For copy-paste errors that would result in source
incompatibilities with past releases, add some legacy defines.
Add series header and C file for STM32F1 which fills in the missing
API. Much of the F1 timer.c would be repeated on F2, so also add
timer_private.h to hold these.
Support for timers 9 through 14 is still missing.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
| |
Whether or not a given peripheral is present on an F1 series MCU
doesn't matter. It doesn't take up any extra space to include these
enumerators, and it's convenient to have them defined so portable
libmaple routines can safely refer to them. This can prevent the need
for special series-specific versions of some functions.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function has been with us from the earliest days of libmaple.
It's showing its age, as the API it presents is tied to the
STM32F1. Deprecate it, and provide instructions for how to use newer,
more portable APIs. The new way is more verbose, but we can always add
a portable "just set up the PLL, dammit" convenience function later (a
nice candidate is to extract an interface from setup_clocks() in
boards.cpp).
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Standard refactoring: add series headers for F1 and F2, along with
series adc.c files. There are some issues relating to adc_extsel_event
to hammer out later, but this will do for now.
We also add some new portability interfaces to libmaple/adc.h in order
for Wirish to use the same code to initialize the ADCs at init() time.
As usual, F1 is untested.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
| |
Just add the missing register bit definitions in new series headers.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|