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 processors 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/Webinar: CMSIS - Practical use embedded software development is also highly recommended:
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.
• = Recommended○ = Optional
CMSIS-Core components are required as a starting point for any software development for M-profile/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-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.
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.
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-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-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-RTOS v2 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.
Continuous Integration in embedded software development is becoming increasingly popular and important for certain systems, for example, systems with functions safety (FuSa) requirements. CMSIS-Build provides a set of tools for CI and an alternative way for users to work with CMSIS outside of an IDE environment.
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.
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.
That's exactly what i need ! Thanks you for this publication.