• Stm32f0 Standard Peripheral Library Documentation Form

Stm32f0 Standard Peripheral Library Documentation Form

Microcontroller data sheets (i.e STM32 reference manuals) describe the peripherals exclusively in register notation. Since the programmer must read this very same documentation to know about the peripheral funtions and features before any attempt is made to use it then it seems natural to me to start programming the registers. STM32xxx Library Folder The documentation of STM library is created using DOXIGEN that gives us the advantage to have the manual updated just a new version of the library is released, but in contrast is not present a manual in standard pdf format. The manual is called: stm32f0xxstdperiphlibum.chm Examples Preconfigured environments.

Andrew NeilThere has been a great deal of grief discussed in a great manythreads on both this and the ST forum about problems due to trying touse code written for one version of the ST Standard PeripheralLibrary with a different version. I have also suffered thismyself.Therefore, I thought it might be a good idea to pull this out intoa separate thread, for easy reference.Most of this post originally appeared in this thread:Other examples:The ST Standard Peripheral Library provides a set of functions forhandling the peripherals on the STM32 Cortex-M3 family. Hans-Bernhard BroekerIncluding the sources makes source-level debuggingwork.But isn't necessary to make it work. You just need to have thesources somewhere.

It's not really necessary for your programto have been compiled from them as part of the project.Including the sources, makes sure the source code repository iscompleteOr you can have the source repository elsewhere and achievethe same result. Losing the library repository isn't really any morelikely than losing the repository for the project's main source.Including the sources speeds up any bug fix needed - librarycode isn't spared from bugs.That's rather debatable. If you include the library source inevery single project, you'll have to manually propagate every bug fixto every affected source file in every project. Using an actuallibrary, you'll have to only update one file per project.And you've omitted the primary advantage of using actual librariesthat they were invented for: you don't have to manually configure alist of exactly those module in the library that your projectactually needs.

The linker automatically pulls only the necessaryparts from the library file. Modern linkers may be capable ofremoving unused stuff from the build by themselves - but it's stillwasteful to burden the linker with pointless work like that.All things considered, the usefulness of keeping a library insource form decreases with the number of projects you're using itin. Tamir MichaelAnd you've omitted the primary advantage of using actuallibraries that they were invented for: you don't have to manuallyconfigure a list of exactly those module in the library that yourproject actually needs. The linker automatically pulls only thenecessary parts from the library file. Modern linkers may be capableof removing unused stuff from the build by themselves - but it'sstill wasteful to burden the linker with pointless work likethat.Well, AFAIK this does not really apply to some commercial stuff(TCPNet included.!).

Do this experiment: use 'armar.exe' to expandTCPNet library into its object files. Then, add these object files toa 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 actuallyfine tune what you need, dramatically reducing code/RAMfootprint.

Hans-Bernhard BroekerWell, AFAIK this does not really apply to some commercialstuff (TCPNet included.!). Do this experiment: use 'armar.exe' toexpand TCPNet library into its object files.

Then, add these objectfiles to a project. Can you link the thing with one missing objectfile? No, as far as I have seen!I'm not sure what point you were trying to make there, but I'mquite sure you missed it.Yes, removing one too many object file from the build will breakit.

So what does that have to do with using libraries, which prettymuch by definition don't lack any files? Per Westermark'Or you can have the source repository elsewhere and achieve thesame result. Losing the library repository isn't really any morelikely than losing the repository for the project's main source'Yes it is. And real life have shown it a number of times. Companymergers, sales. Where people extract what they think belongs to aproject while not being allowed to extract everything since that'snot part of the merger/split agreement.

3 years later, they try tobuild - after first spending lots of time figuring out that they nolonger have a compiler license.At other times, the project got moved including the binarylibrary, making it take a number of years before someone realizedthat the library source code wasn't brought too.' Using an actual library, you'll have to only update one file perproject.' 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 onwhat certifications that software requires, the retesting +documentation + third-party code review + recertification can costhundreds or thousands of times more than the cost of manuallyduplicate a bug fix just when needed.Just extracting map file data to prove that the bug fix was in afunction not included by the linker do cost money and time, and mayhave to be done many times. Andrew NeilYes, there are downsides to using the library as sources.Experienced developers should be aware of this, and be able tostructure their projects accordingly.The main problem is that ST provide the 'library' in source formonly, and Keil provide only a grossly out-of-date version of theready-built Library.So, for new & inexperienced users, I think using the sourcesdirectly is the most straightforward approach.' It's not really necessary for your program to have beencompiled from them as part of the project'That, surely, depends on whether the Library was built with Debuginformation?Even if it was, it would require some faffing around to tell thedebugger where to find the sources.'

You can have the source repository elsewhere and achieve thesame result'Not exactly. Having everything in one project folder tree makes ittrivial to just Zip the whole thing and send to a 3rd party - withoutthem needing access to any repository, and without having to givethem instructions on what needs to go where.'

You don't have to manually configure a list of exactly thosemodule in the library that your project actually needs'Yes, that is true.' Modern linkers may be capable of removing unused stuff fromthe build by themselves'From recent discussions on thie forum, it seems that Keilcan't.The granularity of the Library is no better than the granularity ofthe source files.' Wasteful to burden the linker with pointless work'May be true - but unlikely to be significant. The ST library onlyamounts to a couple of dozen files if you include absolutelyeverything. Hans-Bernhard BroekerThat, surely, depends on whether the Library was built withDebug information?Of course.Even if it was, it would require some faffing around to tellthe debugger where to find the sources.Not necessarily.

It's a question of debug info format andorganizaton. Information about source file names and locations can bestored relative to the library build directory, or with absolutepaths. In the latter case all it would take is to have the source inthe same place it was originally built from for the debugger to findit.And then there's the question whether debugging into a librarythat is supposed to have been tested to a point where people can justblindly trust it should occur frequently enough as to warrantstructuring your whole project organization around it.From recent discussions on thie forum, it seems that Keilcan't.The granularity of the Library is no better than the granularity ofthe source files.May be true - but unlikely to be significant. The ST library onlyamounts to a couple of dozen files if you include absolutelyeverything.Those, combined, would indicate a considerable design deficiency.If it's meant for a linker that won't split object files, it's baddesign for the library to be in such big chunks - regardlesswhether it's in source or library form. Development Tools.Hardware & Collateral.Contact.

© 2005-2019 (or its affiliates). All rights reserved.