Personally, I have experience on 8-bit and 16-bit architectures (such as Atmel or Microchip) and now I would like to continue with 32-bit ARM Cortex-M family. I wanted to learn the internals of Cortex-M architecture and how to flash/program it.

According to my fast and superficial searches, it seems there are CMSIS libraries provided by ARM's itself to remove manufacture dependency. However, I also saw some extra hardware abstraction libraries in some manufacturer's website.

Trying to figure out from where should I start to work but it I'm a bit confused.

I actually do not want to be a manufacturer dependent when I'm developing software for Cortex-M family since the internals of the chip would be fairly similar for each manufacturer (so is it?). I believe I can read and find the differences of an MCU which is using Cortex-M3 core by looking the datasheet provided by manufacturer and can write code with CMSIS libraries (so can I?)

So, my questions are;

  1. Is it possible to develop a firmware for Cortex-M family by just using CMSIS libraries (and using manufacturer's datasheet to figure out chip's internals)? If I want to change manufacturer (without changing the Cortex-M core), will it be a headache to adapt the code for a the chip by using CMSIS libraries?
  2. For changing the manufacturer and deciding for a new chip, will it be another headache? Imagine you're all adopted your both hardware and software work environment for Microchip family and you're migrating your applications to Atmel family (learning new libraries, code syntaxes, IDEs, programmers, debuggers etc..). Sometimes you have to change even the OS that you're using just to use some suitable debugger or programmer interfaces. Will it be same?
  3. If it is a headache to change the manufacturer, what are the tradeoffs of selecting manufacturer at the beginning? (Actually, how could it differ in 2 different chips from 2 different manufacturers while the core is still Cortex-M3?)
  4. Do you have any suggestion for where to start? (Readings, evaluation kits, debuggers, programmers etc. Everything that is needed to bring up a Cortex-M family.)

Thanks in advance.


closed as too broad by Dmitry Grigoryev, laptop2d, Autistic, ThreePhaseEel, uint128_t Jan 22 '17 at 3:06

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


"I wanted to learn the internals of Cortex-M architecture"

a mcu has two parts in it, the core (ARM) and the peripherals (vendor specific). To use a chip, you don't need to know the architectures of the core, but you need to have intimate knowledge of the peripherals.

if you want to know the architectures, Yiu's books on the whole CMx family are a great starting point. Be warned: it provide next to nothing to a practitioner.

otherwise, start with the datasheets, tool chain manuals and lots of coding.

As to vendor libraries, I use them often but only through a middle layer of mine so if I want to, I can easily swap out the vendor library in whole or in pieces with no change to my own user code. essentially, my user code has no knowledge about how a certain function is implemented.


About your questions 1-3, some sort of headache is unavoidable... but it is much easier to change between two manufacturers of chips which are based on ARM core.

Please consider some open source libraries that address exactly your concerns, like libopencm3 -- https://github.com/libopencm3/libopencm3

it already has full support for STM32 and work in progress for many other chips (NXP, Freescale, ...).

For question 4, you can order starter kits that are quite inexpensive. Many of them are programmed through USB, and you can use some nice open source software packages, like GCC, GDB (cross compiling for ARM) and OpenOCD.


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