As we have discussed earlier about CMSIS in first chapter that Introduction to Arm Cortex Microcontrollers , it is clear that CMSIS is much worthy for development cores like ARM Cortex. But i wonder when i come across that, and first question arise in my mind is

Why CMSIS ?

• Overall CMSIS reduces the learning curve, development costs, and time-to-market for new product.
• Developers can write software quicker through a variety of easy-to-use, standardized software interfaces.
• Standardized software interfaces improve the software portability and re-usability.
  And provides interfaces for debug connectivity, debug peripheral views, software delivery, and device support.
• Provides a compiler independent layer that allows using different compilers. CMSIS is supported by all mainstream compilers (ARMCC, IAR, and GNU).
• Enhances program debugging with peripheral information for debuggers and ITM channels for printf-style output and RTOS kernel awareness.

 More about CMSIS

CMSIS provide common abstraction layer so that we can achieve software re-usability and re-portability. In simple words, software written for ARM Cortex-M0 can work for ARM Cortex-M0+ and above devices release after Cortex-M0 with no or minimal changes. CMSIS provide common Hardware Abstraction Layer for all Cortex-M series family. Definition of CMSIS provided according to ARM is like follows:

So, as it is clear CMSIS is standard HAL for all devices using ARM CORTEX as CPU core. CMSIS helps you utilize core features like DSP co-processor, Floating Point Unit etc in an easier way. So CMSIS is for CORE Features, Now lets discuss things outside the CPU core, Each vendor (in our case STMicroelectronics) uses CORTEX core and makes their own ARM based devices by adding some additional features/ peripherals around core. For example almost all vendors add peripherals like USART, ADC, I2C, SPI, CAN, Timers etc. These peripherals too need drivers or Hardware Abstraction Layer, I am not saying that it is impossible to write Drivers for specific peripheral inside MCU, but it consumes your development time. So in order to simplify the development process specific vendors provide some standard peripheral driver library. ST Micro-Electronics has provided a rich set of standard peripheral driver firmwares, so that you can quickly move onto applications without worrying about each bit of register level details.

                     So, as per our first step we need Standard Peripheral Drivers provided by ST Micro-Electronics to start development on STM32F4 Discovery Board. You can download it from our previous lesson Some useful links for STM32F4 Development or click below:

Standard Peripheral drivers and CMSIS library

Understanding Standard Peripheral Driver Library

After download of Standard Peripheral drivers library from the Link given above, Extract it somewhere in your computer. You will find directory organization something like shown below:

_htmresc

This folder contains all packages html page resources.

Libraries

This folder contains two sub-folder, CMSIS and STM32F4xx_StdPeriph_Driver.

CMSIS subfolder

This folder contains the STM32F4 CMSIS files: device peripheral, access layer, Documentation, RTOS(cmsis_os), License terms and core peripheral access layer. Out of all these files, there are three important files:

1. stm32f4xx.h: this file contains the definitions of all peripheral registers, bits, and memory mapping for STM32F4xx devices. The file is the unique include file used in the application programmer C source code, usually in the main.c.
2. system_stm32f4xx.c/.h: This file contains the system clock configuration for STM32F4xx devices. It exports SystemInit( ) function which sets up the system clock source, PLL multiplier and divider factors, AHB/APBx prescalers and Flash settings. This function is called at startup just after reset and before connecting to the main program. The call is made inside the startup_stm32f4xx.s file.
3. startup_stm32f4xx.s: Provides the Cortex-M4F startup code and interrupt vectors for all STM32F4xx device interrupt handlers.

STM32F4xx_StdPeriph_Driver subfolder

This sub-folder contains header files and source files of standard driver developed by ST like USART, GPIO, PWM, etc which make up the core of the library.

 Project

This folder also contains two sub-folder, STM32F4xx_StdPeriph_Examples and STM32F4xx_StdPeriph_Templates.

STM32F4xx_StdPeriph_Examples subfolder

This folder contains many sub-folders for each peripheral like ADC, USART, GPIO, CAN, etc. These peripheral folders consist the minimum set of files needed to run a typical example on how to use this peripheral. There is also a: readme.txt that is brief text file describing the example and how to make it work.

 STM32F4xx_StdPeriph_Templates subfolder

This folder contains standard template projects for IAR, KEIL, RAISONANCE, TASKING and TrueSTUDIO toolchains.
stm32f4xx_conf.h – configuration header file
stm32f4xx_it.c – source file containing the interrupt handlers
stm32f4xx_it.h – header file including all interrupt handlers prototypes
main.c – main program body
main.h – header file for main.c
system_stm32f4xx.c – clock tree initialization, configure the PLL, system clock, initialize the Embedded Flash Interface, etc.

Utilities

Implement an abstraction layer to interact with the Human Interface resources; buttons, LEDs, LCD, fat file system, toolchain patches for different compilers and COM ports (USARTs) available on STM32F4-Discovery, STM3240G-EVAL and STM3241G-EVAL. A common API is provided to manage the LCD across the supported boards, with a separate driver for each board stm324xg_eval_lcd.c.

stm32f4xx_dsp_stdperiph_lib_um

This is very useful HTML document of whole standard peripheral driver library which is arranged in proper manner.