Using GPIOA_IDR directly looks a bit arcane, and the example can benefit
from introducing gpio_get() and how to use it. The stm32f0-discovery
example already does it like this.
Instead of OOCD_SERIAL triggering an attempt to use a specific ftdi based
adapter, introduce common target/interface pairs, OOCD_INTERFACE and
OOCD_TARGET, and an override via OOCD_FILE allowing full control.
Further, attempt to connect to a running openocd instance to flash if possible.
This _will not_ work well if you have multiple openocd instances open at once,
but that's a rare use case.
Examples:
OOCD_INTERFACE=stlink-v2
OOCD_TARGET=stm32f0x
--> openocd ... -f interface/stlink-v2.cfg -f target/stm32f0x.cfg)
OOCD_FILE=board/ek-lm4f120xl.cfg
--> openocd ... -f $(OOCD_FILE) (ie, the variable is passed untouched)
As part of implementing this, correct variables that were always wrong, and
update the openocd flashing commands to use current commands.
This brings in the new ADC api for STM32 parts.
Update to new standardized ADC apis.
Drops pointless channel definitions, uses common names for common functions.
No functional changes.
Based on work in: https://github.com/libopencm3/libopencm3-examples/pull/130
Correctly migrate stm32f103_usb_driver to st_usbfs_v1_driver instead of the
f107 driver.
Fixes: 976720c355
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Be specifically careful with the usb examples. There is likely some
breakage to be expected, not sure I updated all the drivers to the
correct types for the respective chips.
As found in 6f2b39c1be6a8b9531264d92138dc2629d51cfa0, you can't just register a
control callback by itself, you can only register them in the set config
callback, (or, at least, _after_ set config has been done.
This has been compile tested only for the extra examples that were found to
have this failing pattern.
This has been broken since f87170e when set config started clearing control
handlers to be re-registered by different configurations.
Fix this example to use a set config callback to setup control transfer
callbacks, just like CDC-ACM demos. With this fix, this demo works with
dfu-tool 0.8
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
While some of the examples include a "board.ld" style file, some of them were
pointing to the libopencm3 provided chip specific ld scripts. When
TOOLCHAIN_DIR has been overridden, those paths were no longer valid/correct.
The Makefile.includes contain a hardcoded ../../../../../libopencm3
path for the TOOLCHAIN_DIR variable. They also contained another copy
of this hardcoded path, that is now generated from $TOOLCHAIN_DIR.
This allows to have a symbolic link to a Makefile.include in an
out-of-tree project and reuse the Makefile infrastructure.
My bad, I'd been testing my header includes against a branch with some
draft unification of the adc code. ADC is one of the remaining major
peripherals that isn't unified neatly.
Replace includes of stm32/YY/xxxx.h with stm32/xxxx.h
Replace stm32/YY/nvic.h with cm3/nvic.h.
In some cases, the include list was resorted alphabetically when it was
complicated and I was reviewing them manually, but most of this was
automatically done.
file.c~ (note the tilde at the end) are temporary backup files used by some
editors. They are not needed.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
