Does the NUS really use the UART hardware?

[RVM]

I am a bit confused by the name and example use cases of 'NUS'.

The name is 'Nordic UART service' and it is often described as "A Serial UART interface over BLE" that is provided as a service.

In my application, I am calling the function 'ble_nus_data_send(...)'.

I am trying to understand why when I call this function with a large number of bytes then I keep getting error indications that there are no 'RESOURCES' available. Searching for similar issues on the devzone almost invariably highlights solutions that one way or another refer to a 'UART' interface.

It is not clear to me where and why the UART component is even playing a role in the discourse -- my firmware is directly calling the BLE API provided by the Nordic SDK and I do not expect there to be any dependence on a UART function of any sort.

My question is: What is the relation, if at all, between the NUS and a physical UART hardware?

Cheers

RVM

[Vidar Berg]

Hello,

ble_nus_data_send() will let you send any arbitrary data over BLE and does not care if the data originates from a physical UART interface or another source. But the service was made to emulate a UART interface over BLE, so if you advertise support for it in your advertising payload it might result in unexpected connection requests. So if you don’t plan to use it for UART emulation over BLE, I would recommended that you create a new UUID to replace the NUS UUIDs in nus.c/nus.h

- Nordic UART Service (NUS)

I am trying to understand why when I call this function with a large number of bytes then I keep getting error indications that there are no 'RESOURCES' available. Searching for similar issues on the devzone almost invariably highlights solutions that one way or another refer to a 'UART' interface.

The resource error is returned when you have filled up the Softdevice's tx buffer:

(ref. sd_ble_gatts_hvx())

Best regards,

Vidar

[RVM]

Thanks. I was thinking the same and you just confirmed it for me.

FYI, the buffer overrun was likely because I was doing some heavy lifting within the NUS IRQ handler. Once I moved that to a background task, we are no longer running into the resource errors at a rate that throttles our transfer.

Will mark this as an answer.