| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This was already supported, so just move the line coding structure to
the header and add some functions for accessing the current values.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
| |
Mark internal state static. Properly reset the RX/TX state on USB
reset. Choose better names for countTx and newBytes.
Move the exposed configuration back into the .c; this information is
not beneficial to hooks.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
| |
This keeps things in line with the specification, helping readability.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
| |
Finally!
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
| |
Use usb_cdcacm hooks to move the DTR edge and "1EAF" magic packet
detection to usb_serial.cpp. We'll later be able to extend this system
to support Leonardo-style reset signalling.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
| |
We need this so the bootloader reset signal detector can look ahead in
the byte stream without stealing bytes from the user when "1EAF" isn't
received.
While we're doing this, take the time to fix a bunch of RX-related
code (dead code removal, adding volatile, etc.)
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
| |
Provide hooks so users can reach into the CDC ACM callbacks with their
own code. We'll use this to move the bootloader reset signals to
Wirish.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
| |
Mark the API as unstable so people don't rely on these too hard. (This
header is not part of the official libmaple docs). We'll need some of
this configuration elsewhere later, and it doesn't make much sense to
expose it piecemeal.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@lozenge.(none)>
|
|
|
|
|
|
| |
Also, assert copyright LeafLabs 2012.
Signed-off-by: Marti Bolivar <mbolivar@lozenge.(none)>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@lozenge.(none)>
|
|
|
|
|
|
|
|
| |
- 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>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This won't work on F2, which at times has SDA and SCL on different
ports (e.g. I2C3 SDA on PC9, SCL on PA8). Add .sda_port and .scl_port
replacements, which are used when the now-deprecated .gpio_port is
null. Use them correctly everywhere, with some new i2c_private.h
helper functionality.
Sigh. The F1 I2C code tries too hard to guess what you wanted; it's
not porting well at all.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
| |
This is ad-hoc and nonportable. If you really want I2C mapped
elsewhere, then mess with the I2C device fields and call afio_remap()
yourself. (This is also cleaner for F2).
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
| |
The IRQ priority hack is unnecessary on targets with properly
functioning I2C IRQ handlers, so we shouldn't use it unless we have
to. Add a mechanism so a series header can provide such a hack if
necessary. Have the F1 series header use this mechanism.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
| |
These are necessary to pull out some calls to gpio_set_mode().
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
| |
Existing Doxygen was commenting I2C_IRQ_ERROR instead of
i2c_enable_irq(), as desired.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
| |
I'm not sure these functions should even exist in their present form,,
but I don't understand the code well enough to make a real fix. For
now, just replace references to RM0008 with "chip reference manual".
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Put CCR definitions after SR2, to keep them in register map order.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
| |
Reorder register bit definitions by descending bit number, for
consistency with the rest of the library.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
| |
The existing value clobbers the entire register.
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Turn it on at init() time on F2.
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>
|
|
|
|
| |
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>
|