• State Not Answered
  • Replies 3 replies
  • Subscribers 74 subscribers
  • Views 600 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 314189
Options

nRF52840 : Why BLE HCI UART implemented using Interrupt API than Asynchronous API

Alaganraj
Hello Nordic Team,
The sample program BLE HCI UART implemented using interrupt API, which has limitation of 1 byte Rx  per interrupt.
per document, Asynchronous API is recommend for UART,
We are interested in Asynchronous API hoping which will improve the throughput.
  1. Is there any specific reason BLE HCI UART program implemented using interrupt API?
  2. Do you have BLE HCI UART program based on Asynchronous API(uses eDMA)?
  3. If not available, is it something Nordic can help to implement?

Regards,

Alaganraj

Parents
  • 0

    It looks like the only reason they chose the Polling UART API  instead of Async UART API is to keep the sample simple and still expose the functionality of the HCI UART.

    With Async UART API you need to know more about the details of the uart (callback/ TXRX buffers etc) than the simple use of poll.

    I agree that you can optimize this sample to use Async API. But that is the case for any sample where you have more than one option of API to choose from.

  • 0 in reply to Susheel Nuguru

    Thank you for the details Susheel. appreciate your support !

    just adding summary from Scott Jeff as well, it may help people in community.

    " After creating the HCI UART project, I reviewed the HCI protocol. The protocol is primarily a single-word command protocol. However, I assume that data transfer can be of varying lengths. Hence your interest in EZ-DMA.
     I attempted to use the EZ-DMA for a UART application a few years ago. The issue I ran into was the EZ-DMA process leans itself well to block transfer of a fixed size. If the transfer data size is dynamic, you need additional timeout handlers to handle the case when the amount of transferred data isn’t enough to trigger the full buffer process. It’s not an impossible task, but unless there is a need to boost the UART interface’s throughput, a byte orientated transport is much easier and, in most cases, more efficient.
    "
Reply
  • 0 in reply to Susheel Nuguru

    Thank you for the details Susheel. appreciate your support !

    just adding summary from Scott Jeff as well, it may help people in community.

    " After creating the HCI UART project, I reviewed the HCI protocol. The protocol is primarily a single-word command protocol. However, I assume that data transfer can be of varying lengths. Hence your interest in EZ-DMA.
     I attempted to use the EZ-DMA for a UART application a few years ago. The issue I ran into was the EZ-DMA process leans itself well to block transfer of a fixed size. If the transfer data size is dynamic, you need additional timeout handlers to handle the case when the amount of transferred data isn’t enough to trigger the full buffer process. It’s not an impossible task, but unless there is a need to boost the UART interface’s throughput, a byte orientated transport is much easier and, in most cases, more efficient.
    "
Children
No Data
Related
Terms of service