Remove debug leftovers that were causing memory corruption.
Writes of 64 or more bytes from the USB host side caused memory
corruption before this commit.
I've tested it in a STM32L4 board and it is working as expected.
115200 is a much more sane "default" than 38400.
Instead of a mix of 38400 and 115200, just use 115200 in all places.
There's no reason for modern 32bit cpus to be using such old slow
baudrates.
Tested on f1, f4, l1. Replaced some old f1 code that predated some
library support code for this.
Not strictly required as we're using port A out of the box, but makes
for bad example code, when the syscfg clock is required for selectin
exti sources other than port A.
Fixes: b8b97209 stm32l4: basic uart/exti/led/clock demo
which introduced the l4 example, but left out the makefile.include file
and didn't add it to the root build.
Reported at: 2a7e4fac14
HSI is out of spec for reliable USB operation, even though it sometimes
works. stm32-h103 board has an 8Mhz external crystal which should
therefore be used for any USB work.
Originally reported as https://github.com/libopencm3/libopencm3-examples/pull/192
USB_VBUS is not an alternate function, it is an additionnal function which is
always enabled.
If configured as an alternate function, it will draw current from VBUS.
can fixes are compile tested only. I don't have those boards.
f3 i2c is tested on i2c and gives the same results
l1 low power demo seems to have been broken for some time already.
=> should be fixed, but not something I'm going to work on right now.
The "timer" example is actually "the same" for both f1 and f4. Do a
sanity sweep over the commentary, remove all vestiges that this was
cloned from a motor control example, and synchronize both examples.
Future work should extract the common portions "somewhere" but at least
make them consistent for now.
This example was functionally similar to the "other" example, but had
the actual functional mouse movement disabled. To reduce maintennance
cost with slightly divergent examples, simply drop the less useful
example.
The example is pointlessly complicated and includes lots of dead code,
but at least remove the wasteful and confusing references to the
temperature channel as pointed out on github.
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.
