![]() |
CMSIS Driver
Version 1.10 - Preliminary
Middleware Driver API for microcontroller peripherals
|
Peripheral Driver Interfaces are implementations of published APIs. The APIs are Component Groups under the Device Class of a software component. Currently the CMSIS Pack publishes the Driver API Interface with one or more *.h header files and a documentation. It is intended to standardize these Peripheral Driver Interfaces as part of a future CMSIS release.
The actual implementation of each driver is provided in the Device Family Pack available for each microcontroller family. In a Device Family Pack the Device Class contains several software component Groups with Device Drivers for physical device peripherals that are typically used by middleware libraries.
The following Device Driver interfaces are defined as API:
A specific Device Driver API does not support every potential use-case of a peripheral type. For example the Device Driver API Group Ethernet is not suitable for the Precision Time Protocol defined in IEEE1588. In a similar way the Device API Group UART does not support SmartCard interfaces. However, the defined API interfaces support a wide range of use cases. It is possible to extend a Device class with further Device API Groups to cover new use-cases.
A Device Family Pack may contain additional Peripheral Driver Interfaces to extend the standard Device Driver API Groups defined by a future CMSIS standard. For example, other supporting Peripheral Driver Interfaces for Memory BUS, GPIO, or DMA may be part of the Device Family Pack and referenced by the implementation of the standard Device Driver API Groups.
The driver implementations assumes the CMSIS-RTOS functionality and may use interrupts and DMA (direct memory access) available in the device. Each peripheral type that is accessed by a Driver publishes a struct that allows to access the functions of the driver. This struct type is named ARM_DRIVER_xxx and Function Access in the documentation.
Example: Function Access of the SPI driver
A device may offer several peripherals of the same type. For such devices, a driver implementation publishes multiple instances of the driver access structure. The name of each driver instance reflects the names of the peripheral available in the device.
Example: SPI driver Function Access structs for 3 SPIs in a microcontroller device.
For a device family, the drivers are configurable and all configuration options are stored in a central file with the name RTE_Device.h. This file contains also configuration settings for the processor and peripheral clock. The RTE_Device.h may contain control strings for the MDK Configuration Wizard. However, the RTE_Device.h file may be also configured with silicon vendor specific configuration utilities.
Each Function Access struct of a driver contains these functions:
Additional functions are specific to each driver interface and described in the individual sections of each driver.
The driver API functions GetVersion, GetCapabilities, Initialize, PowerControl, Uninitialize are called in the following order:
Version | Description |
---|---|
1.10 | Initial release |