WIP: UUID endian change

[marcuschangarm]

Reversed internal representation of long UUID in the UUID class to little endian to be consistent with the short UUID, advertisements, and the nordic softdevice.

Added string constructor to UUID for human readable UUID.

Made changes to the services.

see ARMmbed/ble-nrf51822#82

[marcuschangarm]

@rgrover as we discussed

[rgrover]

add a check here to ensure that nibble is false

[marcuschangarm]

What do you want to guard against? I was thinking that as long as there are enough hexadecimal characters in the string, we should just ignore the hyphens.

[rgrover]

the hyphens could come at the wrong place. This constructor currently accepts -X-X-X-XXXXXXXXXXXXXXXX...

[marcuschangarm]

Yes, and I think we should allow that. Without a proper feedback mechanism the user could easily mistype a single hyphen and not know what went wrong.

[marcuschangarm]

@rgrover @pan-

I've made the requested changes.

[rgrover]

+1
we need to have a separate discussion regarding the UUID constructor. It may be that in its current form, the UUID constructor is misleading (or not explicit enough) regarding the ordering of the bytes.

[rgrover]

just a trivial note: this is byte-order, not bit-order. I'll fix this when I merge this PR.

[rgrover]

published "ble-2.1.10"
@pan- : applied reverse_copy()
also renamed BitOrder_t to ByteOrder_t

[apalmieriGH]

@marcuschangarm @pan- @rgrover : guys, I suppose that depending on the byte order used, the shortUUID should be set accordingly. The following is a proposal for the setupLong() method in UUID.h
What is your feeling?

void setupLong(const LongUUIDBytes_t longUUID, ByteOrder_t order = UUID::MSB) {
        type      = UUID_TYPE_LONG;
        if (order == UUID::MSB) {
            // Switch endian. Input is big-endian, internal representation is little endian.
            std::reverse_copy(longUUID, longUUID + LENGTH_OF_LONG_UUID, baseUUID);
            shortUUID = (uint16_t)((baseUUID[3] << 8) | (baseUUID[2]));
        } else {
            std::copy(longUUID, longUUID + LENGTH_OF_LONG_UUID, baseUUID);
            shortUUID = (uint16_t)((baseUUID[13] << 8) | (baseUUID[12]));
        }
    }

[marcuschangarm]

@apalmieriGH Isn't that what we are doing already?

https://github.com/ARMmbed/ble/blob/master/ble/UUID.h#L185

[apalmieriGH]

I think this is fine just for LSB. Shouldn't be

shortUUID = (uint16_t)((baseUUID[3] << 8) | (baseUUID[2]));

for MSB case?

[marcuschangarm]

The line is outside the if-else statement, so baseUUID is already LSB.

[apalmieriGH]

Maybe I'm missing something. But in the "if" (which is also the default) case the baseUUID is supposed in MSB, right?

[marcuschangarm]

Yes, and then it gets reversed copied into baseUUID, so after the if-else baseUUID is LSB regardless of input.

[apalmieriGH]

Ok, then in this case, the shortUUID shoud be always

shortUUID = (uint16_t)((baseUUID[3] << 8) | (baseUUID[2]));

Do you agree?

[marcuschangarm]

No, that would give you BBBB when we want AAAA:

human readable UUID in MSB: XXXXAAAA-XXXX-XXXX-XXXX-XXXXBBBBXXXX