Electronic – Do CMSIS libraries also handle GPIO registers

armembeddedmicrocontrollerstm32

I'm currently exploring embedded programming with ARM processors. My embedded systems class has us programming on an Atmel SAMD20 (Cortex M0+). Our lab manual explains in detail how to utilize an Atmel library to access the registers on the processor to control GPIO pins.

What I've been trying to learn on my spare time is how to get up and running on my own with a different microcontroller, knowing that the code will be somewhat different. I read about CMSIS which seems like a convenient way to start programming on new microcontrollers using the same ARM core. However, different silicon vendors will have a different number of GPIO ports/peripherals connected to the microcontroller. How can CMSIS keep consistency between these GPIO ports when they are different between different chips? Or does CMSIS not handle GPIO ports and only things pertaining to the ARM Core?

If the latter is the case, does this mean I must look at vendor datasheets to understand how to code a specific microcontroller? I am looking at STM32 microcontrollers at the moment and am having trouble locating anything that documents their header files. I am a little lost and overwhelmed at the moment, so any advice and direction would be appreciated.

Best Answer

As @Arsenal says, the CMSIS only handles core ARM functionality. The GPIO is implemented by the specific microcontroller vendors.

The STM32 microcontrollers have pretty good documentation. ST gives a few options for device header files, CMSIS headers, abstraction layers, and so on.

I recommend downloading ST's Standard Peripheral Libraries. The SPL for the STM32F10x, for example, can be found here. It includes a large, Doxygen-created, linked document covering their header files, and also many pieces of example code.

I should explain that the SPL is the "old way" of doing this. It is pretty lightweight, and only performs basic functions to use the hardware.

Recently, ST is nudging users towards their STM32Cube firmware development package instead of the SPL. Not only does it have header files and basic functions, but it also includes USB support, graphics modules, etc. It creates lot of code for you.

Some people love it; some stubbornly keep using the SPL. (I'm one of the stubborn ones). If you want it, you can find STM32Cube (for the STM32F1's) here.