The common code wasn't being included in L1 builds, even though the headers now
included the correct definitions.
This combines the two f0 and f3 spi files, which previously differed only in
the number of spi peripherals defined.
Files were renamed to the full "l1f124" style, not because I like it, but
because it's the convention we have, so it's best to apply it rigourously.
Tested on L1 and F100 boards, compile tested only for others, but the examples
repository all compiles too. (Though the lack of SPI examples for all
platforms was how this broke in the first place)
DFF exists at bit 11 for f1, f2, f4 and l1, but the f0 and f3 have that bit as
CRC len and use CR2 for data size bits instead. The merging of the F3 and F0
and attempts to put common data in common places broke the l1 code.
F3 and F0 SPI headers are still almost completely identical.
use stdint-types, not short types
remove info on file stucture of examples, this was removed some time ago,
add reference to libopencm3-examples instead.
STM32L1 has a different set of offsets, not just a different base
address, so we can't have common registers definitions. Also, out of
F0,F1,F2,F3,F4,L1, only the F1 has the odd note about 2x16bit registers
and 2x32bit registers with one 16bit register marked as "This field
value is also reserved for a future feature." Therefore, replace the
awkward reading out as multiple words and just copy them in.
F0,F2,F3,F4 were missing definitions altogether.
This does _not_ attempt to address the problem of the mismatched base
addresses for Medium+ and High Density L1 parts.
The f103 usb core should be usable on the l1 as well, and the /f1/rcc
isn't explicitly required anymore. This is an important change to be
able to share the driver.
The direct access definitions to the SHPR1 SHPR2 and SHPR3 were simply
wrong, and though a handy macro for directly reaching any priority field
was provided, the definitions of the fields assumed direct access to the
registers.
Provide field definitions that match the handy macro, and correct the
direct access definitions for people wishing to use them.
We currently default to "-mfloat-abi=hard -mfpu=fpv4-sp-d16" for M4F cores, and
and variations of "-mfloat-abi=soft" for the others. Keep the M4F default, and
move others to no FP flags for consistency, but allow overriding these flags
via the FP_FLAGS environment variable.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>