Multiperipheral Queued Writes - a buffer for each connection means a lot of space required. Can I deny simultaneous writes?

[goldwake]

I'm currently adding a large characteristic (5.3 times bigger than my max MTU) to my device that supports multiple peripheral connections. This characteristic is used to set up/change a stored config on the device and so, will be written to seldomly but could be written to by more than one device at a time. Because it is only written to seldomly, i'm implementing queued writes using the queued writes module.

Each connection requires its own nrf_ble_qwr_t instance which also requires an allocation of user memory. If I allocate a buffer for each connection, the memory requirements will add up quickly. Is there a way I can deny a long write if there is already one in progress on another connection so that I can use only one buffer? Is there a better way to approach the problem?

My characteristic is 256 bytes long ant MTU of 51 which means i need a buffer of length of

(CEILING(256, (NRF_BLE_GATT_MAX_MTU_SIZE - 3)) * 6) + 256 + 2 = 294 bytes

I'm developing this for an NRF52840 SDK15.0 but will also port it to NRF52832 SDK 14.2

Bonus points if you can tell me how to do a long notification too

[bjorn-spockeli]

Hi Goldwake, 

If you do not want to allocate more than one buffer at the time , then you could keep track of the number of BLE_EVT_USER_MEM_REQUEST and BLE_EVT_USER_MEM_RELEASE events you receive. So when you receive the first BLE_EVT_USER_MEM_REQUEST, then you do not reply with sd_ble_user_mem_reply() for subsequent BLE_EVT_USER_MEM_REQUEST events until you receive BLE_EVT_USER_MEM_RELEASE corresponding to the first BLE_EVT_USER_MEM_REQUEST.

There is no such thing as a long notification, the size of an attribute value(i.e the characteristic value) that is notified is limited to 0 to (ATT_MTU-3). If the attribute value is longer than (ATT_MTU-3) octets, then only the first(ATT_MTU-3) octets of this attributes value can be sent in a notification, see BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part F, Section 3.4.7.1

Best regards

Bjørn