Characteristics and Service static generation macro

[jamessizeland]

Currently the interface for creating Services and their corresponding Characteristics is complex, requiring generation of a static byte slice for each characteristic. The pattern that exists in Softdevice is (in my opinion) very elegant and would clean up the boilerplate code. (example implementation)

where code that currently might need to look something like this:

pub struct Server {
    pub battery: BatteryService,
}

pub struct BatteryService {
    service_handle: AttributeHandle,
    pub level: Characteristic,
    pub rate: Characteristic,
}

/// This will be replaced with something less hard-coded in future.
pub fn init_characteristics(table: &mut Attributes) -> Handles {
    static GATT_STORE: StaticCell<[u8; 128]> = StaticCell::new();
    let storage = GATT_STORE.init([0; 128]);
    let readable = &[CharacteristicProp::Read, CharacteristicProp::Notify];
    let mut battery_service = table.add_service(Service::new(0x180f));
    let (level, rest) = storage.split_at_mut(4);
    let (rate, _rest) = rest.split_at_mut(4);
    let battery = BatteryService {
        level: battery_service
            .add_characteristic(0x2a19, readable, level)
            .build(),
        rate: battery_service
            .add_characteristic(Uuid::from(0x2a21), readable, rate)
            .build(),
        service_handle: battery_service.build(),
    };
    Handles { battery }
}

could be defined something like this:

#[trouble_host::gatt_server]
pub struct Server {
    pub bas: BatteryService,
}


#[trouble_host::gatt_service(uuid = "7e701cf1-b1df-42a1-bb5f-6a1028c793b0")]
pub struct BatteryService {
    #[characteristic(uuid = "e3d1afe4-b414-44e3-be54-0ea26c394eba", read, notify)]
    level: f32,
    #[characteristic(uuid = "e4d1afe4-b414-44e3-be54-0ea26c394eba", read, notify)]
    rate: f32
}

[igiona]

I also would love to have this kind of support from the library.
The GATT server definition of the SoftDevice crate is really clean and easy to read and use.

[lulf]

Agreed! I think building these macros on the current api should be fine, allowing users to pick.

[jamessizeland]

nice @petekubiak and I might be able to give this a look tomorrow.

[jamessizeland]

Have forked and we're working our way through the proc macro creation!

[petekubiak]

@lulf @igiona We've raised a draft PR #131 for this - it's still WIP but gives an indication of the direction. There's a todo list in the description to indicate the remaining work. Please feel free to comment and let us know if there's anything you'd like added / done differently! We'll be carrying on with it next week.