The SPI br parameter has always been the 3 bit fpclk divider field, and
was never a target or explicit bit rate. Correct the comments, and drop
the duplicate commentary that wasn't included in the doxygen output
anyway.
Fixes: a7a3770d Add initial SPI code
Until https://github.com/libopencm3/libopencm3/issues/732 has been
fixed, it's not enough to just have it in the README that you need GNU
awk. Explicitly use the "gawk" command name. This exists on (sane)
systems that have gawk as awk, and for systems that use mawk as default,
the gawk name should also exist.
This should make it significantly easier to diagnost the cause of build
problems.
Final chunk of register definitions to be pulled up.
Now the "target" files are _only_ defining the list of u(s)arts
available, and any _specific_ functions for that target.
Just small pieces at a time to make it easy to see what's happening.
Taking definitions currently implemented in both f0/f3 headers and
making combined, documented versions in the -v2 header.
Use the usart-common base plus the usart-v2 code, instead of private
implementations. Less code, more common apis across targets.
Of note is the trick to make F0 look like it has an APB2 bus. It's the
only stm32 that doesn't have a documented APB2 bus, but still has
peripherals enabled via an "APB2" register, and they match how other
targets have an APB2. Simply make APB2 an alias of APB1, as it's only
used for clock speed detection.
Instead of declaring that _every_ device has USART1,2,3 and UART4,5, let
the targets themselves define what periphs they do, along with their
USARTx_BASE defines, and let the common headers just have the common
abstractions.
This function was using apb1 for quite a few families instead of apb2.
This only mattered for L1 and F3, and for USART1/USART6, and only if
apb1 speed != apb2 speed.
Instead of using families explicitly, just check for the peripherals
themselves. On F0,F1,F2,F3,F4,F7,H7,L0,L1,L4, usart1/6 are _always_ in
the rcc_apb2 register and the other uarts are all on apb1.
(F0 doesn't actually _have_ apb2, but it's still called the apb2
register)
Similar to how we have abstract defines for the stop bits, parity and
flow control common mode namees, provide abstract flag names for the
"standard" flags. This allows us to start using common API code for v1
and v2 uarts
For stm32f3, drop the "compatibility" defines that simply pollute the
namespace, making it confusingly appear as if f3 has both SR and ISR
registers.
Only pulling out the _common_ stuff. This is a single step in a long
process of eliminating all the duplication and "same, but different"
implementations that are stalling adding nice clean easy support for
l0/f7/l4.
This _ignores_ all currently conflict register definitions, even if they
"do the same thing" it just pulls up the common stuff. A subsequent
commit can look at resolving the implementatations to a single version.
Even if they haven't been referenced from a .c file. Some peripherals
start their life as register definitions only, and they should still
have the documentation generated.
There _will_ be overlap in the generated lists, but doxygen doesn't seem
to mind this.
The ADVANCED_TIMERS define/check was added in 523943a as part of adding L1
support. The runtime checks against TIM1/TIM8 already existed. Since L1
doesn't have TIM1/TIM8, those names are undefined, resulting in a compilation
error until ifdeffed out.
Since I throw out all TIM1/TIM8 checks, there's no references to those names
left, thus no need to keep the ifdef either.
As for the registers themselves, l1/timer.h pulls in common/timer_common_all.h
which defines macros for the superset of all timers, so e.g. TIM_BDTR() is
still available regardless of whether or not the particular chip we're building
for has any timers with a BDTR register.
Instead of expecting a posix-ish "find" in the shell, simply leverage
our knowledge of our source structure to make a single list using make's
builtin wildcard() functionality.
Fixes https://github.com/libopencm3/libopencm3/issues/828
Instead of the fragile and error prone attempts to specifically
include/exclude files from doxygen by name and pattern, simply use the
already generated .d files to provide accurate and up to date lists of
all source files used.
Pros:
* Nothing left to worry about
* Much more encouraging to actually _work_ on the documentation now that
you can be sure the right docs will be generated instead of a confusing
mix.
Downsides/Upsides:
* Automatically includes all CM3/USB in each device's page _as well_ now
Downsides:
* lpc43xx still manually listed. However, completely contained in it's
own dir, so no problems
* No attempt to carry this in latex. easy, but more tempted to drop
latex support outright. (I don't think the generation there has even
worked for a while now)
* Due to the mismatch between lib directories and document roots, the
sourcelist can't be magically created per directory. There has to be
some sort of mapping between the two, so as this is doc generation only,
a static list seems sane for maintennance. (Especially compared to the
old method)
* Source list generation probably doesn't work on windows.
Very new gcc versions add a warning on switch cases that fall through.
While there's an option that accepts any comment as explaining it, it's
easier in our case to just use one of the "blessed" comments. We can't
use the [[]] attributes for standards code, and the gcc specific
attributes are worse than the comments. This has no functional change
whatsoever.
WGH