5
\$\begingroup\$

I recently purchased a STM32F4 board to learn the ARM architecture. I am fairly comfortable with embedded programming having worked with AVR series for about a year.

I was going through this tutorial at here

In this the author has mentioned that usually in the ARM boards world, you have 2 set of libraries:

  1. Cortex M Software Interface Standard (CMSIS) - general HAL layer/interface for Cortex M specific features
  2. STM32 libraries - specifically for the onboard peripherals on the STM development board (I2C, SPI, CAN etc)

The author also mentions that just like any HAL layer, the purpose of these is for one to quickly develop rather than waste time on setting things up.

Coming from AVR side where I am using minimal/no libraries and setting up everything by hand (for example spi configuration, rx and tx interrupt driven functions etc) I find this bit strange. By using the STM specific libraries, wouldn't one be constricted to using their microcontrollers only? Then in future if I use some other vendors chip, I'll have to learn to use their specific library

I would like to get an opinion that if this is the right way to go. Being new to ARM should I just use these libraries for now till I become more comfortable or should I from the start get into the habit of doing everything myself?

The idea is to lean ARM independently of any vendor specific board or microcontroller.

\$\endgroup\$

3 Answers 3

Reset to default
3
\$\begingroup\$

I strongly recommend the libraries. A big advantage of cortex M is to be able to easily move your code to other members of the same family (i.e. STMF0 to STMF4), or even to different manufacturers, and you lose this advantage if you don't use the libraries.

BTW, many vendor specific libraries are CMSIS compliant.

I've avoided families that don't supply CMSIS compliant libraries. Also, I've not tried STM Cube for much the same reasons.

\$\endgroup\$
6
  • \$\begingroup\$ so basically the vendors have an option of making their libraries CMSIS compliant? What is confusing me is the fact that as mentioned in case of STM you have the CMSIS part (which could be the same across different vendors if they chose to be CMSIS compliant as you said) but then there is the STM specific libraries (for peripherals) which I presume would be different across different vendors. correct? If I understood it correctly CMSIS library provides the HAL layer for the core functionality and the vendor specific one access to the peripherals that the vendor has included in his board \$\endgroup\$
    – Ankit
    May 25, 2015 at 6:16
  • \$\begingroup\$ No, there is a core, and there's probably some vendor specifics in that, too - but peripheral libraries can be CMSIS compliant as well STM peripheral libraries are compliant, but not cube. \$\endgroup\$
    – Scott Seidman
    May 25, 2015 at 13:39
  • \$\begingroup\$ So basically the CMSIS deals with the core functionality. Since the vendor has licensed the core from ARM, CMSIS would be pretty much the same across all vendors (though it could have some vendor specific customizations). The peripheral library is more likely to be different across vendors as they may be using specific peripherals of their choice. \$\endgroup\$
    – Ankit
    May 25, 2015 at 13:43
  • \$\begingroup\$ No, the CMSIS handles the core and peripherals. \$\endgroup\$
    – Scott Seidman
    May 25, 2015 at 14:28
  • \$\begingroup\$ keil.com/pack/doc/CMSIS/General/html/index.html \$\endgroup\$
    – Scott Seidman
    May 25, 2015 at 14:29
3
\$\begingroup\$

I agree with Scott and the statement "the purpose of these is for one to quickly develop rather than waste time on setting things up."

It ultimately depends on what you mean by learning ARM. Usage of the libraries does not prevent you from going under the hood and writing your own drivers, but the STM32F4 (which I have just started using) is just 1 of over 2000 processors from 16 manufacturers using the ARM core.

For me the drivers offer the flexibility to develop without getting bogged down in details. It does not mean I do not look at the details or attempt to tweak them.

To migrate to another processor with compatible peripherals should just involve switching drivers.

\$\endgroup\$
2
  • \$\begingroup\$ Thank you for the helpful answer. May I ask what IDE are you using? There are so many of them \$\endgroup\$
    – Ankit
    May 24, 2015 at 17:28
  • \$\begingroup\$ I'm using Keil uVision5. \$\endgroup\$
    – StainlessSteelRat
    May 24, 2015 at 18:08
1
\$\begingroup\$

If I were you, I would use the vendor specific peripheral libraries. It takes a lot of time, to look after the registers for configuring the peripherals. I would say, it takes much more time, than learning usage of other vendors libraries. They are quite similar, so it doesn't need much time, to learn using an other microcontrollers library.

On the other hand you can find much more tutorials and support for the peripheral libraries, because they are more widely used.

\$\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.