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

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

Alaganraj — Mon, 11 Sep 2023 23:30:05 GMT

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.

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

Susheel Nuguru — Mon, 11 Sep 2023 07:12:05 GMT

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.

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

Susheel Nuguru — Mon, 11 Sep 2023 05:14:12 GMT

I haven't looked into the example deep enough to be able to answer that. Let me spend some time on it today and will try to answer you soon after that on why we used the interrupt mode for the BLE HCI UART.