BLE GATT characteristic variable length (Zephyr)

RE: BLE GATT characteristic variable length (Zephyr)

Nick_RA — Fri, 02 May 2025 14:38:00 GMT

That would explain why I couldn't find anything! It works fine, thanks.

RE: BLE GATT characteristic variable length (Zephyr)

Hung Bui — Fri, 02 May 2025 13:53:13 GMT

[quote user="Nick_RA"]and just return whatever I want to the central device whenever a connection is made[/quote]

It's actually true. You can take a look here at section 4 where I discussed a little bit about this approach in Zephyr and compare it to the old softdevice:
https://devzone.nordicsemi.com/guides/nrf-connect-sdk-guides/b/software/posts/building-a-ble-application-on-ncs-comparing-and-contrasting-to-softdevice-based-ble-applications#mcetoc_1elnnim8t3
(The blog is a little bit old and may not have most up to date API, please follow the academy course)

RE: BLE GATT characteristic variable length (Zephyr)

Nick_RA — Fri, 02 May 2025 13:46:55 GMT

I already have the callback:

static ssize_t char_foo_read(struct bt_conn *conn, const struct bt_gatt_attr *attr,void *buf, uint16_t len, uint16_t offset)
{
    const char *value = attr->user_data;
    return bt_gatt_attr_read(conn, attr, buf, len, offset, value,len);
}

The intention here is to update the user_data before a connection is made. It's part of a configuration set by the customer via a uart CLI.

Or... are you saying I can ignore the actual characteristic data in the softdevice, and just return whatever I want to the central device whenever a connection is made? That doesn't seem right to me.

RE: BLE GATT characteristic variable length (Zephyr)

Hung Bui — Fri, 02 May 2025 13:06:37 GMT

Hi Nick,
You will receive a call back when the client do a read.
I would suggest to take a look at our Academy course for BLE here: https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-4-bluetooth-le-data-exchange/topic/blefund-lesson-4-exercise-1/

At step 5 it discusses about implementing the callback.