aboutsummaryrefslogtreecommitdiffstats
path: root/libmaple/stm32f1/include
Commit message (Collapse)AuthorAgeFilesLines
* Set DCNTR before starting DMA transfer.Manuel Odendahl2013-01-171-0/+10
| | | | | | | I am not sure why this would work for most DMA transfers but I ran into trouble when doing SDIO DMA. Signed-off-by: Manuel Odendahl <wesen@ruinwesen.com>
* ADC: Doxygen fixupsMarti Bolivar2012-06-291-12/+11
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Doxygen hacks and fixups.Marti Bolivar2012-06-281-1/+1
| | | | | | | | - 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>
* stm32f1: gpio.h: Add another hack mode macro.Marti Bolivar2012-06-261-0/+1
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* I2C: Deprecate I2C_REMAP flag.Marti Bolivar2012-06-221-0/+16
| | | | | | | | 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>
* I2C: Move F1-only errata workarounds out of libmaple/i2c.c.Marti Bolivar2012-06-221-0/+3
| | | | | | | | | 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>
* i2c_set_input_clk(): fix an F1-ism.Marti Bolivar2012-06-221-0/+10
| | | | | | | | | | | | | | | 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>
* Move i2c_dev and i2c_state into new i2c_common.h.Marti Bolivar2012-06-221-4/+4
| | | | | | | 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>
* I2C: Restore on F1, refactoring prep for F2.Marti Bolivar2012-06-221-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Implement DMA tube API on STM32F1.Marti Bolivar2012-06-151-0/+2
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* DMA: prep for F2 with new "tube" API.Marti Bolivar2012-06-151-143/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Bring back <libmaple/spi.h>.Marti Bolivar2012-06-071-3/+0
| | | | | | | | | | | 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>
* series/timer.h: Remove silly duplicate declarations.Marti Bolivar2012-06-071-1/+0
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* stm32.h: Soften "missing MCU" errors into warnings.Marti Bolivar2012-06-071-2/+1
| | | | | | | | | | | | | | 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>
* Bring back libmaple/dac.h.Marti Bolivar2012-06-041-0/+71
| | | | | | | Minor variations on F2: DMA underrun interrupts, and a status register to hold the notification bits. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* stm32.h: Add STM32_HAVE_DAC feature-test.Marti Bolivar2012-06-041-0/+5
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* STM32F1: gpio.h: Add hack mode macro, for F2 compatibility.Marti Bolivar2012-06-041-0/+3
| | | | | | | | 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>
* STM32F2: Add EXTI support.Marti Bolivar2012-06-031-0/+46
| | | | | | | | 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>
* STM32F1: gpio.h: Cosmetics.Marti Bolivar2012-06-031-100/+85
| | | | | | | 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>
* Bring back EXTI on F1, with deprecations for gpio.h on F1.Marti Bolivar2012-06-031-96/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Globally switch style for GPIO config routines.Marti Bolivar2012-06-031-0/+32
| | | | | | | | | | | | | | | | | | | | 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>
* Sort the rcc_clk_id enumerators semi-alphabetically.Marti Bolivar2012-06-021-27/+27
| | | | | | | | | | | | | | | | 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>
* Oops; don't break the build on F1.Marti Bolivar2012-06-021-1/+0
| | | | | | That was dumb. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/stm32.h: Add STM32_TIMER_MASK, STM32_HAVE_TIMER.Marti Bolivar2012-06-011-0/+8
| | | | | | | | | | | | | | | | | | 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>
* STM32F1: Fix nvic_irq_disable_all() on some MCUs.Marti Bolivar2012-05-311-8/+6
| | | | | | | | | | 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>
* nvic.h: Doxygen: nvic_irq_num is target dependent.Marti Bolivar2012-05-311-1/+1
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* series/rcc.h: Lose BIT().Marti Bolivar2012-05-311-132/+142
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* stm32f1/rcc.h: Add a FIXME.Marti Bolivar2012-05-311-0/+2
| | | | | | Having a separate struct is stupid. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* RCC: DoxygenMarti Bolivar2012-05-311-45/+43
| | | | | | | Various changes to Doxygen structure, to help leaflabs-docs make sense of everything. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Lose <libmaple/util.h> dependency in series/flash.h headers.Marti Bolivar2012-05-091-23/+23
| | | | | | Switch from BIT(...) to (1U << ...). Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* flash.h: Doxygen.Marti Bolivar2012-05-091-1/+0
| | | | | | | Document FLASH_BASE once. This is due to restrictions in the documentation build system. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Change __DOXYGEN_PREDEFINED_HACK to __DOXYGEN__.Marti Bolivar2012-05-091-2/+2
| | | | | | avr-gcc does it this way. Seems ok to me. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Mark Doxygen for Flash register maps as series-specific.Marti Bolivar2012-05-081-1/+1
| | | | | | | 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 a bunch of Doxygen file-level comments.Marti Bolivar2012-05-088-13/+15
| | | | | | | | | | | | | 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>
* stm32f1: stm32.h: Tweak STM32_F1_LINE_xxx for mnemonic value.Marti Bolivar2012-05-081-6/+6
| | | | | | | | | | 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>
* stm32f1: stm32.h: Doxygen.Marti Bolivar2012-05-081-5/+5
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* stm32f1: stm32.h: Cosmetics.Marti Bolivar2012-05-081-4/+10
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* stm32f1: stm32.h: Add Doxygen comments.Marti Bolivar2012-05-081-0/+22
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* stm32f1: stm32.h: Add hooks for USB access line.Marti Bolivar2012-05-081-1/+3
| | | | | | | 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>
* stm32f1: stm32.h: Fix wrong comment.Marti Bolivar2012-05-081-3/+0
| | | | | | We've got some value line values now. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* stm32f1/adc.h: Add missing includes.Marti Bolivar2012-05-031-0/+2
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* STM32F1: adc: Tweaks for XL-density MCUs.Marti Bolivar2012-05-031-3/+1
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* stm32f1: Resurrect DMA support. (sets up breaking change)Marti Bolivar2012-05-031-0/+438
| | | | | | | | | | | | | | | | | 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>
* STM32VLDiscovery support filesAnton Eltchaninov2012-05-031-0/+15
| | | | | Signed-off-by: Anton Eltchaninov <anton.eltchaninov@gmail.com> Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* stm32.h: Various updates, mostly to help STM32F1 line support.Marti Bolivar2012-04-241-31/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* stm32f1: stm32.h: Fix comment typo.Marti Bolivar2012-04-241-1/+1
|
* stm32f1: stm32.h: Put MCU section first, allow overrides.Marti Bolivar2012-04-231-30/+47
| | | | | | | | | | 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>
* libmaple/spi: Fixups, move nonportable bits into libmaple/stm32f1.Marti Bolivar2012-04-111-0/+70
| | | | | | | | | | | 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>
* STM32F1: Add support for timers 9 through 14.Marti Bolivar2012-04-111-5/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* stm32f1/nvic.h: Add nvic_irq_num's for XL-density timers; Doxygen fixup.Marti Bolivar2012-04-111-7/+45
| | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-22 09:51:50 +0000