ARM Peripheral Drivers@STM32

This article discuss the  software options available for ARM based micro-controllers.  The ecosystem  by  different silicon vendors consists of Software development tools to meet the requirement of editing, compiling , linking and debugging the application.  Additionally they provide required libraries along with peripheral access APIs . Some of them go one step further by providing GUI based tool to generate  C code for accessing device IPs.

This is in continuation of last article ARM Instruction Set Classification

STM32 bare-metal Peripheral Driver Support Journey at a glance

The latest LL (Low Layer) API supports all STM32 devices. Following provides a quick overview to reach up to this point.  To ease the programmer’s life ST has  provided  STM32cubeMx which generates C code by using GUI based configuration . You may find similar GUI configuration approach to generate device driver in Processor Expert by NxP

Although GUI based tools help reduce development cycle but sometime new release may contain bugs. Therefore ,  One must learn the manual approach behind these device driver files.

Any Industry standard for designing ARM micro-controller bare metal device driver ?

Yes , It is called Cortex Microcontroller Software Interface Standard (CMSIS)

What is the purpose of CMSIS ?

• • To standardize software interfaces among all Cortex-M silicon vendor products.
  • To provide a common approach for software interfaces among peripheral access, RTOS,DSP  and  many other middleware components
  • This helps in software reuse in migrating from one silicon version to another and also from one vendor to another
  • CMSIS is a framework to  integrate  third-party software

 Do  we need all above layers to write a simple application for STM32 Nucleo board?

Not really, One can manage with minimum core( in this case Cortex-M4) and  device/SoC specific files.

CMSIS-Core(Cortex-M) : API  to access  the Cortex-M processor core and peripherals. You may find CMSIS in TrueStudio generated project.

C:\Users\shreyash\Atollic\TrueSTUDIO\STM32_workspace_9.2\test_dbg\Drivers\CMSIS\Include

core_cm4.h : CMSIS Cortex-M4 Core Peripheral Access Layer Header File. It contains various macro definitions , inline function, typedef struct etc  to access Cortex-M4 registers.

For example NVIC function

__STATIC_INLINE void NVIC_SetPriorityGrouping(uint32_t PriorityGroup)
{
uint32_t reg_value;
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

reg_value = SCB->AIRCR; /* read old register configuration */
::::::::::::::::::::::::::::
(PriorityGroupTmp << 8U) ); /* Insert write key and priorty group */
SCB->AIRCR = reg_value;
}

• CMSIS-Driver provides generic bare-metal peripheral driver APIs which helps portability in the supported device family.  The middleware software stack  (used for communication , GUI , File system etc ) can use this peripheral driver.

How CMSIS is integrated with user application ?

If you create a baremetal  C application using TrueStudio , You  may notice  Device Specific File stm32l4xx.h   in the main.c file  .It is located at

C:\Users\shreyash\Atollic\TrueSTUDIO\STM32_workspace_9.2\test_dbg\Drivers\CMSIS\Device\ST\STM32L4xx\Include

User has choice to access device peripherals directly or through HAL (Hardware Abstraction Layer) driver APIs.

#if !defined (USE_HAL_DRIVER)
/**
* @brief Comment the line below if you will not use the peripherals drivers.
In this case, these drivers will not be included and the application code will
be based on direct access to peripherals registers
*/
/*#define USE_HAL_DRIVER */
#endif /* USE_HAL_DRIVER */

USE_HAL_DRIVER

If you plan to use HAL drivers , You should  use the STM32CubeMX code generator to generate the latest versions of drivers, stacks  and middleware.  This is required because Peripheral drivers are frequently updated by silicon vendors to add support for new devices or fix bugs.

It can be copied to following :C:\Users\shreyash\Atollic\TrueSTUDIO\STM32_workspace_9.2\test_dbg\Drivers\STM32L4xx_HAL_Driver

What are the main characteristics  of CMSIS compliant code ?

Following are some of the  essential rules & conventions to be followed by CMSIS compliant code  :

• • Compliant with ANSI C (C99) and C++ (C++03).
  • Uses ANSI C standard data types defined in <stdint.h>.
  • Variables and parameters have a complete data type.
  • Expressions for #define constants are enclosed in parenthesis.

Additionally , CMSIS recommends following conventions for identifiers :

• CAPITAL names to identify Core Registers, Peripheral Registers, and CPU Instructions.
• CamelCase names to identify function names and interrupt functions.
• Namespace_ prefixes avoid clashes with user identifiers and provide functional groups (i.e. for peripherals, RTOS, or DSP Library).

The CMSIS is documented within the source files with:

• Comments that use the C or C++ style.
• Doxygen compliant function comments that provide:
  • brief function overview.
  • detailed description of the function.
  • detailed parameter explanation.
  • detailed information about return values.

Reference:

• CMSIS Documentation

This particular article is discussed at STM32 Peripheral Drivers

Thanks for reading till end. We will keep posting  Embedded specific important topics.  If you find useful tips at Embedkari, Please subscribe  Embedkari so that you don’t miss any interesting topic .