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.
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.
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.
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.
Using the latest (as of today) gcc-arm-embedded toolchain caused two build
failures similar to:
error: unknown type name 'cookie_io_functions_t'
These custom IO functions are now protected by a define, so define _GNU_SOURCE
which enables all such areas. This is a libc issue.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The unique serial number from the device unique signature block was never used
in any examples. Add it to the these two usb midi examples, to have a user for
this api available for reference.
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
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.
This example takes advantage of the big Flash memory space and
uses the standard library functions printf, and fgets to
implement a simple interactive application.
This example is just using buffers and built in alpha overlay
functionality to animate a dmond floating on a checker board. After
initializing of the frame buffers only 7 registers are being modified to
implement the animation.
This version is the ASCII one but uses the LCD display
that is attached to the board for a more colorful result.
This example also zooms into a more "interesting" place in the set so
the display stays interesting during the full 100 generations.
Remove the ISR function and remains of the hack in lcd-spi.c and
convert console.c to use the LOC3 system reset code rather than
the hack which only works on the F4 as it turns out.
Now that I know a bit more about how SPI is working on the STM32F4
I removed the egregious hack and replaced it with some cleaner code
for driving the LCD. On the positive side it gets a faster update
rate on the screen.
