| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
enum stm32_series gives a tag to each STM32 series, including the ones
we don't yet support.
STM32_MCU_SERIES is a define which the series stm32.h header must
provide, identifying the series of the MCU being targeted.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is for greater consistency with the ST application notes, which
refer to migrating "across" series (e.g. F1 to F2), but compatibility
"within" a family (e.g. F1).
So:
- Move libmaple/stm32x/include/family to .../include/series/ and fix
up includes appropriately.
- Refer to "family" headers as "series" headers in comments.
- Make similar "find and replace"-style changes to build system
variable names and comments.
- Move support/ld/stm32/family to .../stm32/series.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the smallest wait state value that is safe for use when the
MCU is at its fastest rate, not considering overclocking. This
requires moving the FLASH_WAIT_STATE defines above the family include,
so do that, and add the missing #defines (for wait states up to 7).
For the STM32F1, the correct value for FLASH_SAFE_WAIT_STATES is
FLASH_WAIT_STATE_2; say so in the F1-family flash.h.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
| |
These go in a new family header, libmaple/stm32f1/include/family/stm32.h.
While we're at it, do some reorganizing.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make a new family header, libmaple/stm32f1/include/family/gpio.h, and
supporting libmaple/stm32f1/gpio.c.
Beyond registers and devices, these also include anything mentioning
AFIO, which doesn't exist on F2.
Update libmaple/stm32f1/rules.mk for new gpio.c.
Alter gpio_write_bit() to use dev->regs->BSRR only. BRRs are not
present on STM32F2.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
| |
Backwards-compatible. Only the headers need to change.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a backwards-compatible change.
The Flash registers on the STM32F2 line are different than on
STM32F1. Therefore, move the register map and bit definitions to new
libmaple/stm32f1/include/family/flash.h.
Move flash_enable_prefetch() from libmaple/flash.c to new
libmaple/stm32f1/flash.c. The remaining pieces of libmaple/flash.c use
a common subset of the Flash registers, so they're's portable to F2,
and that's all we're currently interested in.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a backwards-compatible change.
Modify libmaple/rules.mk to include the family's include
directory. This allows libmaple/include/libmaple/rcc.h to include the
STM32F1 RCC header with #include <family/rcc.h>. We'll use this
convention henceforth to distinguish between top-level and
family-specific headers.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add libmaple/usb/rules.mk, which compiles the USB FS device firmware
submodule. Move the logic for compiling the USB stack from
libmaple/rules.mk into libmaple/usb/rules.mk.
Move libmaple/usb/usb_cdacm.h to libmaple/include/libmaple/. Its API
is sufficiently general that we'll be able to port it over to USB
OTG (either FS or HS) eventually, and that lets us include it from
Wirish using the new style for libmaple headers.
Fix the includes for public libmaple headers within libmaple/usb.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
Move libmaple/*.h to (new) libmaple/include/libmaple/. The new
accepted way to include a libmaple header foo.h is with:
#include <libmaple/foo.h>
This is more polite in terms of the include namespace. It also allows
us to e.g. implement the Arduino SPI library at all (which has header
SPI.h; providing it was previously impossible on case-insensitive
filesystems due to libmaple's spi.h).
Similarly for Wirish.
The old include style (#include "header.h") is now deprecated.
libmaple/*.h:
- Change include guard #defines from _FOO_H_ to _LIBMAPLE_FOO_H_.
- Add license headers where they're missing
- Add conditional extern "C" { ... } blocks where they're missing
(they aren't always necessary, but we might was well do it against
the future, while we're at it.).
- Change includes from #include "foo.h" to #include <libmaple/foo.h>.
- Move includes after extern "C".
- Remove extra trailing newlines
Note that this doesn't include the headers under libmaple/usb/ or
libmaple/usb/usb_lib. These will get fixed later.
libmaple/*.c:
- Change includes from #include "foo.h" to #include <libmaple/foo.h>.
Makefile:
- Add I$(LIBMAPLE_PATH)/include/libmaple to GLOBAL_FLAGS. This allows
for users (including Wirish) to migrate their code, but should go
away ASAP, since it slows down compilation.
Wirish:
- Move wirish/**/*.h to (new) wirish/include/wirish/. This ignores
the USB headers, which, as usual, are getting handled after
everything else.
- Similarly generify wirish/boards/ structure. For each supported
board "foo", move wirish/boards/foo.h and wirish/boards/foo.cpp to
wirish/boards/foo/include/board/board.h and
wirish/boards/foo/board.cpp, respectively. Also remove the #ifdef
hacks around the .cpp files.
- wirish/rules.mk: put wirish/boards/foo/include in the include path
(and add wirish/boards/foo/board.cpp to the list of sources to be
compiled). This allows saying:
#include <board/board.h>
instead of the hack currently in place. We can allow the user to
override this setting later to make adding custom board definitions
easier.
- Disable -Werror in libmaple/rules.mk, as the current USB warnings
don't let the olimex_stm32_h103 board compile. We can re-enable
-Werror once we've moved the board-specific bits out of libmaple
proper.
libraries, examples:
- Update includes accordingly.
- Miscellaneous cosmetic fixups.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|