begriffs open source - cmsis/blob - CMSIS/DoxyGen/Driver/src/General.txt

   1 /**
   2 \mainpage Overview
   3
   4 The CMSIS-Driver specification is a software API that describes peripheral driver interfaces for middleware stacks and user
   5 applications. The CMSIS-Driver API is designed to be generic and independent of a specific RTOS making it reusable across a
   6 wide range of supported microcontroller devices. The CMSIS-Driver API covers a wide range of use cases for the supported
   7 peripheral types, but can not take every potential use-case into account. Over time, it is indented to extend the
   8 CMSIS-Driver API with further groups to cover new use-cases.
   9
  10 The CMSIS Software Pack publishes the API Interface under the Component Class \b CMSIS \b Driver with header files and a
  11 documentation. These header files are the reference for the implementation of the standardized peripheral driver interfaces.
  12 These implementations are published typically in the Device Family Pack of a related microcontroller family under the
  13 Component Class \b CMSIS \b Driver. A Device Family Pack may contain additional interfaces in the Component Class \b Device
  14 to extend the standard Peripheral Drivers covered by this CMSIS-Driver specification with additional device specific
  15 interfaces for example for Memory BUS, GPIO, or DMA.
  16
  17 The standard peripheral driver interfaces connect microcontroller peripherals for example with middleware that implements
  18 communication stacks, file systems, or graphic user interfaces. Each peripheral driver interface may provide multiple
  19 instances reflecting the multiple physical interfaces of the same type in a device. For example the two physical SPI
  20 interfaces are reflected with a separate \ref AccessStruct for SPI1 and SPI2. The \ref AccessStruct is the interface of a
  21 driver to the middleware component or the user application.
  22
  23 \image html Driver.png  "Peripheral Driver Interfaces and Middleware"
  24
  25 The following CMSIS-Driver API groups are defined:
  26   - \ref can_interface_gr "CAN": Interface to CAN bus peripheral.
  27   - \ref eth_interface_gr "Ethernet": Interface to Ethernet MAC and PHY peripheral.
  28   - \ref i2c_interface_gr "I2C": Multi-master Serial Single-Ended Bus interface driver.
  29   - \ref mci_interface_gr "MCI": Memory Card Interface for SD/MMC memory.
  30   - \ref nand_interface_gr "NAND": NAND Flash Memory interface driver.
  31   - \ref flash_interface_gr "Flash": Flash Memory interface driver.
  32   - \ref sai_interface_gr "SAI": Serial audio interface driver (I2s, PCM, AC'97, TDM, MSB/LSB Justified).
  33   - \ref spi_interface_gr "SPI": Serial Peripheral Interface Bus driver.
  34   - \ref storage_interface_gr "Storage": Storage device interface driver.
  35   - \ref usart_interface_gr "USART": Universal Synchronous and Asynchronous Receiver/Transmitter interface driver.
  36   - \ref usb_interface_gr "USB": Interface driver for USB Host and USB Device communication.
  37   - \ref wifi_interface_gr "WiFi": Interface driver for wireless communication.
  38
  39 <hr>
  40
  41 CMSIS-Driver in ARM::CMSIS Pack
  42 -------------------------------
  43
  44 The following files relevant to CMSIS-Driver are present in the <b>ARM::CMSIS</b> Pack directories:
  45 | Directory                      | Content                                                                |
  46 |--------------------------------|------------------------------------------------------------------------|
  47 |\b CMSIS/Documentation/Driver   | This documentation                                                     |
  48 |\b CMSIS/Driver/Include         | Driver header files (Driver_<i>interface</i>.h, Driver_Common.h)       |
  49 |\b CMSIS/Driver/DriverTemplates | Driver implementation template files (Driver_<i>interface</i>.c)       |
  50
  51 <hr>
  52 */
  53
  54 /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
  55 /**
  56 \page driver_revisionHistory Revision History of CMSIS-Driver
  57
  58
  59 <table class="cmtable" summary="Revision History">
  60     <tr>
  61       <th>Version</th>
  62       <th>Description</th>
  63     </tr>
  64     <tr>
  65       <td>2.7.0</td>
  66       <td>Modifications compared to Version 2.6.0:
  67         - Added WiFi Interface API 1.0.0-beta.
  68         - Added custom driver selection to simplify implementation of new CMSIS-Driver.
  69       </td>
  70     </tr>
  71     <tr>
  72       <td>2.6.0</td>
  73       <td>Modifications compared to Version 2.05:
  74 - Enhanced CAN-Driver API with explicit BUSOFF state.
  75 - Enhanced NAND-Driver API for ECC handling.
  76       </td>
  77     </tr>
  78     <tr>
  79       <td>2.05</td>
  80       <td>Modifications compared to Version 2.04:
  81  - Changed: All typedefs related to status have been made volatile.
  82       </td>
  83     </tr>
  84     <tr>
  85       <td>2.04</td>
  86       <td>Modifications compared to Version 2.03:
  87  - Added: template files for CAN interface driver.
  88       </td>
  89     </tr>
  90     <tr>
  91       <td>2.03</td>
  92       <td>Modifications compared to Version 2.02:
  93  - Added: CAN API for an interface to CAN peripherals
  94  - Added: Overview of the \ref driverValidation "CMSIS-Driver Validation" Software Pack.
  95  - Enhanced: documentation and clarified behavior of the \ref CallSequence.
  96       </td>
  97     </tr>
  98     <tr>
  99       <td>2.02</td>
 100       <td>Modifications compared to Version 2.00:
 101  - Minor API changes, for exact details refer to the header file of each driver.
 102  - Added: Flash Interface, NAND interface.
 103       </td>
 104     </tr>
 105     <tr>
 106       <td>2.00</td>
 107       <td>API with non-blocking data transfer, independent of CMSIS-RTOS.</td>
 108     </tr>
 109     <tr>
 110       <td>1.10</td>
 111       <td>Initial release</td>
 112     </tr>
 113 </table>
 114 */
 115
 116 /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
 117 /**
 118 \page theoryOperation Theory of Operation
 119
 120 [TOC]
 121
 122 This section gives an overview of the general operation of CMSIS-Drivers. It explains the \ref DriverFunctions that are
 123 common in all CMSIS-Drivers along with the \ref CallSequence. The topic \ref Data_Xfer_Functions describes how data
 124 read/write operations to the peripheral are implemented.
 125
 126 Each CMSIS-Driver defines an \ref AccessStruct for calling the various driver functions and each peripheral (that is accessed
 127 via a CMSIS-Driver) has one \ref DriverInstances "Driver Instance".
 128
 129
 130 \section DriverFunctions Common Driver Functions
 131
 132 Each CMSIS-Driver contains these functions:
 133
 134  - \b GetVersion: can be called at any time to obtain version information of the driver interface.
 135
 136  - \b GetCapabilities: can be called at any time to obtain capabilities of the driver interface.
 137
 138  - \b Initialize: must be called before powering the peripheral using \b PowerControl. This function performs the following:
 139      - allocate I/O resources.
 140          - register an optional \b SignalEvent callback function.
 141
 142  - \b SignalEvent: is an optional callback function that is registered with the \b Initialize function. This callback
 143    function is initiated from interrupt service routines and indicates hardware events or the completion of a data block
 144    transfer operation.
 145
 146  - \b PowerControl: Controls the power profile of the peripheral and needs to be called after \b Initialize. Typically, three
 147    power options are available:
 148      - \c ARM_POWER_FULL: Peripheral is turned on and fully operational. The driver initializes the peripheral registers, interrupts, and (optionally) DMA.
 149      - \c ARM_POWER_LOW: (optional) Peripheral is in low power mode and partially operational; usually, it can detect
 150        external events and wake-up.
 151      - \c ARM_POWER_OFF: Peripheral is turned off and not operational (pending operations are terminated). This is the state
 152        after device reset.
 153
 154  - \b Uninitialize: Complementary function to Initialize. Releases the I/O pin resources used by the interface.
 155
 156  - \b Control: Several drivers provide a control function to configure communication parameters or execute miscellaneous
 157    control functions.
 158
 159 The section \ref CallSequence contains more information on the operation of each function. Additional functions are specific
 160 to each driver interface and are described in the individual sections of each driver.
 161
 162 \subsection ProcessorMode Cortex-M Processor Mode
 163
 164 The CMSIS-Driver functions access peripherals and interrupts and are designed to execute in \b Privileged mode.
 165 When calling CMSIS-Driver functions from RTOS threads, it should be ensure that these threads execute in \b Privileged mode.
 166
 167
 168 \section CallSequence Function Call Sequence
 169
 170 For normal operation of the driver, the API functions \b GetVersion, \b GetCapabilities, \b Initialize, \b PowerControl, \b Uninitialize are
 171 called in the following order:
 172
 173 \msc
 174  a [label="", textcolor="indigo", linecolor="indigo", arclinecolor="indigo"],
 175  b [label="", textcolor="blue", linecolor="blue", arclinecolor="blue"];
 176
 177  a rbox a [label="Middleware", linecolor="indigo"],
 178  b rbox b [label="Driver", linecolor="blue"];
 179  --- [label="Verify API version"];
 180  a=>b [label="GetVersion ()", textcolor="gray", linecolor="gray"];
 181  --- [label="Obtain driver features"];
 182  a=>b [label="GetCapabilities (...)", textcolor="gray", linecolor="gray"];
 183  ---  [label="Setup software resources"];
 184  a=>b [label="Initialize (...)", textcolor="red", linecolor="red"];
 185  --- [label="Setup the peripheral"];
 186  a=>b  [label="PowerControl (ARM_POWER_FULL)", textcolor="red", linecolor="red"];
 187  --- [label="Operate with the peripheral"];
 188  a=>b [label="Data Transfer Functions"];
 189  a<=b  [label="SignalEvent (...)"];
 190  --- [label="Wait for external hardware events"];
 191  a=>b  [label="PowerControl (ARM_POWER_LOW)"];
 192  a<=b  [label="SignalEvent (...)"];
 193  --- [label="Stop working with peripheral"];
 194  a=>b [label="PowerControl (ARM_POWER_OFF)", textcolor="red", linecolor="red"];
 195  a=>b [label="Uninitialize (...)", textcolor="red", linecolor="red"];
 196 \endmsc
 197
 198 The functions \b GetVersion and \b GetCapabilities can be called any time to obtain the required information from the driver.
 199 These functions return always the same information.
 200
 201
 202 \subsection CS_start Start Sequence
 203
 204 To start working with a peripheral the functions \b Initialize and \b PowerControl need to be called in this order:
 205 \code
 206   drv->Initialize (...);                 // Allocate I/O pins
 207   drv->PowerControl (ARM_POWER_FULL);    // Power up peripheral, setup IRQ/DMA
 208 \endcode
 209
 210 - \b Initialize typically allocates the I/O resources (pins) for the peripheral. The function can be called multiple times;
 211   if the I/O resources are already initialized it performs no operation and just returns with \ref ARM_DRIVER_OK.
 212 - \b PowerControl (\c ARM_POWER_FULL) sets the peripheral registers including interrupt (NVIC) and optionally DMA.
 213   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.
 214
 215 \subsection CS_stop Stop Sequence
 216
 217 To stop working with a peripheral the functions \b PowerControl and \b Uninitialize need to be called in this order:
 218 \code
 219   drv->PowerControl (ARM_POWER_OFF);     // Terminate any pending transfers, reset IRQ/DMA, power off peripheral
 220   drv->Uninitialize (...);               // Release I/O pins
 221 \endcode
 222 The functions \b PowerControl and \b Uninitialize always execute and can be used to put the peripheral into a <b>Safe State</b>,
 223 for example after any data transmission errors.  To restart the peripheral in a error condition, you should first execute
 224 the \ref CS_stop and then the \ref CS_start.
 225
 226 - \b PowerControl (\c ARM_POWER_OFF) terminates any pending data transfers with the peripheral, disables the peripheral and
 227   leaves it in a defined mode (typically the reset state).
 228     - when DMA is used it is disabled (including the interrupts)
 229     - peripheral interrupts are disabled on NVIC level
 230     - the peripheral is reset using a dedicated reset mechanism (if available) or by clearing the peripheral registers
 231     - pending peripheral interrupts are cleared on NVIC level
 232     - driver variables are cleared
 233 - \b Uninitialize always releases I/O pin resources.
 234
 235 \section Share_IO Shared I/O Pins
 236
 237 All CMSIS-Driver provide a \ref CS_start and \ref CS_stop. Therefore two different drivers can share the same I/O pins,
 238 for example UART1 and SPI1 can have overlapping I/O pins. In this case the communication channels can be used as shown below:
 239
 240 \code
 241   SPI1drv->Initialize (...);                // Start SPI1
 242   SPI1drv->PowerControl (ARM_POWER_FULL);
 243    ...                                      // Do operations with SPI1
 244   SPI1drv->PowerControl (ARM_POWER_OFF);    // Stop SPI1
 245   SPI1drv->Uninitialize ();
 246    ...
 247   USART1drv->Initialize (...);              // Start USART1
 248   USART1drv->PowerControl (ARM_POWER_FULL);
 249    ...                                      // Do operations with USART1
 250   USART1drv->PowerControl (ARM_POWER_OFF);  // Stop USART1
 251   USART1drv->Uninitialize ();
 252 \endcode
 253
 254 \section Data_Xfer_Functions Data Transfer Functions
 255
 256 A CMSIS-Driver implements non-blocking functions to transfer data to a peripheral. This means that the driver configures the
 257 read or write access to the peripheral and instantly returns to the calling application.  The function names for data
 258 transfer end with:
 259  - \b Send to write data to a peripheral.
 260  - \b Receive to read data from a peripheral.
 261  - \b Transfer to indicate combined read/write operations to a peripheral.
 262
 263 During a data transfer, the application can query the number of transferred data items using functions named
 264 <b>Get<i>xxx</i>Count</b>. On completion of a data transfer, the driver calls a callback function with a specific event code.
 265
 266 During the data exchange with the peripheral, the application can decide to:
 267  - Wait (using an RTOS scheduler) for the callback completion event. The RTOS is controlled by the application code which
 268    makes the driver itself RTOS independent.
 269  - Use polling functions that return the number of transferred data items to show progress information or partly read or fill
 270    data transfer buffers.
 271  - Prepare another data transfer buffer for the next data transfer.
 272
 273 The following diagram shows the basic communication flow when using the \b _Send function in an application.
 274
 275 \image html Non_blocking_transmit_small.png  "Non-blocking Send Function"
 276
 277 \section AccessStruct Access Struct
 278
 279 A CMSIS-Driver publishes an \ref AccessStruct with the data type name ARM_DRIVER_xxxx that gives to access the driver
 280 functions.
 281
 282 \b Code \b Example: \b Function \b Access \b of \b the \b SPI \b driver
 283 \code
 284 typedef struct _ARM_DRIVER_SPI {
 285   ARM_DRIVER_VERSION   (*GetVersion)      (void);
 286   ARM_SPI_CAPABILITIES (*GetCapabilities) (void);
 287   int32_t              (*Initialize)      (ARM_SPI_SignalEvent_t cb_event);
 288   int32_t              (*Uninitialize)    (void);
 289   int32_t              (*PowerControl)    (ARM_POWER_STATE state);
 290   int32_t              (*Send)            (const void *data, uint32_t num);
 291   int32_t              (*Receive)         (      void *data, uint32_t num);
 292   int32_t              (*Transfer)        (const void *data_out, void *data_in, uint32_t num);
 293   uint32_t             (*GetDataCount)    (void);
 294   int32_t              (*Control)         (uint32_t control, uint32_t arg);
 295   ARM_SPI_STATUS       (*GetStatus)       (void);
 296 } const ARM_DRIVER_SPI;
 297 \endcode
 298
 299 \subsection DriverInstances Driver Instances
 300
 301 A device may offer several peripherals of the same type. For such devices, the CMSIS-Driver publishes multiple instances
 302 of the \ref AccessStruct. The name of each driver instance reflects the names of the peripheral available in the device.
 303
 304 \b Code \b Example: \ref AccessStruct \b for \b three \b SPIs \b in \b a \b microcontroller \b device.
 305 \code
 306 ARM_DRIVER_SPI Driver_SPI1;     // access functions for SPI1 interface
 307 ARM_DRIVER_SPI Driver_SPI2;     // access functions for SPI2 interface
 308 ARM_DRIVER_SPI Driver_SPI3;     // access functions for SPI3 interface
 309 \endcode
 310
 311 The access functions can be passed to middleware to specify the driver instance that the middleware should use for communication.
 312
 313 \b Example:
 314 \code
 315 void init_middleware (ARM_DRIVER_SPI *Drv_spi) ...
 316 \\ inside the middleware the SPI driver functions are called with:
 317 \\   Drv_spi->function (...);
 318 \endcode
 319
 320 \code
 321 \\ setup middleware
 322 init_middleware (&Driver_SPI1);      // connect middleware to SPI1 interface
 323   :
 324 init_middleware (&Driver_SPI2);      // connect middleware to SPI2 interface
 325 \endcode
 326
 327
 328 \section DriverConfiguration Driver Configuration
 329
 330 For a device family, the drivers may be configurable. The \ref referenceImplementation stores configuration options in a
 331 central file with the name \b RTE_Device.h. However, the configuration of the drivers itself is not part of the CMSIS-Driver
 332 specification.
 333
 334 \section CodeExample Code Example
 335
 336 The following example code shows the usage of the SPI interface.
 337
 338 \include SPI_Demo.c
 339 */
 340
 341 /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
 342 /**
 343 \page referenceImplementation Reference Implementation
 344
 345 The API of the CMSIS-Drivers is published in the \ref DriverHeaderFiles.
 346
 347 To simplify the development of a CMSIS-Driver both \ref DriverTemplates and \ref DriverExamples are provided.
 348
 349 ARM offers also a Software Pack for CMSIS-Driver Validation as described in \ref driverValidation.
 350
 351 \section DriverHeaderFiles Driver Header Files
 352
 353 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
 354 CMSIS specification in the implementation file of the CMSIS-Driver.
 355
 356 The following header files are available in the directory <b>.\\CMSIS\\Driver\\Include</b>.
 357
 358 | Header File          | Description
 359 |----------------------|-------------------------
 360 | %Driver_Common.h     | \ref common_drv_gr
 361 | %Driver_CAN.h        | \ref can_interface_gr
 362 | %Driver_ETH.h        | \ref eth_interface_gr
 363 | %Driver_ETH_MAC.h    | \ref eth_mac_interface_gr
 364 | %Driver_ETH_PHY.h    | \ref eth_phy_interface_gr
 365 | %Driver_Flash.h      | \ref flash_interface_gr
 366 | %Driver_I2C.h        | \ref i2c_interface_gr
 367 | %Driver_MCI.h        | \ref mci_interface_gr
 368 | %Driver_NAND.h       | \ref nand_interface_gr
 369 | %Driver_SPI.h        | \ref spi_interface_gr
 370 | %Driver_Storage.h    | \ref storage_interface_gr
 371 | %Driver_SAI.h        | \ref sai_interface_gr
 372 | %Driver_USART.h      | \ref usart_interface_gr
 373 | %Driver_USB.h        | \ref usb_interface_gr
 374 | %Driver_USBD.h       | \ref usbd_interface_gr
 375 | %Driver_USBH.h       | \ref usbh_interface_gr
 376 | %Driver_WiFi.h       | \ref wifi_interface_gr
 377
 378
 379 \section DriverTemplates Driver Template Files
 380
 381 Driver template files are code skeletons that provide the structure of a CMSIS-Driver.  The following templates are
 382 available in the directory <b>.\\CMSIS\\Driver\\DriverTemplates</b>.
 383
 384 | Source File       | Description
 385 |-------------------|------------------------------------
 386 | %Driver_CAN.c     | \ref can_interface_gr
 387 | %Driver_ETH_MAC.c | \ref eth_mac_interface_gr
 388 | %Driver_ETH_PHY.c | \ref eth_mac_interface_gr
 389 | %Driver_Flash.c   | \ref flash_interface_gr
 390 | %Driver_I2C.c     | \ref i2c_interface_gr
 391 | %Driver_MCI.c     | \ref mci_interface_gr
 392 | %Driver_SAI.c     | \ref sai_interface_gr
 393 | %Driver_SPI.c     | \ref spi_interface_gr
 394 | %Driver_Storage.c | \ref storage_interface_gr
 395 | %Driver_USART.c   | \ref usart_interface_gr
 396 | %Driver_USBD.c    | \ref usbd_interface_gr
 397 | %Driver_USBH.c    | \ref usbh_interface_gr
 398
 399
 400 \section DriverExamples Driver Examples
 401
 402 The driver examples are full working CMSIS-Drivers that may be adapted to a different hardware. Examples are currently
 403 available for the NXP LPC1800 series and provide the implementation of a complete CMSIS-Driver. The following examples are
 404 available in the directory <b>.\\CMSIS\\Pack\\Example\\CMSIS_Driver</b>.
 405
 406 | Source File       | Header File       | Description
 407 |-------------------|-------------------|-------------------------------
 408 | %EMAC_LPC18xx.c   | %EMAC_LPC18xx.h   | \ref eth_mac_interface_gr
 409 | %SSP_LPC18xx.c    | %SSP_LPC18xx.h    | \ref spi_interface_gr
 410 | %I2C_LPC18xx.c    | %I2C_LPC18xx.h    | \ref i2c_interface_gr
 411 | %I2S_LPC18xx.c    | %I2S_LPC18xx.h    | \ref sai_interface_gr
 412 | %MCI_LPC18xx.c    | %MCI_LPC18xx.h    | \ref mci_interface_gr
 413 | %USART_LPC18xx.c  | %USART_LPC18xx.h  | \ref usart_interface_gr
 414 | %USBn_LPC18xx.c   | %USB_LPC18xx.h    | common files for \ref usbd_interface_gr and \ref usbh_interface_gr
 415 | %USBDn_LPC18xx.c  | <i>none</i>       | \ref usbd_interface_gr
 416 | %USBHn_LPC18xx.c  | <i>none</i>       | \ref usbh_interface_gr
 417
 418
 419 These CMSIS-Drivers use additional modules for GPIO and DMA control:
 420
 421 | Source File       | Header File      | Description
 422 |-------------------|------------------|---------------------------------------
 423 | %GPIO_LPC18xx.c   | %GPIO_LPC18xx.h  | GPIO Interface for LPC1800 series
 424 | %GPDMA_LPC18xx.c  | <i>none</i>      | DMA Interface for LPC1800 series
 425 | %SCU_LPC18xx.c    | %SCU_LPC18xx.h   | SCU Interface for LPC1800 series
 426
 427 The CMSIS-Drivers for the LPC1800 device have also many configuration options that are controls using \#define statements in
 428 the file <b>.\\CMSIS\\Pack\\Example\\CMSIS_Driver\\Config\\RTE_Device.h</b>. Using this file, the I/O pin and DMA assignment
 429 can be set among other parameters such as USB speed and PHY interfaces.
 430
 431 Further driver reference implementations are available in Device Family Packs (DFP) labeled with version 2.0.0 or higher.
 432 */
 433
 434 /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
 435 /**
 436 \page driverValidation Driver Validation
 437
 438 The <a href="http://www.keil.com/pack/" target=_blank>Software Pack</a> named <b>ARM::CMSIS-Driver_Validation</b> contains the following:
 439
 440  - Source code of a CMSIS-Driver Validation Suite along with configuration file.
 441  - Documentation of the CMSIS-Driver Validation Suite.
 442  - Examples that shows the usage of the CMSIS-Driver Validation Suite on various target platforms.
 443
 444 The CMSIS-Driver Validation Suite performs the following tests:
 445  - Generic Validation of API function calls
 446  - Validation of Configuration Parameters
 447  - Validation of Communication with loopback tests
 448  - Validation of Communication Parameters such as baudrate
 449  - Validation of Event functions
 450
 451 The following CMSIS-Drivers can be tested with the current release:
 452  - \ref can_interface_gr : with loop back test of communication.
 453  - \ref eth_interface_gr : MAC and PHY with loop back test of communication.
 454  - \ref i2c_interface_gr : only API and setup; does not test data transfer.
 455  - \ref mci_interface_gr : only API and setup; does not test data transfer.
 456  - \ref spi_interface_gr : with loop back test of communication.
 457  - \ref usart_interface_gr : with loop back test of communication.
 458  - \ref usbd_interface_gr : only API and setup; does not test data transfer.
 459  - \ref usbh_interface_gr : only API and setup; does not test data transfer.
 460
 461 The Driver Validation output can printed to a console, output via ITM printf, or output to a memory buffer.
 462
 463 \section test_output Sample Test Output
 464 \verbatim
 465 CMSIS-Driver Test      Aug 24 2015 15:15:14
 466
 467 TEST 01: SPI_GetCapabilities          PASSED
 468 TEST 02: SPI_Initialization
 469   DV_SPI.c(142) - Failed
 470 TEST 03: SPI_PowerControl             NOT EXECUTED
 471   :
 472   :
 473 TEST 23: USART_Send
 474   DV_USART.c(335) - Fail to send 1024 bytes
 475   DV_USART.c(335) - Fail to send 2048 bytes
 476   DV_USART.c(341) - Fail to send without callback 2048 bytes
 477   :
 478   :
 479 Test Summary: 52 Tests: 42 Executed, 22 Failed.
 480   653 Test Cases: 56 Errors(s), 12 Warning(s).
 481 \endverbatim
 482
 483 \section loop_back_setup Setup for Loop Back Communication
 484
 485 To perform loop back communication tests it is required to connect the input and the output of the peripherals as shown in this table:
 486
 487 Peripheral       | Loop Back Configuration
 488 :----------------|:----------------------------
 489 Ethernet         | Connect TX+ (Pin 1) with RX+ (Pin 3), TX- (Pin 2) with RX- (Pin 6)
 490 SPI              | Connect MISO to MOSI
 491 USART            | Connect TX with RX
 492
 493 The following picture shows the necessary external loop back connections for the Keil MCBSTM32F400 evaluation board:
 494  - SPI: PB14 (SPI2_MISO) and PB15 (SPI2_MOSI)
 495  - USART: PB6 (USART1_TX) and PB7 (USART1_RX)
 496  - Ethernet: Pin 1 (TX+) and Pin 3 (RX+), Pin 2 (TX-) and Pin 6 (RX-)
 497
 498 \image html image006.png  "Connections for Loop Back Communication Tests on Keil MCBSTM32F400"
 499
 500
 501 */