aboutsummaryrefslogtreecommitdiffstats
path: root/libmaple
Commit message (Collapse)AuthorAgeFilesLines
...
* I2C: Add i2c_config_gpios(), i2c_master_release_bus().Marti Bolivar2012-06-223-6/+43
| | | | | | These are necessary to pull out some calls to gpio_set_mode(). Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* <libmaple/i2c.h>: Fix Doxygen.Marti Bolivar2012-06-221-3/+3
| | | | | | | Existing Doxygen was commenting I2C_IRQ_ERROR instead of i2c_enable_irq(), as desired. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/i2c.h: Better comments.Marti Bolivar2012-06-221-2/+16
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/i2c.c: Replace throb() with ASSERT(0).Marti Bolivar2012-06-221-1/+1
| | | | | | Calling throb() directly like that breaks the abstraction. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* I2C: I don't think 10-bit addressing works.Marti Bolivar2012-06-221-0/+3
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* <libmaple/i2c.h>: Move low-level routines to end of file.Marti Bolivar2012-06-221-71/+73
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* I2C: Fix Doxygen F1-isms.Marti Bolivar2012-06-221-3/+6
| | | | | | | | 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(): fix an F1-ism.Marti Bolivar2012-06-222-1/+26
| | | | | | | | | | | | | | | 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-223-31/+84
| | | | | | | 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>
* libmaple/i2c.h: Cosmetics.Marti Bolivar2012-06-221-1/+4
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* I2C: Restore on F1, refactoring prep for F2.Marti Bolivar2012-06-227-63/+171
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* libmaple/i2c.c: Cosmetics.Marti Bolivar2012-06-221-2/+0
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* <libmaple/i2c.h>: Cosmetics.Marti Bolivar2012-06-221-6/+6
| | | | | | Put CCR definitions after SR2, to keep them in register map order. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* <libmaple/i2c.h>: Cosmetics.Marti Bolivar2012-06-221-20/+20
| | | | | | | Reorder register bit definitions by descending bit number, for consistency with the rest of the library. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* <libmaple/i2c.h>: Add missing register bit defns.Marti Bolivar2012-06-221-0/+22
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/i2c.h: Assert LeafLabs copyright.Marti Bolivar2012-06-221-0/+1
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Fix I2C_CR2_FREQ bit definition.Marti Bolivar2012-06-221-1/+1
| | | | | | The existing value clobbers the entire register. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/i2c.h: Cosmetics.Marti Bolivar2012-06-221-1/+1
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/i2c.h: Don't use BIT().Marti Bolivar2012-06-221-40/+40
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* <libmaple/dma.h>: Assert LeafLabs copyright.Marti Bolivar2012-06-211-0/+1
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Implement DMA tube API on STM32F2.Marti Bolivar2012-06-154-2/+1315
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Implement DMA tube API on STM32F1.Marti Bolivar2012-06-152-4/+60
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* DMA: prep for F2 with new "tube" API.Marti Bolivar2012-06-156-366/+1038
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 stm32_private.h.Marti Bolivar2012-06-121-0/+45
| | | | | | | | | This will hold STM32-related things that I'm not sure are well-thought out enough to go into <libmaple/stm32.h>. Currently, it contains an accessor routine that tells you the purpose of the memory block containing an address. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Build libmaple/dma.c on STM32F1.Marti Bolivar2012-06-121-1/+3
| | | | | | F2 doesn't work yet. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* enum spi_mode: Add more descriptive enumerators, documentation.Marti Bolivar2012-06-071-11/+16
| | | | | | | | | 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>
* Bring back <libmaple/spi.h>.Marti Bolivar2012-06-078-25/+221
| | | | | | | | | | | 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>
* Move syscalls.c into Wirish.Marti Bolivar2012-06-072-170/+0
| | | | | | libmaple takes orders, it doesn't give them. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/timer.h: Capitalization fixMarti Bolivar2012-06-071-2/+2
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/timer.h: Lose BIT().Marti Bolivar2012-06-071-90/+90
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/timer.h: Move deprecated bits to bottom.Marti Bolivar2012-06-071-66/+67
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* struct timer_dev: Don't touch ->handlers!Marti Bolivar2012-06-071-3/+1
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/timer.h: Nuke useless comment.Marti Bolivar2012-06-071-1/+1
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/timer.h: Doxygen beautification and fixupsMarti Bolivar2012-06-071-98/+109
| | | | | | | 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>
* Move timer_dev definitions into libmaple/timer.c.Marti Bolivar2012-06-074-192/+184
| | | | | | | | | 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>
* Tweak some timer_private APIs.Marti Bolivar2012-06-073-41/+36
| | | | | | | 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>
* series/timer.h: Remove silly duplicate declarations.Marti Bolivar2012-06-072-2/+0
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* stm32.h: Soften "missing MCU" errors into warnings.Marti Bolivar2012-06-072-3/+2
| | | | | | | | | | | | | | 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-045-82/+228
| | | | | | | 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-043-0/+12
| | | | 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-036-8/+127
| | | | | | | | 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>
* STM32F2: Add SYSCFG support.Marti Bolivar2012-06-033-0/+230
| | | | | | Turn it on at init() time on F2. 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-0311-188/+372
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* <libmaple/bitband.h>: DoxygenMarti Bolivar2012-06-031-2/+2
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/dac.c: Copyright.Marti Bolivar2012-06-031-0/+1
| | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* libmaple/dac.c: Generalize comment about PA4/PA5.Marti Bolivar2012-06-031-2/+2
| | | | | | Seems like this is true on F2 as well! Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Add ISRs and vector table for F1 value line.Marti Bolivar2012-06-035-4/+393
| | | | | | | | | | | | | | | | | Now libmaple/stm32f1/rules.mk tries to pull in ISRs and a vector table on a per-line basis. Move isrs_performance.S and vector_table_performance.S to (new) libmaple/stm32f1/performance, and rename them. Add corresponding files for value line under (new) libmaple/stm32f1/value. This helps clean up some performance-line-isms, and allows implementing e.g. the CEC interrupt, which is used by something else on performance line. Untested (I don't have access to a value line MCU); hopefully this works. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
* Slightly improve and generify the USB infrastructure.Marti Bolivar2012-06-039-49/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-22 21:52:30 +0000