The CMSIS-Pack format is used to deliver a Software Pack and is aimed to be scalable for future requirements. It provides a management process and supports a tool independent distribution for:
- Device Support for tool chains and software applications to target a specific device:
- Information about the processor and it's features.
- C and assembly files for the device startup and access to the memory mapped peripheral registers.
- Parameters, technical information, and data sheets about the device family and the specific devices.
- Device description and available peripherals.
- Memory layout of internal and external RAM and ROM address ranges.
- Flash algorithms for programming the device.
- Debug and trace configurations as well as System View Description files for device specific display of the memory mapped peripheral registers.
- Board Support for rapid development in the prototyping stage:
- Information about the development board and it's features.
- Parameters, technical information, and data sheets about the board, the mounted microcontroller and peripheral devices.
- Drivers for on-board peripheral devices
- Software Components simplify the re-use of software and the management of 3rd party software. They contain:
- A collection of source modules, header and configuration files as well as libraries.
- Documentation of the software, including features and APIs.
- Application Programming Interfaces specify one or more APIs for software components that are part of another Software Pack.
- Example Projects can be used as a reference and starting point for similar applications. They contain:
- Fully defined application projects that work out of the box in the specified build and debug environments.
- Documentation about the purpose of the example, how to build, configure and execute the application.
- User Code Templates help to understand the basic concepts of a software component better and to give the user a good starting point for implementing his application.
All files that belong to a Software Pack are compressed into a *.PACK file using a standard ZIP file format. The content of each Software Pack is described in the Pack Description (*.PDSC) file that is part of each Pack. Refer to Pack Description (*.PDSC) Format for more information.
Pack File Name
A Software Pack must have a unique filename following this naming convention: <vendor>.<name>.<version>.pack.
- <vendor> is name of the supplier or vendor of the Software Pack.
- <name> is name of the Software Pack. It is the vendor's responsibility to ensure unique package names.
- <version>specifies the version number of the Software Pack.
- .pack is the file extension identifying a Software Pack.
- The XML elements <vendor>, <name>, and <version> are declared in the PDSC file.
- <vendor> and <name> must not contain spaces.
The PDSC file needs to reside at the top-level of the Pack file, using it as the root directory for all file references.
Software Component Cclasses
If you add a software component in the PDSC file, you have to specify a component class (CClass), component group (Cgroup), and the component's version number (Cversion). For more information refer to Software Components.
If applicable, try to map the Cclass of your software component to one of the following predefined or already well established classes:
- Board Support: Generic interfaces for evaluation and development boards
- CMSIS: Cortex Microcontroller Software Interface Standard components
- CMSIS Driver: Unified device drivers compliant to the CMSIS-Driver specification
- Compiler: ARM Compiler software extensions
- Data Exchange: Software components for data exchange
- Device: Startup and system setup components
- File System*: File drive support and file system
- Graphics*: Graphical libraries for user interfaces
- Network*: Network stack using Internet protocols
- RTOS*: Real-time operating systems
- Safety: Components for testing application software against safety standards
- Security*: Encryption for secure communication or storage
- USB*: Universal Serial Bus stack
- Wireless*: Communication stacks such as Bluetooth, WiFi, and ZigBee
Classes with a * should always be used together with a bundle to avoid conflicts with other software components.
If you wish to standardize a new Cclass, please send an inquiry to cmsis.nosp@m.@arm.nosp@m..com or raise an issue on the public CMSIS GitHub development repository.
Steps to Create a Pack
The following image shows the basic steps that are required to create a Software Pack:
- Produce input: Create the files that will be delivered with the Pack.
- Organize files: Use directories to separate the content of the Pack.
- Create PDSC file: The XML based PDSC file can be created using any text editor. Editors that can validate XML code against a schema file help to find bugs early in the Pack development stage.
- Generate PACK: Any compression tool supporting the ZIP format can be used to create a PACK file. packChk.exe is helpful for the validation of the contents of a Pack.
The following pages will show how to create a Software Pack from scratch. The page Pack with Software Components will start with a simple Pack containing only the PDSC file and a single software component and will then explain further elements of a Pack in more detail. The page Pack with Device Support adds information on the additional requirements that a DFP has, while Pack with Board Support will elaborate on the content specific to a BSP.
The ARM::CMSIS Pack contains tutorials that are explained on the following pages. In the \CMSIS\Pack\Tutorials directory the following three ZIP files are available: