2
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ GPIO also frequently require some pin muxing setup, as well as maybe clocks. \$\endgroup\$ – Sean Houlihane Mar 23 '17 at 18:28
1
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ The SPL is no longer supported (and not available for newer devices), but ST is working on a low level Cube HAL to replace the SPL for those who need to work closer with the hardware. \$\endgroup\$ – Arsenal Mar 23 '17 at 19:30
5
\$\begingroup\$

No. GPIO are an external peripheral to the core and as such have no standardized register layout or specification. CMSIS just handles the core and the core peripherals which are standardized by ARM.

Usually (these days) the vendors are providing a hardware abstraction layer specific to their models.

For the STM32 ST provides the Cube environment. I can't really tell you much about it because we don't use it in our products, so I didn't have time to mess around with it yet.

If you go down the route we did (bare metal, own HAL) you have to have a look at the reference manual of your specific device, the errata sheet to tell you if you need to handle some hardware bugs in software and the data sheet for pin mappings and other electrical data.

The headers for the peripherals are often provided by the compiler company and not by the chip manufacturer (or at least you don't notice it because they come packed with the compiler). Usually the headers are closely following the naming scheme of the reference manual. Some use a structure for one peripheral others are defining each register as an own. The bits are also usually predefined, so you can write readable code without shifting bits around like crazy.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.