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.
Yes, there are downsides to using the library as sources.
Experienced developers should be aware of this, and be able to structure their projects accordingly.
The main problem is that ST provide the "library" in source form only, and Keil provide only a grossly out-of-date version of the ready-built Library.
So, for new & inexperienced users, I think using the sources directly is the most straightforward approach.
"It's not really necessary for your program to have been compiled from them as part of the project"
That, surely, depends on whether the Library was built with Debug information? Even if it was, it would require some faffing around to tell the debugger where to find the sources.
"you can have the source repository elsewhere and achieve the same result"
Not exactly. Having everything in one project folder tree makes it trivial to just Zip the whole thing and send to a 3rd party - without them needing access to any repository, and without having to give them instructions on what needs to go where.
"you don't have to manually configure a list of exactly those module in the library that your project actually needs"
Yes, that is true.
"Modern linkers may be capable of removing unused stuff from the build by themselves"
From recent discussions on thie forum, it seems that Keil can't. The granularity of the Library is no better than the granularity of the source files.
"wasteful to burden the linker with pointless work"
May be true - but unlikely to be significant. The ST library only amounts to a couple of dozen files if you include absolutely everything.
That, surely, depends on whether the Library was built with Debug information?
Of course.
Even if it was, it would require some faffing around to tell the debugger where to find the sources.
Not necessarily. It's a question of debug info format and organizaton. Information about source file names and locations can be stored relative to the library build directory, or with absolute paths. In the latter case all it would take is to have the source in the same place it was originally built from for the debugger to find it.
And then there's the question whether debugging into a library that is supposed to have been tested to a point where people can just blindly trust it should occur frequently enough as to warrant structuring your whole project organization around it.
From recent discussions on thie forum, it seems that Keil can't. The granularity of the Library is no better than the granularity of the source files. [...] May be true - but unlikely to be significant. The ST library only amounts to a couple of dozen files if you include absolutely everything.
Those, combined, would indicate a considerable design deficiency. If it's meant for a linker that won't split object files, it's bad design for the library to be in such big chunks --- regardless whether it's in source or library form.