When is STM32 Standard peripheral library v3.6.1 going to be released?

[chmorgan]

Posted on May 10, 2013 at 20:58

The latest released version of the standalone stm32 standard peripheral library is v3.5.0 but the version inside of the usb device driver download is v3.6.1. This has a handful of useful bug fixes.

ST, are there plans to release a newer standalone standard peripheral library in the near future?Chris #stm32-standard-peripheral-librar

[Tesla DeLorean]

Posted on May 11, 2013 at 14:52

This is fairly common practice by ST, what's the problem of using the 3.6.1?

Archive it within your source repository if your build process is tied to a specific version. It's also not unreasonable to fix bugs in ones own local copy of the source. Or stick to older releases with known/tested behaviour.

[chmorgan]

Posted on May 11, 2013 at 16:28

Hi.

Certainly its possible to build your own packages. In this case I'd have to pull out the cmsis and the std library implementation into its own area, or use them from inside of the usb drivers directory layout. Either one involves some level of effort.Do you know if the license on the usb drivers and std perhipheral library would let me push the work to github? I wouldn't mind splitting things out but it would be nice if I could save someone else the effort of having to do so. I was thinking something that had cmsis, each cpu's std library and the usb lib.Chris

[Tesla DeLorean]

Posted on May 11, 2013 at 17:52

I don't work for ST, so can't represent their position, and I am not a lawyer, but I perceive it as fairly tolerant. A search on library components show they exist with some proliferation on Google Code, github, pudn, and other places. I know that I have posted library source mashed up with other example code, where I have cherry picked newer library source from assorted releases. On the scale of things it's not much work, especially if you have a half decent file manager, and merge/compare/diff tools. I also push bug fixes and code examples down stream to my customers.

What likely wouldn't be tolerated would be melding the libraries to NXP or TI parts, for instance. The staff behind the libraries is also fairly shallow, things likely get addressed when needed, and too pave the way for newer chips or integration across chip families. A lot of effort currently is presumed to be focused on the F429 families, and the expansion of those new features, rather than the somewhat dated/mature F1xx parts.