|
|
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>
|
