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.
And you've omitted the primary advantage of using actual libraries that they were invented for: you don't have to manually configure a list of exactly those module in the library that your project actually needs. The linker automatically pulls only the necessary parts from the library file. Modern linkers may be capable of removing unused stuff from the build by themselves --- but it's still wasteful to burden the linker with pointless work like that.
Well, AFAIK this does not _really_ apply to some commercial stuff (TCPNet included...!). Do this experiment: use "armar.exe" to expand TCPNet library into its object files. Then, add these object files to a project. Can you link the thing with one missing object file? No, as far as I have seen! If you use a open source system like uIP, lwIP etc. you can actually fine tune what you need, dramatically reducing code/RAM footprint.
Well, AFAIK this does not _really_ apply to some commercial stuff (TCPNet included...!). Do this experiment: use "armar.exe" to expand TCPNet library into its object files. Then, add these object files to a project. Can you link the thing with one missing object file? No, as far as I have seen!
I'm not sure what point you were trying to make there, but I'm quite sure you missed it.
Yes, removing one too many object file from the build will break it. So what does that have to do with using libraries, which pretty much by definition don't lack any files?
I was trying to demonstrate why I think using a library like TCPNet incurs a large footprint (even if you have the source...). There seem to be significant inter-dependencies there that make the whole thing bloated beyond belief (it may have changed in the mean time, but I doubt it!).