/** \mainpage Overview The CMSIS-Driver specification is a software API that describes peripheral driver interfaces for middleware stacks and user applications. The CMSIS-Driver API is designed to be generic and independent of a specific RTOS making it reusable across a wide range of supported microcontroller devices. The CMSIS-Driver API covers a wide range of use cases for the supported peripheral types, but can not take every potential use-case into account. Over time, it is indented to extend the CMSIS-Driver API with further groups to cover new use-cases. The CMSIS Software Pack publishes the API Interface under the Component Class \b CMSIS \b Driver with header files and a documentation. These header files are the reference for the implementation of the standardized peripheral driver interfaces. These implementations are published typically in the Device Family Pack of a related microcontroller family under the Component Class \b CMSIS \b Driver. A Device Family Pack may contain additional interfaces in the Component Class \b Device to extend the standard Peripheral Drivers covered by this CMSIS-Driver specification with additional device specific interfaces for example for Memory BUS, GPIO, or DMA. The standard peripheral driver interfaces connect microcontroller peripherals for example with middleware that implements communication stacks, file systems, or graphic user interfaces. Each peripheral driver interface may provide multiple instances reflecting the multiple physical interfaces of the same type in a device. For example the two physical SPI interfaces are reflected with a separate \ref AccessStruct for SPI1 and SPI2. The \ref AccessStruct is the interface of a driver to the middleware component or the user application. \image html driver.png "Peripheral Driver Interfaces and Middleware" The following CMSIS-Driver API groups are defined: - \ref can_interface_gr "CAN": Interface to CAN bus peripheral. - \ref eth_interface_gr "Ethernet": Interface to Ethernet MAC and PHY peripheral. - \ref i2c_interface_gr "I2C": Multi-master Serial Single-Ended Bus interface driver. - \ref mci_interface_gr "MCI": Memory Card Interface for SD/MMC memory. - \ref nand_interface_gr "NAND": NAND Flash Memory interface driver. - \ref flash_interface_gr "Flash": Flash Memory interface driver. - \ref sai_interface_gr "SAI": Serial audio interface driver (I2s, PCM, AC'97, TDM, MSB/LSB Justified). - \ref spi_interface_gr "SPI": Serial Peripheral Interface Bus driver. - \ref storage_interface_gr "Storage": Storage device interface driver. - \ref usart_interface_gr "USART": Universal Synchronous and Asynchronous Receiver/Transmitter interface driver. - \ref usb_interface_gr "USB": Interface driver for USB Host and USB Device communication. - \ref vio_interface_gr "VIO": API for virtual I/Os (VIO). - \ref wifi_interface_gr "WiFi": Interface driver for wireless communication. A list of current CMSIS-Driver implementations is available \ref listOfImplementations "here". \note Usually, WiFi chips and modules have their own networking stack incorporated. This means that payload data is sent via a serial interface (SPI or USART) to the WiFi chip/module and the Ethernet frames are assembled inside. If you intend to use a TCP/IP stack from a middleware component with a WiFi chip/module, make sure that the WiFi driver has a \ref wifi_bypass_gr. This allows to send the Ethernet frames assembled by the TCP/IP component transparently through the WiFi chip/module.
CMSIS-Driver in ARM::CMSIS Pack ------------------------------- The following files relevant to CMSIS-Driver are present in the ARM::CMSIS Pack directories: | Directory | Content | |--------------------------------|------------------------------------------------------------------------| |\b CMSIS/Documentation/Driver | This documentation | |\b CMSIS/Driver/Include | Driver header files (Driver_interface.h, Driver_Common.h) | |\b CMSIS/Driver/DriverTemplates | Driver implementation template files (Driver_interface.c) |
*/ /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/ /** \page driver_revisionHistory Revision History of CMSIS-Driver
Version Description
2.8.0 - Changed: removed volatile from status related typedefs APIs - Enhanced WiFi Interface API with support for polling Socket Receive/Send - Added VIO API 0.1.0 (Preview)
2.7.1 - Finalized WiFi Interface API 1.0.0.
2.7.0 - Added WiFi Interface API 1.0.0-beta. - Added custom driver selection to simplify implementation of new CMSIS-Driver.
2.6.0 - Enhanced CAN-Driver API with explicit BUSOFF state. - Enhanced NAND-Driver API for ECC handling.
2.05 - Changed: All typedefs related to status have been made volatile.
2.04 - Added: template files for CAN interface driver.
2.03 - Added: CAN API for an interface to CAN peripherals - Added: Overview of the \ref driverValidation "CMSIS-Driver Validation" Software Pack. - Enhanced: documentation and clarified behavior of the \ref CallSequence.
2.02 - Minor API changes, for exact details refer to the header file of each driver. - Added: Flash Interface, NAND interface.
2.00 API with non-blocking data transfer, independent of CMSIS-RTOS.
1.10 Initial release
*/ /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/ /** \page listOfImplementations CMSIS-Driver Implementation List The following table shows a list of current CMSIS-Driver implementations. It is regularly updated, so it is subject to change. [CAN]: \ref can_interface_gr "CAN" [Ethernet MAC]: \ref eth_mac_interface_gr "Ethernet MAC". [Ethernet PHY]: \ref eth_phy_interface_gr "Ethernet PHY". [I2C]: \ref i2c_interface_gr "I2C". [MCI]: \ref mci_interface_gr "MCI". [NAND]: \ref nand_interface_gr "NAND". [Flash]: \ref flash_interface_gr "Flash". [SAI]: \ref sai_interface_gr "SAI". [SPI]: \ref spi_interface_gr "SPI". [Storage]: \ref storage_interface_gr "Storage". [USART]: \ref usart_interface_gr "USART". [USB Host]: \ref usbh_interface_gr "USB Host". [USB Device]: \ref usbd_interface_gr "USB Device". [VIO]: \ref vio_interface_gr "VIO". [WiFi]: \ref wifi_interface_gr "WiFi"
Vendor Device/Family [CAN] [Ethernet MAC] [Ethernet PHY] [I2C] [MCI] [NAND] [Flash] [SAI] [SPI] [Storage] [USART] [USB Host] [USB Device] [VIO] [WiFi]
Arm Musca-A1
√
√
Musca-B1
√
√
Musca-S1
√
SSE-200
√
√
√
√
SSE-300
√
√
√
√
SSE-310
√
√
√
√
Espressif ESP32
√
ESP8266
√
Infineon S29GL064Nx2
√
XMC1000
√
√
√
√
√
XMC4000
√
√
√
√
√
√
√
√
√
√
Inventek ISM43362
√
Microchip KSZ8061RNA
√
KSZ8061RNB
√
KSZ8851SNL
√
√
LAN8710A
√
LAN8720
√
LAN8742A
√
LAN8740A
√
LAN91C111
√
√
LAN9220
√
√
Micron M29EW28F128
√
M29W640FB
√
NXP LPC1500
√
√
√
LPC1700
√
√
√
√
√
√
√
√
√
LPC1800
√
√
√
√
√
√
√
√
√
LPC4000
√
√
√
√
√
√
√
√
√
LPC4300
√
√
√
√
√
√
√
√
√
i.MXRT105x
√
√
√
√
√
i.MXRT1060
√
√
√
√
√
i.MXRT1064
√
√
√
√
√
√
K32L2A31A
√
√
√
K32L2A41A
√
√
√
K32L2B11A
√
√
√
K32L2B21A
√
√
√
K32L2B31A
√
√
√
K32L3A60
√
√
√
LPC51U68
√
√
√
LPC54005
√
√
√
LPC54016
√
√
√
LPC54018M
√
√
√
LPC54018
√
√
√
LPC54102
√
√
√
LPC54113
√
√
√
LPC54114
√
√
√
√
√
LPC54605
√
√
√
LPC54606
√
√
√
LPC54607
√
√
√
LPC54608
√
√
√
LPC54616
√
√
√
LPC54618
√
√
√
LPC54628
√
√
√
LPC54S005
√
√
√
LPC54S016
√
√
√
LPC54S018M
√
√
√
LPC54S018
√
√
√
LPC5502
√
√
√
LPC5504
√
√
√
LPC5506
√
√
√
LPC5512
√
√
√
LPC5514
√
√
√
LPC5516
√
√
√
LPC5526
√
√
√
LPC5528
√
√
√
LPC5534
√
√
√
LPC5536
√
√
√
LPC55S04
√
√
√
LPC55S06
√
√
√
LPC55S14
√
√
√
LPC55S16
√
√
√
LPC55S26
√
√
√
LPC55S28
√
√
√
LPC55S36
√
√
√
LPC55S66
√
√
√
LPC55S69
√
√
√
MIMX8MD6
√
√
√
MIMX8MD7
√
√
√
MIMX8MQ5
√
√
√
MIMX8MQ6
√
√
√
MIMX8MQ7
√
√
√
MIMXRT1011
√
√
√
MIMXRT1015
√
√
√
MIMXRT1021
√
√
√
√
√
MIMXRT1024
√
√
√
√
√
MIMXRT1051
√
√
√
√
√
MIMXRT1052
√
√
√
√
√
MIMXRT1061
√
√
√
MIMXRT1061X
√
√
√
MIMXRT1062
√
√
√
√
√
MIMXRT1062X
√
√
√
√
√
MIMXRT1064
√
√
√
√
√
MIMXRT1165
√
√
√
√
√
MIMXRT1166
√
√
√
√
√
MIMXRT1173
√
√
√
√
√
MIMXRT1175
√
√
√
√
√
MIMXRT1176
√
√
√
√
√
MIMXRT533S
√
√
√
MIMXRT555S
√
√
√
MIMXRT595S
√
√
√
MIMXRT633S
√
√
√
MIMXRT685S
√
√
√
MK02F12810
√
√
√
MK11D5
√
√
√
MK11DA5
√
√
√
MK12D5
√
√
√
MK21D5
√
√
√
MK21DA5
√
√
√
MK21F12
√
√
√
MK21FA12
√
√
√
MK22D5
√
√
√
MK22F12810
√
√
√
MK22F12
√
√
√
MK22F25612
√
√
√
MK22F51212
√
√
√
MK22FA12
√
√
√
MK24F12
√
√
√
MK24F25612
√
√
√
MK26F18
√
√
√
MK27F15
√
√
√
MK27FA15
√
√
√
MK28F15
√
√
√
MK28FA15
√
√
√
MK63F12
√
√
√
MK64F12
√
√
√
√
√
√
√
√
MK65F18
√
√
√
MK66F18
√
√
√
MK80F25615
√
√
√
MK82F25615
√
√
√
MKE02Z4
√
√
√
MKE04Z1284
√
√
√
MKE04Z4
√
√
√
MKE06Z4
√
√
√
MKE12Z7
√
√
√
MKE13Z7
√
√
√
MKE14F16
√
√
√
MKE14Z4
√
√
√
MKE14Z7
√
√
√
MKE15Z4
√
√
√
MKE15Z7
√
√
√
MKE16F16
√
√
√
MKE16Z4
√
√
√
MKE17Z7
√
√
√
MKE18F16
√
√
√
MKL02Z4
√
√
√
MKL03Z4
√
√
√
MKL13Z644
√
√
√
MKL17Z4
√
√
√
MKL17Z644
√
√
√
MKL26Z4
√
√
√
MKL27Z4
√
√
√
MKL27Z644
√
√
√
MKL28Z7
√
√
√
MKL33Z4
√
√
√
MKL33Z644
√
√
√
MKL34Z4
√
√
√
MKL36Z4
√
√
√
MKL43Z4
√
√
√
MKL46Z4
√
√
√
MKL82Z7
√
√
√
MKM14ZA5
√
√
√
MKM33ZA5
√
√
√
MKM34Z7
√
√
√
MKM34ZA5
√
√
√
MKM35Z7
√
√
√
MKS20F12
√
√
√
MKS22F12
√
√
√
MKV10Z1287
√
√
√
MKV10Z7
√
√
√
MKV11Z7
√
√
√
MKV30F12810
√
√
√
MKV31F12810
√
√
√
MKV31F25612
√
√
√
MKV31F51212
√
√
√
MKV42F16
√
√
√
MKV44F16
√
√
√
MKV46F16
√
√
√
MKV56F24
√
√
√
MKV58F24
√
√
√
S32K3
√
Qualcomm QCA400x
√
Redpine RS13100
√
√
√
√
√
√
RS14100
√
√
√
√
√
√
√
√
√
Renesas AT45DB641E
√
AT45DB642D
√
DA16200
√
STMicroelectronics STM32F0xx
√
√
√
√
√
STM32F1xx
√
√
√
√
√
√
√
√
STM32F2xx
√
√
√
√
√
√
√
√
STM32F3xx
√
√
√
√
√
STM32F4xx
√
√
√
√
√
√
√
√
STM32F7xx
√
√
√
√
√
√
√
√
√
STM32G0xx
√
STM32G4xx
√
√
√
STM32H7xx
√
√
√
√
√
√
√
√
√
STM32L0xx
√
√
√
√
STM32L1xx
√
STM32L4xx
√
√
√
√
√
√
STM32L5xx
√
√
√
STM32U5xx
√
√
√
ST802RT1
√
Texas Instruments DP82848C
√
WizNet WizFi360
√
*/ /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/ /** \page theoryOperation Theory of Operation [TOC] This section gives an overview of the general operation of CMSIS-Drivers. It explains the \ref DriverFunctions that are common in all CMSIS-Drivers along with the \ref CallSequence. The topic \ref Data_Xfer_Functions describes how data read/write operations to the peripheral are implemented. Each CMSIS-Driver defines an \ref AccessStruct for calling the various driver functions and each peripheral (that is accessed via a CMSIS-Driver) has one \ref DriverInstances "Driver Instance". \section DriverFunctions Common Driver Functions Each CMSIS-Driver contains these functions: - \b GetVersion: can be called at any time to obtain version information of the driver interface. - \b GetCapabilities: can be called at any time to obtain capabilities of the driver interface. - \b Initialize: must be called before powering the peripheral using \b PowerControl. This function performs the following: - allocate I/O resources. - register an optional \b SignalEvent callback function. - \b SignalEvent: is an optional callback function that is registered with the \b Initialize function. This callback function is initiated from interrupt service routines and indicates hardware events or the completion of a data block transfer operation. - \b PowerControl: Controls the power profile of the peripheral and needs to be called after \b Initialize. Typically, three power options are available: - \c ARM_POWER_FULL: Peripheral is turned on and fully operational. The driver initializes the peripheral registers, interrupts, and (optionally) DMA. - \c ARM_POWER_LOW: (optional) Peripheral is in low power mode and partially operational; usually, it can detect external events and wake-up. - \c ARM_POWER_OFF: Peripheral is turned off and not operational (pending operations are terminated). This is the state after device reset. - \b Uninitialize: Complementary function to Initialize. Releases the I/O pin resources used by the interface. - \b Control: Several drivers provide a control function to configure communication parameters or execute miscellaneous control functions. The section \ref CallSequence contains more information on the operation of each function. Additional functions are specific to each driver interface and are described in the individual sections of each driver. \subsection ProcessorMode Cortex-M Processor Mode The CMSIS-Driver functions access peripherals and interrupts and are designed to execute in \b Privileged mode. When calling CMSIS-Driver functions from RTOS threads, it should be ensure that these threads execute in \b Privileged mode. \section CallSequence Function Call Sequence For normal operation of the driver, the API functions \b GetVersion, \b GetCapabilities, \b Initialize, \b PowerControl, \b Uninitialize are called in the following order: \msc a [label="", textcolor="indigo", linecolor="indigo", arclinecolor="indigo"], b [label="", textcolor="blue", linecolor="blue", arclinecolor="blue"]; a rbox a [label="Middleware", linecolor="indigo"], b rbox b [label="Driver", linecolor="blue"]; --- [label="Verify API version"]; a=>b [label="GetVersion ()", textcolor="gray", linecolor="gray"]; --- [label="Obtain driver features"]; a=>b [label="GetCapabilities (...)", textcolor="gray", linecolor="gray"]; --- [label="Setup software resources"]; a=>b [label="Initialize (...)", textcolor="red", linecolor="red"]; --- [label="Setup the peripheral"]; a=>b [label="PowerControl (ARM_POWER_FULL)", textcolor="red", linecolor="red"]; --- [label="Operate with the peripheral"]; a=>b [label="Data Transfer Functions"]; a<=b [label="SignalEvent (...)"]; --- [label="Wait for external hardware events"]; a=>b [label="PowerControl (ARM_POWER_LOW)"]; a<=b [label="SignalEvent (...)"]; --- [label="Stop working with peripheral"]; a=>b [label="PowerControl (ARM_POWER_OFF)", textcolor="red", linecolor="red"]; a=>b [label="Uninitialize (...)", textcolor="red", linecolor="red"]; \endmsc The functions \b GetVersion and \b GetCapabilities can be called any time to obtain the required information from the driver. These functions return always the same information. \subsection CS_start Start Sequence To start working with a peripheral the functions \b Initialize and \b PowerControl need to be called in this order: \code drv->Initialize (...); // Allocate I/O pins drv->PowerControl (ARM_POWER_FULL); // Power up peripheral, setup IRQ/DMA \endcode - \b Initialize typically allocates the I/O resources (pins) for the peripheral. The function can be called multiple times; if the I/O resources are already initialized it performs no operation and just returns with \ref ARM_DRIVER_OK. - \b PowerControl (\c ARM_POWER_FULL) sets the peripheral registers including interrupt (NVIC) and optionally DMA. The function can be called multiple times; if the registers are already set it performs no operation and just returns with \ref ARM_DRIVER_OK. \subsection CS_stop Stop Sequence To stop working with a peripheral the functions \b PowerControl and \b Uninitialize need to be called in this order: \code drv->PowerControl (ARM_POWER_OFF); // Terminate any pending transfers, reset IRQ/DMA, power off peripheral drv->Uninitialize (...); // Release I/O pins \endcode The functions \b PowerControl and \b Uninitialize always execute and can be used to put the peripheral into a Safe State, for example after any data transmission errors. To restart the peripheral in a error condition, you should first execute the \ref CS_stop and then the \ref CS_start. - \b PowerControl (\c ARM_POWER_OFF) terminates any pending data transfers with the peripheral, disables the peripheral and leaves it in a defined mode (typically the reset state). - when DMA is used it is disabled (including the interrupts) - peripheral interrupts are disabled on NVIC level - the peripheral is reset using a dedicated reset mechanism (if available) or by clearing the peripheral registers - pending peripheral interrupts are cleared on NVIC level - driver variables are cleared - \b Uninitialize always releases I/O pin resources. \section Share_IO Shared I/O Pins All CMSIS-Driver provide a \ref CS_start and \ref CS_stop. Therefore two different drivers can share the same I/O pins, for example UART1 and SPI1 can have overlapping I/O pins. In this case the communication channels can be used as shown below: \code SPI1drv->Initialize (...); // Start SPI1 SPI1drv->PowerControl (ARM_POWER_FULL); ... // Do operations with SPI1 SPI1drv->PowerControl (ARM_POWER_OFF); // Stop SPI1 SPI1drv->Uninitialize (); ... USART1drv->Initialize (...); // Start USART1 USART1drv->PowerControl (ARM_POWER_FULL); ... // Do operations with USART1 USART1drv->PowerControl (ARM_POWER_OFF); // Stop USART1 USART1drv->Uninitialize (); \endcode \section Data_Xfer_Functions Data Transfer Functions A CMSIS-Driver implements non-blocking functions to transfer data to a peripheral. This means that the driver configures the read or write access to the peripheral and instantly returns to the calling application. The function names for data transfer end with: - \b Send to write data to a peripheral. - \b Receive to read data from a peripheral. - \b Transfer to indicate combined read/write operations to a peripheral. During a data transfer, the application can query the number of transferred data items using functions named GetxxxCount. On completion of a data transfer, the driver calls a callback function with a specific event code. During the data exchange with the peripheral, the application can decide to: - Wait (using an RTOS scheduler) for the callback completion event. The RTOS is controlled by the application code which makes the driver itself RTOS independent. - Use polling functions that return the number of transferred data items to show progress information or partly read or fill data transfer buffers. - Prepare another data transfer buffer for the next data transfer. The following diagram shows the basic communication flow when using the \b _Send function in an application. \image html Non_blocking_transmit_small.png "Non-blocking Send Function" \section AccessStruct Access Struct A CMSIS-Driver publishes an \ref AccessStruct with the data type name ARM_DRIVER_xxxx that gives to access the driver functions. \b Code \b Example: \b Function \b Access \b of \b the \b SPI \b driver \code typedef struct _ARM_DRIVER_SPI { ARM_DRIVER_VERSION (*GetVersion) (void); ARM_SPI_CAPABILITIES (*GetCapabilities) (void); int32_t (*Initialize) (ARM_SPI_SignalEvent_t cb_event); int32_t (*Uninitialize) (void); int32_t (*PowerControl) (ARM_POWER_STATE state); int32_t (*Send) (const void *data, uint32_t num); int32_t (*Receive) ( void *data, uint32_t num); int32_t (*Transfer) (const void *data_out, void *data_in, uint32_t num); uint32_t (*GetDataCount) (void); int32_t (*Control) (uint32_t control, uint32_t arg); ARM_SPI_STATUS (*GetStatus) (void); } const ARM_DRIVER_SPI; \endcode \subsection DriverInstances Driver Instances A device may offer several peripherals of the same type. For such devices, the CMSIS-Driver publishes multiple instances of the \ref AccessStruct. The name of each driver instance reflects the names of the peripheral available in the device. \b Code \b Example: \ref AccessStruct \b for \b three \b SPIs \b in \b a \b microcontroller \b device. \code ARM_DRIVER_SPI Driver_SPI1; // access functions for SPI1 interface ARM_DRIVER_SPI Driver_SPI2; // access functions for SPI2 interface ARM_DRIVER_SPI Driver_SPI3; // access functions for SPI3 interface \endcode The access functions can be passed to middleware to specify the driver instance that the middleware should use for communication. \b Naming \b Convention The access structs need to follow this naming convention: the keyword "Driver" followed by an underscore "_", the interface name "IFNAME" (usually in upper case letters), and the instance number "n". Here's the full list of access struct names for all drivers (n to be replaced with the actual instance number): \code Driver_CANn Driver_ETH_MACn Driver_ETH_PHYn Driver_Flashn Driver_I2Cn Driver_MCIn Driver_NANDn Driver_SAIn Driver_SPIn Driver_Storagen Driver_USARTn Driver_USBDn Driver_USBHn Driver_WiFin \endcode \b Example: \code void init_middleware (ARM_DRIVER_SPI *Drv_spi) ... \\ inside the middleware the SPI driver functions are called with: \\ Drv_spi->function (...); \endcode \code \\ setup middleware init_middleware (&Driver_SPI1); // connect middleware to SPI1 interface : init_middleware (&Driver_SPI2); // connect middleware to SPI2 interface \endcode \section DriverConfiguration Driver Configuration For a device family, the drivers may be configurable. The \ref referenceImplementation stores configuration options in a central file with the name \b RTE_Device.h. However, the configuration of the drivers itself is not part of the CMSIS-Driver specification. \section CodeExample Code Example The following example code shows the usage of the SPI interface. \include SPI_Demo.c */ /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/ /** \page referenceImplementation Reference Implementation The API of the CMSIS-Drivers is published in the \ref DriverHeaderFiles. To simplify the development of a CMSIS-Driver both \ref DriverTemplates and \ref DriverExamples are provided. ARM offers also a Software Pack for CMSIS-Driver Validation as described in \ref driverValidation. \section DriverHeaderFiles Driver Header Files The API of each CMSIS-Driver is published in a header file. It is recommended to include the header file that is part of the CMSIS specification in the implementation file of the CMSIS-Driver. The following header files are available in the directory .\\CMSIS\\Driver\\Include. | Header File | Description |----------------------|------------------------- | %Driver_Common.h | \ref common_drv_gr | %Driver_CAN.h | \ref can_interface_gr | %Driver_ETH.h | \ref eth_interface_gr | %Driver_ETH_MAC.h | \ref eth_mac_interface_gr | %Driver_ETH_PHY.h | \ref eth_phy_interface_gr | %Driver_Flash.h | \ref flash_interface_gr | %Driver_I2C.h | \ref i2c_interface_gr | %Driver_MCI.h | \ref mci_interface_gr | %Driver_NAND.h | \ref nand_interface_gr | %Driver_SPI.h | \ref spi_interface_gr | %Driver_Storage.h | \ref storage_interface_gr | %Driver_SAI.h | \ref sai_interface_gr | %Driver_USART.h | \ref usart_interface_gr | %Driver_USB.h | \ref usb_interface_gr | %Driver_USBD.h | \ref usbd_interface_gr | %Driver_USBH.h | \ref usbh_interface_gr | %Driver_WiFi.h | \ref wifi_interface_gr \section DriverTemplates Driver Template Files Driver template files are code skeletons that provide the structure of a CMSIS-Driver. The following templates are available in the directory .\\CMSIS\\Driver\\DriverTemplates. | Source File | Description |-------------------|------------------------------------ | %Driver_CAN.c | \ref can_interface_gr | %Driver_ETH_MAC.c | \ref eth_mac_interface_gr | %Driver_ETH_PHY.c | \ref eth_mac_interface_gr | %Driver_Flash.c | \ref flash_interface_gr | %Driver_I2C.c | \ref i2c_interface_gr | %Driver_MCI.c | \ref mci_interface_gr | %Driver_SAI.c | \ref sai_interface_gr | %Driver_SPI.c | \ref spi_interface_gr | %Driver_Storage.c | \ref storage_interface_gr | %Driver_USART.c | \ref usart_interface_gr | %Driver_USBD.c | \ref usbd_interface_gr | %Driver_USBH.c | \ref usbh_interface_gr \section DriverExamples Driver Examples The driver examples are full working CMSIS-Drivers that may be adapted to a different hardware. Examples are currently available for the NXP LPC1800 series and provide the implementation of a complete CMSIS-Driver. The following examples are available in the directory .\\CMSIS\\Pack\\Example\\CMSIS_Driver. | Source File | Header File | Description |-------------------|-------------------|------------------------------- | %EMAC_LPC18xx.c | %EMAC_LPC18xx.h | \ref eth_mac_interface_gr | %SSP_LPC18xx.c | %SSP_LPC18xx.h | \ref spi_interface_gr | %I2C_LPC18xx.c | %I2C_LPC18xx.h | \ref i2c_interface_gr | %I2S_LPC18xx.c | %I2S_LPC18xx.h | \ref sai_interface_gr | %MCI_LPC18xx.c | %MCI_LPC18xx.h | \ref mci_interface_gr | %USART_LPC18xx.c | %USART_LPC18xx.h | \ref usart_interface_gr | %USBn_LPC18xx.c | %USB_LPC18xx.h | common files for \ref usbd_interface_gr and \ref usbh_interface_gr | %USBDn_LPC18xx.c | none | \ref usbd_interface_gr | %USBHn_LPC18xx.c | none | \ref usbh_interface_gr These CMSIS-Drivers use additional modules for GPIO and DMA control: | Source File | Header File | Description |-------------------|------------------|--------------------------------------- | %GPIO_LPC18xx.c | %GPIO_LPC18xx.h | GPIO Interface for LPC1800 series | %GPDMA_LPC18xx.c | none | DMA Interface for LPC1800 series | %SCU_LPC18xx.c | %SCU_LPC18xx.h | SCU Interface for LPC1800 series The CMSIS-Drivers for the LPC1800 device have also many configuration options that are controls using \#define statements in the file .\\CMSIS\\Pack\\Example\\CMSIS_Driver\\Config\\RTE_Device.h. Using this file, the I/O pin and DMA assignment can be set among other parameters such as USB speed and PHY interfaces. Further driver reference implementations are available in Device Family Packs (DFP) labeled with version 2.0.0 or higher. */ /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/ /** \page driverValidation Driver Validation The Software Pack named ARM::CMSIS-Driver_Validation contains the following: - Source code of a CMSIS-Driver Validation Suite along with configuration file. - Documentation of the CMSIS-Driver Validation Suite. - Examples that shows the usage of the CMSIS-Driver Validation Suite on various target platforms. The CMSIS-Driver Validation Suite performs the following tests: - Generic Validation of API function calls - Validation of Configuration Parameters - Validation of Communication with loopback tests - Validation of Communication Parameters such as baudrate - Validation of Event functions The following CMSIS-Drivers can be tested with the current release: - \ref can_interface_gr : with loop back test of communication. - \ref eth_interface_gr : MAC and PHY with loop back test of communication. - \ref i2c_interface_gr : only API and setup; does not test data transfer. - \ref mci_interface_gr : only API and setup; does not test data transfer. - \ref spi_interface_gr : with loop back test of communication. - \ref usart_interface_gr : with loop back test of communication. - \ref usbd_interface_gr : only API and setup; does not test data transfer. - \ref usbh_interface_gr : only API and setup; does not test data transfer. - \ref wifi_interface_gr : extensive tests for WiFi Driver. The Driver Validation output can be printed to a console or saved in an XML file, via standard output (usually ITM). \section test_output Sample Test Output \verbatim CMSIS-Driver USART Test Report Dec 6 2019 11:44:30 TEST 01: USART_GetCapabilities PASSED TEST 02: USART_Initialization PASSED TEST 03: USART_PowerControl DV_USART.c (301): [WARNING] Low power is not supported PASSED TEST 04: USART_Config_PolarityPhase PASSED TEST 05: USART_Config_DataBits DV_USART.c (387): [WARNING] Data Bits = 9 are not supported PASSED TEST 06: USART_Config_StopBits DV_USART.c (425): [WARNING] Stop Bits = 1.5 are not supported DV_USART.c (429): [WARNING] Stop Bits = 0.5 are not supported PASSED TEST 07: USART_Config_Parity PASSED TEST 08: USART_Config_Baudrate PASSED TEST 09: USART_Config_CommonParams PASSED TEST 10: USART_Send PASSED TEST 11: USART_AsynchronousReceive PASSED TEST 12: USART_Loopback_CheckBaudrate PASSED TEST 13: USART_Loopback_Transfer PASSED TEST 14: USART_CheckInvalidInit PASSED Test Summary: 14 Tests, 14 Passed, 0 Failed. Test Result: PASSED \endverbatim \section loop_back_setup Setup for Loop Back Communication To perform loop back communication tests it is required to connect the input and the output of the peripherals as shown in this table: Peripheral | Loop Back Configuration :----------------|:---------------------------- Ethernet | Connect TX+ (Pin 1) with RX+ (Pin 3), TX- (Pin 2) with RX- (Pin 6) SPI | Connect MISO to MOSI USART | Connect TX with RX The following picture shows the necessary external loop back connections for the Keil MCBSTM32F400 evaluation board: - SPI: PB14 (SPI2_MISO) and PB15 (SPI2_MOSI) - USART: PB6 (USART1_TX) and PB7 (USART1_RX) - Ethernet: Pin 1 (TX+) and Pin 3 (RX+), Pin 2 (TX-) and Pin 6 (RX-) \image html image006.png "Connections for Loop Back Communication Tests on Keil MCBSTM32F400" */