Application software development of Cortex-M3 based on CMSIS standard

　　ARM released the ARM Cortex Microcontroller Software Interface Standard (CMSIS) on November 12, 2008. CMSIS is a vendor-independent hardware abstraction layer for the Cortex-M processor series, which provides a continuous and simple processor software interface for chip manufacturers and middleware suppliers, simplifies software reuse, reduces the difficulty of porting operating systems on Cortex-M3, and shortens the learning time for new microcontroller developers and the time to market for new products.

　　According to recent surveys, software development has been recognized by the embedded industry as the main development cost. Figure 1 shows a comparison of software development and hardware development costs in recent years. Therefore, ARM has cooperated with many chip and software manufacturers such as Atmel, IAR, Keil, Hami-nary Micro, Micrium, NXP, SEGGER and ST to standardize the software interfaces of all Cortex chip manufacturers' products and formulate the CMSIS standard. This move is intended to reduce software development costs, especially for new equipment project development or porting existing software to Cortex processor-based microcontrollers provided by other chip manufacturers. With this standard, chip manufacturers can focus their resources on differentiating product peripheral features and eliminate the need to maintain different and incompatible standards when programming microcontrollers, thereby achieving the goal of reducing development costs.

　　1 Software architecture based on CMSIS standard

　　As shown in Figure 2, the software architecture based on the CMSIS standard is mainly divided into the following four layers: user application layer, operating system and middleware interface layer, CMSIS layer, and hardware register layer. The CMSIS layer plays a connecting role: on the one hand, this layer implements the hardware register layer in a unified manner, shielding the different definitions of the internal and external registers of the Cortex-M series microprocessor core by different manufacturers; on the other hand, it provides interfaces to the upper operating system and middleware interface layer and application layer, simplifying the difficulty of application development and enabling developers to develop applications in a completely transparent manner. For this reason, the implementation of the CMSIS layer is relatively complex.

 　　The CMSIS layer is mainly divided into 3 parts.

　　① Core Peripheral Access Layer (CPAL): ARM is responsible for its implementation. It includes the definition of register addresses, the definition of access interfaces to core registers, NVIC, and debug subsystems, and the definition of access interfaces to special-purpose registers (such as CONTROL and xPSR). Since access to special registers is defined inline, ARM uses _INLINE to mask differences for different compilers. All interface functions defined in this layer are reentrant.

　　② Middleware Access Layer (MWAL): ARM is responsible for implementation, but chip manufacturers need to update this layer according to the characteristics of the equipment they produce. This layer is mainly responsible for defining some API functions for middleware access, such as providing standard software interfaces for access and debugging of TCP/IP protocol stack, SD/MMC, USB protocol and real-time operating system. This layer has not yet been implemented in the 1.1 standard.

　　③Device Peripheral Access Layer (DPAL): implemented by chip manufacturers. The implementation of this layer is similar to CPAL, and is responsible for defining the hardware register address and peripheral access interface. This layer can call the interface functions provided by the CPAL layer, and expand the exception vector table according to the device characteristics to handle the interrupt request of the corresponding peripheral. [page]

　　2 CMSIS Specification

　　(1) File structure

　　The file structure of CMSIS is shown in Figure 3 (taking STM32 as an example). Among them, stdint.h includes the definition of type indicators such as 8-bit, 16-bit, and 32-bit, which is mainly used to mask the differences between different compilers. core_cm3.h and core_cm3.c include the declaration and definition of global variables of the Cortex_M3 core, and define some static function functions. system_.h and system_.c (i.e. system_stm32.h and system_stm32.c in Figure 3) are the system initialization function SystemInit() defined by different chip manufacturers, as well as some variables indicating the clock (such as SystemFrequency). .h (i.e. stm32.h in Figure 3) is the header file provided to the application, which contains core_cm3.h and system_.h, defines registers related to specific chip manufacturers and various interrupt exception numbers, and can customize special devices in the M3 core, such as MCU, interrupt priority bit number, and SysTick clock configuration. Although CMSIS provides many files, only h needs to be included in the application.

 　　(2) Toolchain

　　CMSIS supports the three major tool chains for embedded development, namely ARM ReakView (armcc), IAR EWARM (iccarm) and GNU tool chain (gcc). The following definition in core_cm3.C can be used to mask the differences in some compiler built-in keywords. 

　　In this way, the functional functions in CPAL can be defined as static inline types (static_INLINE) to achieve compilation optimization.

　　(3) Interrupt exception

　　CMSIS has strict requirements for exception and interrupt identifiers, interrupt handler function names, and interrupt vector exception numbers. Exception and interrupt identifiers must be suffixed with _IRQn, the system exception vector number must be a negative value, and the device interrupt vector number is incremented from 0. The specific definition is as follows (taking STM32 as an example): CMSIS also defines system exception handler function names and common interrupt handler function names differently. System exception handler function names must be suffixed with _Handler, while common interrupt handler function names are suffixed with _IRQHandler. These exception interrupt handler functions are defined as weak attributes so that duplicate definition errors do not occur when re-implemented in other files. The addresses of these handler functions are used to fill the interrupt exception vector table and are declared in the startup code, for example: NMI_Handler, MemManage_Handler, SysTick_Handler, WWDG_IRQHandler, etc.

 CMSIS also defines system exception handling functions and common interrupt handling function names differently. System exception handling function names must be suffixed with _Handler, while common interrupt handling function names must be suffixed with _IRQHandler. These exception interrupt handling functions are defined as weak attributes so that duplicate definition errors do not occur when they are reimplemented in other files. The addresses of these handling functions are used to fill the interrupt exception vector table and are declared in the startup code, such as: NMI_Handler, MemManage_Handler, SysTick_Handler, WWDG_IRQHandler, etc.

      (4) Data types

CMSIS defines data types in stdint.h and defines core register structures in core_cm3.h. Register access rights are indicated by corresponding identifiers. CMSIS defines the following three identifiers to specify access rights: _I (volatile const), _O (volatile), and _IO (volatile). _I is used to specify read-only permission, _O specifies write-only permission, and _IO specifies read-write permission.

      (5) Debugging

A basic requirement in embedded software development is to be able to output debugging information through the terminal. This can generally be achieved in two ways: one is to use a serial cable to connect the UART on the board and the COM port on the PC, and view the debugging information through the hyperterminal on the PC; the other is to use the semi-host mechanism, but it may not be supported by the tool chain used. Software debugging based on the Cortex-M3 core breaks through this limitation. The Cortex-M3 core provides an ITM (Instrumentation Trace Macrocell) interface, and the ITM data received by the SWO pin can be debugged through SWV (Serial Wire Viewer). ITM implements 32 general data channels. Based on this implementation, CMSIS stipulates that channel 0 is used as a terminal to output debugging information, and channel 31 is used for output debugging of the operating system (privileged mode access). The ITM_SendChar() function is defined in core_cm3.h, so it can be called to rewrite fputc to print debugging information through printf in the application, and the debugging information can be viewed through the ITM Viewer. With this implementation, embedded software developers can output debugging information without configuring the serial port and using terminal debugging software, which reduces the workload to a certain extent.

      (6) Security Mechanism

In the process of embedded software development, the security and robustness of the code have always been the focus of developers, so CMSIS has also made efforts in this regard. All CMSIS codes are based on the MISRA-C2004 (Motor Industry Software Reliability Association for the C programming language) standard. MIRSA-C 2004 has established a series of security mechanisms to ensure the security of driver layer software, which is a standard that the embedded industry should follow. For those that do not meet the MISRA standard, the compiler will prompt an error or warning, which mainly depends on the tool chain used by the developer.

      3 Code Implementation Based on CMSIS Standard

CMSIS reduces the difficulty of code development. To better explain this, a simple example based on STM32 microprocessor is used to illustrate it. The code implementation is as follows: It can be seen that only a few lines of code in the user program are needed to implement the timer function, reporting once every 1 S, and the output debugging information can be viewed through the ITM window. Among them, SystemInit() is used to initialize the clock, SysTick_Config() is used to configure the system timer, and SysTick_Handler() is used to handle system clock exceptions, which occur once every 1 ms. Since fputc() is rewritten, the debugging information can be printed to the ITM window through the printf() function, and the output result is shown in Figure 4. Conclusion This article explains the software architecture and specifications based on the CMSIS standard, and uses an example to more clearly interpret the great potential of CMSIS as a new software development standard based on the Cortex-M core processor series. It not only reduces the difficulty of software development, but also reduces the cost of software development. Therefore, it will be of great help for engineers to master the CMSIS standard as soon as possible for software development based on the Cortex-M3 processor.