We're more portable since last writing. We also shamefully ignore the
bugtracker and blocking changes pages, so drop those for now. Other
tweaks and fixups.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Switch to the new include style. Move includes in headers inside the
include guards, for the GCC multiple include parser optimization. Make
80-column clean. Add newlines at end of files.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Added a generic pure abstract class to provide the interface for all
Wire implementations. Modified the old Wire library using software
interface to use the new Base Wire abstract class. Added a new
library which allows the use of the Wire class to use the I2C
hardware. Changed default pin numbers for Software Wire library to
match pin numbers used for I2C/TWI shields created for the Arduino.
Signed-off-by: Trystan Jones <crenn6977@gmail.com>
- 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>
It's about time. This initial file is based on the output of
$ git log | grep Author | sort | uniq
It leaves out credit for patches that were later reverted or moved out
of libmaple. It also doesn't credit the many patches and other
bugfixes from users who've e.g. written in the forum describing their
changes, but didn't submit actual patches. Names aren't always
available in cases like those, but if the contributors come forward,
we'd be happy to add them.
Add note in HACKING about adding yourself to CREDITS.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Use "from __future__ import print_function" so the recent py3k
compatibility patches to reset.py preserve the old output in Python 2.
This increases our minimum Python version to 2.6, but avoids ugly
output Python 2, where print statements with a tuple argument print
the tuple with parentheses etc.
Python 2.6 came out almost four years ago, and it's widely available:
- even on older Linux distros (e.g. Ubuntu 10.04 and Debian Squeeze
have 2.6 default at time of writing),
- on OS X since 10.6,
- and Windows users will probably be installing from python.org
anyway, so they've likely got a reasonably recent vintage.
Dropping 2.5 support thus doesn't seem likely to cause problems.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Make the reset script work for both python2 and python3 by putting brackets around print statements and properly encoding the string sent with ser.write
Signed-off-by: Hanspeter Portner <agenthp@users.sf.net>
It's wasting the users' and my time to have to point to this document
on every single pull request.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Works with officially supported CodeSourcery toolchain. May need
tweaks for users with a more modern arm-none-eabi-g++.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Merge the long-lived (too long; future changes like these will need to
proceed more incrementally) development branch of libmaple, containing
experimental STM32F2 and STM32F1 value line support, into master.
This required many changes to the structure of the library. The most
important structural reorganizations occurred in:
- 954f9e5: moves public headers to include directories
- 3efa313: uses "series" instead of "family"
- c0d60e3: adds board files to the build system, to make it easier to
add new boards
- 096d86c: adds build logic for targeting different STM32 series
(e.g. STM32F1, STM32F2)
This last commit in particular (096d86c) is the basis for the
repartitioning of libmaple into portable sections, which work on all
supported MCUs, and nonportable sections, which are segregated into
separate directories and contain all series-specific code. Moving
existing STM32F1-only code into libmaple/stm32f1 and wirish/stm32f1,
along with adding equivalents under .../stm32f2 directories, was the
principal project of this branch.
Important API changes occur in several places. Existing code is still
expected to work on STM32F1 targets, but there have been many
deprecations. A detailed changelog explaining the situation needs to
be prepared.
F2 and F1 value line support is not complete; the merge is proceeding
prematurely in this respect. We've been getting more libmaple patches
from the community lately, and I'm worried that the merge conflicts
with the old tree structure will become painful to manage.
Conflicts:
Makefile
Resolved Makefile conflicts manually; this required propagating
-Xlinker usage into support/make/target-config.mk.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Rip out the existing nonportable pieces, and shove them under
wirish/stm32f1, using weak symbols so users who only want libmaple
proper don't end up with build errors. Add stubbed-out (and only
partially functional) definitions for F2 targets under wirish/stm32f2.
The behavior on F103 targets is the same as it was before (though the
assertion framework has always been broken and badly needs
replacement, that awaits another commit). We additionally now skip
re-enabling USB on F1 targets without USB, to make things work on
value line MCUs.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
We can implement it in terms of _i2c_bus_clk() instead of hard-coding
STM32_PCLK1.
This might be overkill, since I2C peripherals are slow and thus likely
to be on APB1 for all STM32 devices (that is the case for F2/F4, for
instance), but if we're going to have _i2c_bus_clk(), we might as well
respect it.
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>
I'm going to be moving a lot of code around without changing it soon,
so git blame will be unreliable.
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>
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>
