Add Nordic Uart Service (NUS) peripheral to examples

[plaes]

Add generic peripheral implementation of Nordic Uart Service (NUS) and add example of it to nrf-sdc.

Has still some TODOs

[plaes]

@lulf Any clues what I'm doing wrong here? :)

[petekubiak]

@plaes Can you explain a little more about the issue? Does something break if you make the tx array 123 bytes?

[plaes]

If you have following on line 118, it asserts that 123 != 128 when sending the notification after someone has connected:

let mut tx = [0; ATT_MTU];

[petekubiak]

Interesting...I'm guessing this is the asset in question:

trouble/host/src/attribute.rs

Line 381 in 51d2b95

assert_eq!(value.len(), input.len());

The issue you're facing is because your tx characteristic is of type heapless::Vec<u8, 123>, while the local variable tx is of type [u8; 123]. heapless::Vec has 4 bytes of metadata associated with it, giving 127 bytes which is probably being padded to 128 for alignment :)

[petekubiak]

Following up on this, I'd definitely recommend using the same type throughout. With your code as it is currently written, line 124 is actually modifying the first byte in the heapless::Vec's length field (which is of type usize). This will cause undefined behaviour if you were to try to use it as a Vec elsewhere.

On the whole I would be reluctant to use non-primitive types for characteristics as it assumes that the other end of the comms channel has an understanding of that type. Furthermore, the heapless implementation of Vec could change its memory structure in a future version, which would change the representation of the data in memory and cause further confusion.

TL;DR: in this instance I'd strongly recommend making your tx characteristic a byte array.

[plaes]

This is where the assertion happens:

trouble/host/src/attribute.rs

Lines 376 to 383 in 51d2b95

	pub fn set(&self, handle: Characteristic, input: &[u8]) -> Result<(), Error> {
	self.iterate(|mut it| {
	while let Some(att) = it.next() {
	if att.handle == handle.handle {
	if let AttributeData::Data { props, value } = &mut att.data {
	assert_eq!(value.len(), input.len());
	value.copy_from_slice(input);
	return Ok(());

Regarding nrf-softdevice, all the value conversions seem to go through to_gatt() and from_gatt() methods, which is provided by two traits: FixedGattValue and GattValue.

GattValue can handle data with length smaller than attribute size and also implements support for Vec and String types via Heapless.

[jamessizeland]

Nice, I suspect we'll want to just implement the same, or possibly do so as part of the bt-hci crate.

[petekubiak]

Yes, I'm in the process of bringing the FixedGattValue and GattValue traits into TrouBLE as part of my work on #136. The purpose of that work isn't to implement support for variable length characteristics, but it will provide the framework to be able to implement this in future.

[petekubiak]

I've raised #149 to track the variable length characteristic implementation

[lulf]

Agreed bringing over FixedGattValue and GattValue traits to trouble makes sense. There is also #133 which might also allow doing varlength without having to store it.

[plaes]

Updated example to the new API, but I have to dig into the whole NRF UART thingy a bit more to understand how to properly test it. And secondly, there's this buffer size modification that I need to perform - not sure I'm doing this properly or this should be handled via some kind of wrapper method that handles size requirements.

[jamessizeland]

what hardware do I need to try this out?

[plaes]

what hardware do I need to try this out?

I'm currently on custom nrf52832 board, but it should be possible to use the generic "apps" part on any hardware you have as UART isn't actually connected to any peripheral.

[jamessizeland]

are you blocked by anything on finishing this PR that we can help with @plaes?

[plaes]

are you blocked by anything on finishing this PR that we can help with @plaes?

Not really blocked, but busy with other things. If you want, you can take over.

[jamessizeland]

Cool, no worries, I'll see about taking a look!