libopenstm32 - a Free Software firmware library for STM32 ARM Cortex-M3 microcontrollers

Olimex STM32-H103 eval board

I guess it's time to finally announce libopenstm32, a Free Software firmware library for STM32 ARM Cortex-M3 microcontrollers me and a few other people have been working on in recent weeks. The library is licensed under the GNU GPL, version 3 or later (yes, that's an intentional decision after some discussions we had).

The code is available via git:

 $ git clone git://
 $ cd libopenstm32
 $ make

Building is done using a standard ARM gcc cross-compiler (arm-elf or arm-none-eabi for instance), see the summon-arm-toolchain script for the basic idea about how to build one.

The current status of the library is listed in the wiki. In short: some parts of GPIOs, UART, I2C, SPI, RCC, Timers and some other basic stuff works and has register definitions (and some convenience functions, but not too many, yet). We're working on adding support for more subsystems, any help with this is highly welcome of course! Luckily ARM stuff (and especially the STM32) has pretty good (and freely available) datasheets.

We have a few simple example programs, e.g. for the Olimex STM32-H103 eval board (see photo). JTAG flashing can be done using OpenOCD, for example.

Feel free to join the mailing lists and/or the #libopenstm32 IRC channel on Freenode.

The current list of projects where we plan to use this library is Open-BLDC (an Open Hardware / Free Software brushless motor controller project by Piotr Esden-Tempski), openmulticopter (an Open Hardware / Free Software quadrocopter/UAV project), openbiosprog (an Open Hardware / Free Software BIOS chip flash programmer I'm in the process of designing using gEDA/PCB), and probably a few more.

If you plan to work on any new (or existing) microcontroller hardware- or software-projects involving an STM32 microcontroller, please consider using libopenstm32 (it's the only Free Software library for this microcontroller family I know of) and help us make it better and more complete. Thanks!


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

GNU STM32 Development

Hi All,

Just dropping a link to a website I have been writing articles for to help people get started with the STM32 using GNU tools. Includes a free skeleton project ready to go once a cross-compiler is installed, and articles on how to use FreeRTOS. There is much more to come, I will be adding as much information as I can so as to centralize it for hobbyists who are looking to break into the STM32.

Fantastic Project

Thank you so much for this project. I have been using it for several projects, and recently discovered just how nice it is. Setting up a serial port is elegant and readable and the same goes for the SPI code. Much better than the ST libraries. Once again thank you.


Great, I'm glad you liked it. If there are any issues or feature requests please let us know on the mailing list. Thanks!

cortex-m3 libraries

[3 months later...]

I was just looking at and lamenting the lack of an open, cohesive, basic hardware peripheral library for cortex-m3 devices; hackers won't write awesome application libraries if they aren't portable at least across a couple manufacturers. For our open hardware development platform (maple) we wrote our own low level library called libmaple (plus libc and newlib of course). It was a lot of work and it would be a shame for others to have to repeat it, but it wasn't designed from the beginning to be portable. Something like CMSIS would go a long ways... I think GPL vs. LGPL/MIT would turn a lot of people away though.



hello Uwe

Thanks for your work on this. I've created a tool chain using your script. I ran your usart example and all works ok except that the baud rate is twice the expected rate. It is not the baud calculation, as I put in the raw value and it still operates at e.g. 19200 when 9600 is selected. I will probably use and maybe add to your library.

Many thanks

Baudrate bug


thanks for testing! This is a small bug in the clock setup I think, will investigate.


Baudate calculation buggy?

I started using your library today for a few experiments. I like the project and how it is done. It feels much cleaner then the STM stuff.
I am using a STM32F103R Processor for my tests and it looks like the UART baud rate problem is still present.
I can see in the Terminal that the processor send data but the baud rate is off so my data is converted to chinese.
I compare the setup with the STM stuff and it looks like STM is using a different clock value for the setup.
The clock used in the STM32 lib is 2800000 and for cm3lib 7200000.

I also think it has something to do with the PLL setup sofar I could not figure out what is going wrong.
Does anybody out there having the same problem? and maybe solved it already?


Duplication of CMSIS?

Uwe, how is this library (or is intended to be) different from CMSIS? I cloned your repository and did a quick scan of the headers, and it appears to duplicate it all. By using the CMSIS you are even portable between different Cortex-M3 vendors, and I don't see anything STM32-specific in your library.

Duplication? Yes, indeed.

Duplication? Yes, indeed. However, there is no way around that. The CMSIS license (as well as the license of the proprietary ST STM32 firmware lib) is not even remotely what I would call Free Software / Open Source. One of the CMSIS files (Core/CM3/system_lm3s.c) even says "You may not combine this software with "viral" open-source software in order to form a larger program." and other totally unacceptable stuff. The main core_cm3.h just says "for use with Cortex-Mx processor based microcontrollers" and "This file can be freely distributed within development tools that are supporting such ARM based processors." It does not allow you to distribute it outside of devel tools, it does not allow modifications etc. etc.

On a slightly related note, what we _might_ do is split out the generic Cortex-M3 stuff into a common lib and the STM32 specific stuff, so that later support for other Cortex-M3 microcontrollers from other vendors can be added easily.


LGPL instead of GPL?

I was not aware of the strict licensing terms of the CMSIS, thank you for starting the openstm32 project. Have you considered using the LGPL license instead of the GPL? This move would make the library much more useful for developers like me that are working on both open source and closed source projects.

Usually I can talk my clients into releasing source code for generic library functions, but they will normally resist releasing all source code as GPL.

Thank you for your nice work

It's not totally CMSIS

It's not totally CMSIS strict licensing - simply with distribution of program with CMSIS library code and GPL code one must provide whole source with GPL license. If anybody cares CMSIS should be dual/multi license, but it's too small piece of code to really care.


We're aware of the issues, both licenses have their advantages and disadvantages. Multiple of the contributors (including myself) do want to enforce changes to the lib itself as well as the software using the lib to be GPL'd, though. We basically agree with the reasoning explained in more detail at Why you shouldn't use the Lesser GPL for your next library.

If the fact that libopenstm32 is GPL'd helps to open-source only a single otherwise commerical or proprietary project (so that the project can use libopenstm32) this decision has already proven very useful.

Also, if the lib gets used in embedded (commercial / closed) devices and products later and we find out that libopenstm32 was used, we can enforce the release of the whole firmware for such devices (even in court, if necessary), just as Harald Welte of has done multiple time in the past using GPL'd code in netfilter in the Linux kernel. Using the LGPL would not allow us to do that.

Hope that explains, Uwe.

But on the other hand it may

But on the other hand it may cause many prioprietary projects to not use libopenstm32. And this leads to lack of users and bug reports, thus slowing development.

But on the other other hand it may

But on the other other hand it may motivate developers/companies to use the open-source model.

Forcing opensource

Yes, it explains a lot. I understand that there is no point in becoming familiar with library, if i can not use it in closed source project. So rather than forcing someone to realease code, you will simply has only opensource user forever.

Yes totally agree with decision to go GPL3

Who cares about if a closed source developer uses the library ? By definition they won't be putting anything back into the project. Let them whine as much as they want. We are already starting to see the deficiencies in the STM offering (for instance vendor tie in). Let the closed source software developers create there own libraries. When it comes to embedded software most are already getting a free ride by the use of GCC.

I care

>> Who cares about if a closed source developer uses the library ? By definition they won't be putting anything back into the project.

Huh ?
I completely agree with Peter Stuge, this is quite insulting.

As many people here, i develop microcontroller source code for both FOSS projects and proprietary projects.
Being able to use a FOSS library for proprietary projects would give a big advantage to a library like STM32.

And a big, corporate backed user base should not be neglected. You state it won't be putting anything back to the project, this is complete nonsense.
Just a little example : Typically, a microcontroller project passes very stringent code audits, because it's critical code that has to run 24/365 without user interaction. Crashes are not allowed. often, physical security is involved when doing machine control.
- If the lib is LGPL, the benefits of this company backed work goes to the project.
- If the lib is BSD, the benefits of this company backed work may go to the project.
- If the lib is GPL, the company cannot use the lib, coz the application code will not be released. (HW companies don't have open source management)

I currently work for a big (40 000 employees) HW company, which uses diverse FOSS softwares.
On a big controller with a linux OS, you can use GPL code together with proprietary stuff, if they run in separate processes with well documented interfaces. A nice way to do.
On a small microcontroller without an OS, or with an small embedded OS, you simply can't do that. You either go all prorietary, or all FOSS. As mentionned, HW companies go proprietary. All HW companies i saw up to now went proprietary because of that detail !

In my opinion, and in a lot of other embedded SW devs, GPL libraries are simply not fit for small micros.

Closed source developers can certainly contribute


You write "By definition they [closed source developers] won't be putting anything back into the project." and I think you are confusing two different things.

I am an avid open source developer and like most other developers I also do significant amount of closed source development. You are really insulting me when you assume that I would not contribute to the library because a project in which the library would be used is closed source. That is very much backwards.

You should really consider that there are two completely separate bodies of code. I absolutely respect the libopenstm32 authors' choice of GPL3+, but it does mean that I am unable to use the library in some cases. In some, perhaps most, of those cases I would be adding features, bug reports and bug fixes to the library because I needed them. Until the library becomes feature complete all contributions are of course welcome. Unfortunately some contributions can not happen because of the chosen license, so development of the library will take a bit longer.

I think the license choice tradeoff is obvious; a GPL library actively works against any software in the world being closed source (IMO somewhat naive and rather impractical) vs. a LGPL library permitting closed source use but ensuring a much greater ability of the library to gain contributions ie. reaching finished state quicker.

Both choices are equally good and valid. Personally I just prefer LGPL for libraries.

Kind regards