There has been a great deal of grief discussed in a great many threads on both this and the ST forum about problems due to trying to use code written for one version of the ST Standard Peripheral Library with a different version. I have also suffered this myself.
Therefore, I thought it might be a good idea to pull this out into a separate thread, for easy reference.
Most of this post originally appeared in this thread: http://www.keil.com/forum/19587/ Other examples: http://www.keil.com/forum/19540/ http://www.keil.com/forum/docs/thread19482.asp
The ST Standard Peripheral Library provides a set of functions for handling the peripherals on the STM32 Cortex-M3 family. The idea is to save the user (the new user, in particular) having to deal directly with the registers.
This is now a common practice among Cortex-M3 manufacturers (and others).
Keil include a version of the ST Standard Peripheral Library with both source & pre-built library as a standard part of the ARM toolset:
Source: Keil\ARM\Examples\ST\STM32F10xFWLib
Library: Keil\ARM\RVxx\LIB\ST
However, note that this is almost certainly not the latest version; therefore it will not work with current examples on the ST site - or any other code written with any other library version.
AFAIK, ST only provide their "library" as source - not as a true, ready-built Library.
Therefore, my recommendation is that you include the necessary source files from the appropriate "library" version in your Project, and build them as part of the project.
If you wish, you could make a separate Group for the ST files: www.keil.com/.../uv4_ca_create_file_groups.htm
This also has the advantage of giving you source-level debugging in the "library" functions.
To avoid any risk of confusion, I would delete the ready-built Library & sources from the Keil installation.
"Or you can have the source repository elsewhere and achieve the same result. Losing the library repository isn't really any more likely than losing the repository for the project's main source"
Yes it is. And real life have shown it a number of times. Company mergers, sales, ... where people extract what they think belongs to a project while not being allowed to extract everything since that's not part of the merger/split agreement. 3 years later, they try to build - after first spending lots of time figuring out that they no longer have a compiler license.
At other times, the project got moved including the binary library, making it take a number of years before someone realized that the library source code wasn't brought too.
"Using an actual library, you'll have to only update one file per project."
Sounds good, but isn't always good. If you do include a bug fix, then the project using the library needs to be retested. Depending on what certifications that software requires, the retesting + documentation + third-party code review + recertification can cost hundreds or thousands of times more than the cost of manually duplicate a bug fix just when needed.
Just extracting map file data to prove that the bug fix was in a function not included by the linker do cost money and time, and may have to be done many times.