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.
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.
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)
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
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 */
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.