The Common Microcontroller Software Interface Standard (CMSIS) is today integral to most software running on Arm Cortex-M processor-based microcontrollers. Without a standard like CMSIS, the software running on the billions of devices would not be as consistent, resulting in less code reuse, steeper learning curves for software developers, and additional costs in terms of getting devices out to market. Additionally, even in a larger subsystem comprising one or more Cortex-M cores and several more powerful cores, CMSIS can still help to keep software development as simple as possible.
Before reading on, if you are not already familiar with CMSIS, it is probably worth having a quick read through some of the existing blogs and documentation, which is referenced at the end of this article. Additionally, the video and webinar: CMSIS - Practical use in embedded software development is also highly recommended.
CMSIS: practical use in embedded software development
Many embedded developers and MCU designers may have at least heard of CMSIS and the benefits it brings. However, today CMSIS comprises various components which over time have steadily grown in number. This short article aims to help you decide which bits of CMSIS are recommended, which bits are optional and should be considered, and which bits might not apply, in relation to the Arm-based project you are working on. There are lots of different job roles in any Arm-based project. As a quick reference, hopefully you can find your job role in the following table and quickly identify which CMSIS components apply to you.
Many Arm microcontroller users will just need to use existing CMSIS components, but others might also need to develop and create CMSIS components, such as software packs, so that a wider audience can make use of them.
If you are a Cortex-M software developer and reading this article, it is quite likely you have used CMSIS-Core headers and startup code already and have some familiarity with what different CMSIS components offer. On the other hand, if you are a system designer, you might have less software development experience and more expertise in RTL Verilog. Even so, it is still likely to be the case that you will need to write some initial software that will run on the device you are designing and testing, so it is good to 'get off on the right foot' and use CMSIS from the outset of the project.
If you have used Cortex-M in past projects, you might be able to reuse some of the CMSIS-compliant software. However, if you are designing your first Arm microcontroller system or your previous projects did not comply with CMSIS, then it is recommended that you make the extra effort to create relevant components for the device you are designing. Furthermore, doing this should help those who are responsible for creating other software components and documentation for your device. If the system developer can get this right, then hopefully all of their users follow.
The following table attempts to give you a quick and easy insight into which CMSIS components you should care about. If you are a project/product manager, then I strongly recommend checking all CMSIS components with different members of your team, and in particular which optional components might benefit the project you are managing. Recommended and optional CMSIS components are described in a bit more detail in the following post.
Key:
• = Recommended⚬ = Optional* = New in CMSIS version 6
CMSIS-Core components are required as a starting point for any software development for M-profile and Cortex-M systems. Whether you are a test engineer or developing an application that end up running on the end device, making use of CMSIS-Core headers and startup files are simply going to make your life easier. Arm publishes CMSIS-Core headers for accessing registers and peripherals belonging to the Arm processor. Also, if you are designing a system, you can use CMSIS-SVD to generate CMSIS-Core headers for your own peripherals.
CMSIS-Driver is an API for working with common peripherals and middleware stacks such as Keil-Middleware. It provides an extra level of abstraction and is independent of the underlying operating system's programming mechanism. It might be the case that you are working on a bare-metal system that might not require an extra level of abstraction, but in many systems CMSIS-Driver could help developers work with a device more easily or when they switch from one device to another.
CMSIS-RTOS v2 (CMSIS-RTOS2) is a standard API for real-time operating systems. A key idea behind the API is to make it easier for developers to switch from one operating system to another. FreeRTOS, RTX5, and Zephr, are examples of operating systems compliant with CMSIS-RTOS.
CMSIS offers other components that could provide ways to further help improve the consistency of software across different aspects of an embedded/microcontroller system.
CMSIS-DSP is a collection of DSP functions for various filters and algorithms that target all available Cortex-M processors. If you are working on DSP applications, look at these free offerings. They might save you a lot of work. Also, if you are an experienced DSP engineer then the door is always open for you to make your own contributions to the CMSIS-DSP software project.
CMSIS-NN provides optimization for compute intensive ML operators targeting Cortex-M processors. It is aimed at enabling applications in the Edge AI domain and supports the framework TensorFlow Lite for microcontrollers. If you are developing any such applications, the optimized ML operators which are free to use could save you a lot of work and add value to your project. Like with other CMSIS components, you are always welcome to join the open-source team and contribute to CMSIS-NN. CMSIS-DSP is also recommended for anyone working with CMSIS-NN since it helps with raw data formatting to prepare input data to an ML model.
CMSIS-View equips software developers with software components, utilities and methodologies that provide visibility into internal operation of embedded applications and software components. CMSIS-View is particularly useful for analyzing events and faults that might occur whilst an embedded application is running using a standard API and viewing tools.
Compiler tools typically offer special library support, called semihosting, to give debug tools the chance to offer the developer a quick and convenient way to handle I/O functionality. For example, a compiler and debugger that both support semihosting means that output from a C library function like printf() can be automatically redirected to a convenient I/O display within the debug environment. A semihosted environment is convenient for a little while, but at some point developers need to retarget this functionality to somewhere else like a UART peripheral. Also, some debug tools simply do not support semihosting, so users sometimes need to find a way to retarget such I/O at a very early stage in their project's lifecycle. CMSIS-Compiler not only provides software components for retargeting I/O operations in standard C run-time libraries, but it also supports an OS-independent interface for multithreading.
CMSIS-Toolbox is one ot the most exciting additions to CMSIS version 6. CMSIS-Toolbox supersedes CMSIS-Build and adds even more functionality to make it much easier to manage your projects. Continuous Integration in embedded software development is becoming increasingly popular and vital for certain systems, for example, systems with functions safety (FuSa) requirements. CMSIS-Toolbox provides a set of tools for CI that supports multiple compilers: Arm Compiler for Embedded, Arm GNU Toolchain (GCC) version, IAR Compiler, and CLANG Compiler, making it possible to continuously develop and build your project with multiple toolchains with just a single command (see the CMSIS-Toobox documentation and CMSIS-Toolbox Getting Started Tutorial for further details on compiler version support and how to get started). CMSIS-Toolbox may also be used within an IDE environment or from the command-line interface, providing developers with more flexibility.
CMSIS-Stream is a new component added for DSP and ML engineers interested in optimizing data block streaming between processing steps of a DSP/ML application. (The 'Stream' in CMSIS-Stream should not be confused with streaming trace tools like DSTREAM-ST). The majority of CMSIS-Stream involves a Python script that can be used to automatically generate standard functionality required for data block streaming, so the end user can focus more on the specific nodes they want to focus on. CMSIS-Stream also has no dependencies on any other CMSIS component. The CMSIS-Stream documentation provides further details on what's involved and there are various examples already available to try out in the CMSIS-Stream open-source repository.
CMSIS-DAP is low-cost debug solution that is integrated into many Arm embedded platforms including many Mbed enabled devices. If you are designing a new MCU device and a development board that contains the MCU, then you might want to consider adding a CMSIS-DAP connection to the system. The main advantage is that your end users can connect to the device directly via USB rather than having to purchase a separate debug adapter such as a ULINK or DSTREAM.
The term 'Zone' in CMSIS-Zone is related to protection and security. Today, Arm embedded systems can be configured with multiple protection mechanisms such as a Memory Protection Unit (MPU), a Peripheral Protection Controller (PPC), or the Security Attribution Unit (SAU) available in Armv8-M systems that implement the Security Extension (TrustZone for Armv8-M). CMSIS-Zone makes it much easier to configure these more complex embedded systems. Also, to save you having to read through all the documentation, there is a nice introductory video that demonstrates the advantages of using this CMSIS component.
CMSIS provides specifications for device vendors to package their products in a standard way, which makes it significantly easier for different people involved in a project to work with a given device.
CMSIS-Pack describes a delivery mechanism for software components, device parameters, and board support. For developers who are working with an off-the-shelf microcontroller, there should hopefully already be one or more packages available to download that support the device you're working with. The Arm website hosts many of these:
The Device Family Packs (DFPs) contain the necessary support files including C headers and startup code. Sometimes there are also bonus software packages available that have been written by the CMSIS community to provide generic and specific solutions for various devices, such as middleware or real-time operating systems. If you are designing a system, then you can generate your own XML-based packages too, for example, a board support pack for your target system.
There is also a DFP (Cortex_DFP) for Arm pseudo devices that can be used for generic Arm software projects or for validation purposes with Arm simulation models.
CMSIS-SVD is highly recommended for any device/silicon vendor working on a new system design. An XML scheme similar to IP-XACT (if you are familiar with that) is provided to allow device vendors to describe the peripherals on their device. Once the XML has been written in the correct syntax, it can be processed by a utility named SVDConv to automatically generate CMSIS-Core-compliant C header files for the device. The XML files may also be useful for debug tools and can be reused in the future when migrating to other Cortex-M systems. As a software developer, you use these SVD files in your debugger to get access to your device's registers.
I hope that this article helps you figure out which CMSIS components are useful for your project. I have added a short FAQ list, but if you have any further questions, feel free to post something or contact Arm's support team.
Q: Does CMSIS support any other Arm architectures and processors other than M-profile/Cortex-M?A: There are a small number of Armv7-A Cortex-A processors currently supported by CMSIS. Arm is continually looking at ways to simplify and standardize software. Although CMSIS is currently focused primarily on Cortex-M devices, that's not to say that it couldn't be expanded to other profiles in the future.
Q: Can I contribute to CMSIS?A: Yes. CMSIS is an open source project. Arm is heavily involved in maintaining CMSIS and encourages as many developers to get involved in improving the standard.
Q: Is there a branch of CMSIS that's suitable for developing safety applications?A: Arm's FuSa RTS suite contains a stable branch of CMSIS-Core that doesn't receive updates from upstream.
Q: Is there a tool that can convert my IP-XACT schema to the CMSIS-SVD XML schema?A: There are tools that claim to have support for this. A quick search on the web for "IP-XACT SVD" should point you in the right direction.
Arm Community
Arm Developer
Github
Arm Keil