USART Driver Library - Data Transfer Models for Harmony v2

The Universal Synchronous/Asynchronous Receiver/Transmitter (USART) driver provides three different data transfer models for transferring data:

The Byte-by-Byte Model
The File I/O Type Read/Write Transfer Model
Buffer Queue Transfer Model

Byte-by-Byte Model

The Byte-by-Byte model allows the application to transfer data through the USART driver, one byte at a time. With this model, the driver reads one byte from the receiver First-in First-out (FIFO) or writes one byte to the transmit FIFO. The application must check if data has been received, before reading the data. The application must also check if the transmit FIFO is not full, before writing to the FIFO. The Byte-by-Byte model places the responsibility of maintaining the USART peripheral on the application. The driver cannot support other data transfer models if support for this data transfer model is enabled. The Byte-by-Bytemodel can be used for simple data transfer applications.

The DRV_USART_WriteByte function and the DRV_USART_ReadByte function represent the Byte-by-Byte model.

File I/O Type Read/Write Model

This data transfer model is similar to the File Read/Write model in a UNIX operating system. The application calls the USART driver read/write routines to transfer data through the USART. Unlike the Byte-by-Byte model, this model can process a block of data. Depending on the mode (blocking or non-blocking) in which the client opened the driver, the driver will either block until all of the data is transferred (used only with a Real-Time Operating System (RTOS)) or will immediately return with the number of bytes transferred. The application does not have to check the FIFO status while using this mode. The application can instead use the return status (number of bytes transferred) to maintain its logic and throttle the data transfer to the USART driver.

The driver can support the non-DMA Buffer Queue model along with the File I/O Type Read/Write model. The Byte-by-Byte model and DMA Buffer Queue model cannot be enabled if the File I/O Type Read/Write model is enabled.

The DRV_USART_Read and DRV_USART_Write functions represent the File I/O Type Read/Write model. The functional behavior of these Application Programming Interfaces (APIs) is affected by the mode in which the client opened the driver. If the client opened the driver in blocking mode, then these APIs will block. In Blocking mode (used only with an RTOS), the DRV_USART_Read and DRV_USART_Write functions will not return until the requested number of bytes have been read or written. If the client opened the driver in Non-Blocking mode, then these APIs will not block. In Non-Blocking mode, the DRV_USART_Read and DRV_USART_Write functions will return immediately with the amount of data that could be read or written.

Buffer Queue Transfer Model

The Buffer Queue model allows clients to queue data transfers for processing. This data transfer model is always non-blocking. The USART driver returns a buffer handle for a queued request. The clients can track the completion of a buffer through events and the API. If the USART driver is busy processing a data transfer, other data transfer requests are queued. This allows the clients to optimize their application logic and increase throughput. To optimize memory usage, the USART driver implements a shared buffer object pool concept to add a data transfer request to the queue. The following figure shows a conceptual representation of the Buffer Queue model:

buffer_queue.png

As shown in the figure above, each USART driver hardware instance has a read/write queue. The application must configure the sizes of these read/write queues. The USART driver additionally employs a global pool of buffer queue objects. This pool is common to all USART driver hardware instances and its size is defined by the DRV_USART_QUEUE_DEPTH_COMBINED configuration macro.

When a client places a request to add a data transfer, the driver performs the following actions:

  1. It checks if a buffer object is free in the global pool; if not, the driver rejects the request.
  2. It then checks if the hardware instance-specific queue is full; if not, the buffer object from the global pool is added to the hardware instance-specific queue. If the queue is full, the driver rejects the request.

The API for the DMA and non-DMA Buffer Queue model is the same. The driver can support the non-DMA Buffer model along with the File I/O Type Read Write model. The Byte-by-Byte model cannot be enabled if the Buffer Queue model is enabled.

The USART driver DMA feature is only available while using the Buffer Queue model. If enabled, the USART driver uses the DMA module channels to transfer data directly from the application memory to USART transmit or receive registers. This reduces CPU resource consumption and improves system performance.

The DRV_USART_BufferAddRead and DRV_USART_BufferAddWrite functions represent the Buffer Queue model. These functions are always non-blocking. The Buffer Queue model employs queuing of read/write request. Each driver instance contains a read/write queue. The sizes are determined by the ueueSizeRead and queueSizeWrite members of the DRV_USART_INIT data structure. The driver provides driver events (DRV_USART_BUFFER_EVENT) that indicates termination of the buffer requests.

When the driver is configured for Interrupt mode operation, the buffer event handler executes in an interrupt context. Calling computationally intensive or hardware polling routines within the event handlers are not recommended.

When the driver adds request to the queue, it returns a buffer handle. This handle allows the client to track the request as it progresses through the queue. The buffer handle expires when the event associated with the buffer is complete.

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.