Because most changes are internal to a function in exti.c I am leaving
the macro checks in there, otherwise we would end up with a bunch of
code duplication if we used the dispatch system used otherwise
throughout the stm32 part of the library. I bet it could be split up
into more granular functions resulting in more generic code that we
could run through the dispatch system. But I am leaving that as an
excersize for later.
We don't support f0 yet so let's not fool anyone. We may rename those
files back again if when we cross check that it is actually true this
file supports f0.
- Additional frequency configuration (48Mhz, for usb use!)
- FLASH latency decreased (too unnecessarily low before)
- Rcc functions to change usb freq prescaler.
- Several functions added (that only work on the f3)
- The data register now has a 8bit access counter part
that is necessary for 8bit transmissions, together with
the access functions.
- The init master functions doesn't work for the f3.
Very few functions can be shared (~ 3). A possible solutions is to move
i2c_common_all to i2c_common_f124, create i2c_common_all and move f3/i2c to i2c_common_f3. Who agrees?
- Makefiles of other stm32s updated accordingly.
- f3/rcc.c updated to some definition changes.
- f3/flash.c removed in order to use flash_common_f234.c to comply with new organization.
- Makefiles now include building f3 src directory.
- Gpio support added. gpio_common_f24 changed to support also f3.
- f3 still not compiling, but f2 compile not broken (probably also f4).
In places where we were defining memory mapped peripheral buffers we
were using directly a cast to "volatile int_type *". For consistency we
should use dereferenced accessor like: &MMIO32(address)
Added --terse and --mailback options to the make stylecheck target. It
also does continue even if it enounters a possible error.
We decided on two exceptions from the linux kernel coding standard:
- Empty wait while loops may end with ; on the same line.
- All blocks after while, if, for have to be in brackets even if they
only contain one statement. Otherwise it is easy to introduce an
error.
Checkpatch needs to be adapted to reflect those changes.
According to the reference manual, you are _forbidden_ from writing 00 to the
VOS[1:0] bits in PWR_CR. Writing a 00 is automatically turned into range 2,
or, 10. Attempting to then |= the bits for range 1 (01) results in the final
result of choosing voltage range 3 (11). This has fairly catastrophic effects
if you then attempt to switch to PLL clock at 32Mhz.
Oddly, the existing code was working fine on STM32L151C6 revision W, but
failing with revision V silicon. Regardless, the existing code was wrong and
not following the reference manual.
Further, attempting to change any power voltage range settings without the RCC
enabled will have no effect, so all the higher level helper routines
have added peripheral enable lines before attempting to set the range.
This switch to HSI was an attempt to run the setup code faster. However,
there's no real need for this, and it just confuses things by switching first
to one clock, and then to another. Just keep running on the existing clock
until switching to the clock actually chosen by the user's arguments.
Added hash processor register definitions and main functions. Hash
processor is supported in stm32f21, stm32f41 and stm32f43 and can be
used to calculate Md5 and Sha1.
