Keil Logo Arm Logo

STM32: Using the ST Standard Peripheral Library with Keil

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details Message
Read-Only
Author
Andrew Neil
Posted
23-Sep-2011 13:43 GMT
Toolset
ARM
New! STM32: Using the ST Standard Peripheral Library with Keil

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:
http://www.keil.com/support/man/docs/uv4/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.

Read-Only
Author
erik malund
Posted
23-Sep-2011 18:22 GMT
Toolset
ARM
New! in the 3 large professional cases

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:

in the 3 large professional cases have been involved with (coming in "after the fact") it was done that way.

thus it seem that the most experienced users do so. I definitely would.

Erik

Read-Only
Author
Per Westermark
Posted
23-Sep-2011 18:56 GMT
Toolset
ARM
New! RE: in the 3 large professional cases

Including the sources makes source-level debugging work.

Including the sources, makes sure the source code repository is complete - no sudden oops 5 years later when the project have been using a precompiled library and a compiler change made that library unusable.

Including the sources speeds up any bug fix needed - library code isn't spared from bugs.

Including the sources means there will be source repository tags in the library code too, allowing a diff command to see all changes between to application versions - including the updates to the library.

Locking library source to application source means that the application doesn't need a full retesting if there is a library update. Unless there is a known problem, the application can continue using an older version of the library code.

Must be more advantages too.

The only real disadvantage is that when a new library is received, the changes must be distributed to all projects using the library - but that can be done first when a new version needs to be produced.

Read-Only
Author
Andrew Neil
Posted
23-Sep-2011 19:10 GMT
Toolset
ARM
New! RE: Must be more advantages too

The ST documentation is, well, not always that great. I have had cases where I needed to be able to step into ST library functions to see what was really going on...

Read-Only
Author
Andrew Neil
Posted
23-Sep-2011 19:39 GMT
Toolset
ARM
New! Keil include a version of the ST Standard Peripheral Library ... almost certainly not the latest

I've just downloaded the latest Eval (MDK v4.22) to check:

The supplied ST Library is v2.0.1, dated 2008 - so that is very long out-of-date indeed!!

Read-Only
Author
Per Westermark
Posted
23-Sep-2011 22:29 GMT
Toolset
ARM
New! Old library costs money

Sounds like someone at Keil should be taken by the ear, then.

Releasing the compiler with a library from 2008, that differs a lot from the current, costs Keil's customers huge amount of money and time.

Most probably, Keil uses the old library to avoid having to update their examples. Instead, every customer has to do that work. Again. And again. And again.

Read-Only
Author
Andrew Neil
Posted
24-Sep-2011 08:46 GMT
Toolset
ARM
New! RE: Old library costs money

"Sounds like someone at Keil should be taken by the ear, then."

Indeed!

"...costs Keil's customers huge amount of money and time"

As can be seen from the posts both here & on the ST forum.

It also hurts ST's customers - at least one recently said he was abandoning the STM32 because of this!

"Most probably, Keil uses the old library to avoid having to update their examples"

I don't think Keil's own examples use the library...?

Read-Only
Author
real code Zeusti
Posted
24-Sep-2011 09:00 GMT
Toolset
ARM
New! RE: Old library costs money

<quote>at least one recently said he was abandoning the STM32 because of this!<\quote>

no staminer?

always yo're freind.

Zeusti.

Read-Only
Author
Andrew Neil
Posted
24-Sep-2011 09:36 GMT
Toolset
ARM
New! RE: No stamina

Yes, I think so.

Perhaps it's a cunning ploy to weed-out the lightweights who are just going to be a burden on support...?

But I think it backfires in just generating a load of unnecessary work for support!

Read-Only
Author
Andrew Neil
Posted
24-Sep-2011 11:51 GMT
Toolset
ARM
New! RE: If you wish, you could make a separate Group for the ST files

That is, in fact, exactly what the Template project provided by ST does!

Read-Only
Author
Hans-Bernhard Broeker
Posted
24-Sep-2011 12:29 GMT
Toolset
ARM
New! RE: in the 3 large professional cases

Including the sources makes source-level debugging work.

But isn't necessary to make it work. You just need to have the sources somewhere. It's not really necessary for your program to have been compiled from them as part of the project.

Including the sources, makes sure the source code repository is complete

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.

Including the sources speeds up any bug fix needed - library code isn't spared from bugs.

That's rather debatable. If you include the library source in every single project, you'll have to manually propagate every bug fix to every affected source file in every project. Using an actual library, you'll have to only update one file per project.

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.

All things considered, the usefulness of keeping a library in source form decreases with the number of projects you're using it in.

Read-Only
Author
Tamir Michael
Posted
24-Sep-2011 12:52 GMT
Toolset
ARM
New! RE: in the 3 large professional cases

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.

Read-Only
Author
Hans-Bernhard Broeker
Posted
24-Sep-2011 15:17 GMT
Toolset
ARM
New! RE: in the 3 large professional cases

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?

Read-Only
Author
Tamir Michael
Posted
24-Sep-2011 15:25 GMT
Toolset
ARM
New! RE: in the 3 large professional cases

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!).

Read-Only
Author
Per Westermark
Posted
24-Sep-2011 12:54 GMT
Toolset
ARM
New! RE: in the 3 large professional cases

"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.

Read-Only
Author
Andrew Neil
Posted
24-Sep-2011 13:56 GMT
Toolset
ARM
New! RE: Disabvantages

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.

Read-Only
Author
Hans-Bernhard Broeker
Posted
24-Sep-2011 15:08 GMT
Toolset
ARM
New! RE: Disabvantages

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.

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Keil logo

Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings