- 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>
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>
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>
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>
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>
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>
Pull some code out of the F2 pinMode() into a utility function. This
feels generally useful enough to be exposed to the users (it will, for
example, make it easier to implement input capture in a clean way).
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>
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>
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>
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.
The timer enumerators are different tokens on F2 than they are on F1.
This is wrong (breaks portability), so fix it, and update the F2
rcc_dev_info table to match.
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>
fsmc_sram_init_gpios() is now series-specific, so move its existing
implementation to the F1 backend, and add libmaple/stm32f2/fsmc.c for
the F2 backend.
Delete libmaple/fsmc.c; it is now empty.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
FIXME:
- Test F1 support
- Solve problem of duplicated bytes being TXed unless delay is
inserted after configuration but before first bytes are TXed.
Rip out nonportable bits from top-level interfaces. The USART register
maps are basically the same between F1 and F2, so leave these, but add
register bit definitions which had name changes to the libmaple header
to avoid needless repetition. There are also a few new bits in the F2
USART registers; add definitions for these in the F2 USART header. Add
Doxygen comments for all USART bit definitions.
Deprecate struct usart_dev's max_baud field. This is just bloat that
doesn't bring us much real benefit.
Add new series-specific USART files for F1 and F2:
- libmaple/stm32f[1,2]/usart.c
- libmaple/stm32f[1,2]/include/series/usart.h
These are standard series-specific files, providing register map base
pointers, defining devices, implementing nonportable routines, etc.
We need a portable way to configure the USART GPIOs. To this end, add
usart_async_gpio_cfg() to the top-level USART interface. This function
is implemented in new F1 and F2 USART backends to take the appropriate
action to configure the RX and TX pins for asynchronous full duplex
mode.
USART baud rate calculation is done differently on the different
series. Keep the usart_set_baud_rate() declaration in the top-level
USART header, but move the implementations into the series-specific
usart.c files.
In usart_set_baud_rate(), allow for deriving clock_speed automatically
by letting user tell us to figure out the peripheral clock speed by
mapping the device's rcc_clk_id onto an STM32_PCLK[1,2] value. This
preserves flexibility for users with non-default clock configurations,
but makes things easier on everyone else.
Add private USART files for portable private USART routines:
- libmaple/usart_private.h
- libmaple/usart_private.c
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Add GPIO_AFRL and GPIO_AFRH bit definitions; these seem to have been
overlooked. Add enum gpio_af to give labels to the various
functions. Add gpio_set_af() convenience routine for configuring a
GPIO's alternate function.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
The new style for configuring the PLL is to initialize
a (series-specific) struct rcc_pll_cfg, and pass a pointer to it to
rcc_configure_pll(). After that's done, you can use
rcc_turn_on_clk(RCC_CLK_PLL) to turn on the main PLL, and busy-wait
until rcc_is_clk_ready(RCC_CLK_PLL) is true to make sure the new
configuration took effect.
- libmaple/rcc.h:
-- Add struct rcc_pll_cfg, which specifies a PLL configuration. This
specifies a PLL source and a void pointer to series-specific PLL
configuration data.
-- Add rcc_configure_pll(), which takes a pointer to struct
rcc_pll_cfg, and configures the main PLL. It's up to each series
to define this function.
- stm32f1/rcc.h: Add struct stm32f1_rcc_pll_data, to store F1-specific
PLL configuration state.
- stm32f1/rcc.c: Add an implementation for rcc_configure_pll().
- stm32f2/rcc.h: Add struct stm32f2_rcc_pll_data, to store F2-specific
PLL configuration data.
- stm32f2/rcc.c: Add an implementation for rcc_configure_pll().
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
