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