Hi Chris, A) Thanks for the style tips. I always appreciate those.
B) The device seems to be stuck in trying to register attributes loop, similar to what had happened when I didn't have enough attributes supported. Because I have just changed the UUID of the attribute I had working before, I don't expect this to be the same problem. Cheers James On Thu, May 19, 2016 at 12:13 PM, Christopher Collins <[email protected]> wrote: > On Thu, May 19, 2016 at 11:57:45AM -0700, James Howarth wrote: > > I'm not quite sure how to define a custom 128 bit UUID and pass it to > > .uuid128. > > > > I thought it might be a global variable e.g. > > static uint8_t UUID_BASE[16] = {0x03, 0x04, 0x00, 0x00, 0x2A, 0xAE, > > 0x4D, > > 0x26, 0xAD, 0x62, 0x03, 0xE9, 0xA8, 0x63, 0x7E, 0xBD}; > > > > And then pass this to the service like: > > .uuid128 = UUID_BASE, > > > > However this does not seem to work. Any suggestions appreciated. > > Hi James, > > That is the correct way to specify a 128-bit UUID. What goes wrong when > you try it? > > I also wanted to add a few nitpicks. None of these are issues that will > prevent your code from working, but I wanted to mention them in case you > want to come back to them later and for the benefit of other readers. > > 1. You might want to declare the uuid array as const, since it is a > read-only value. This will allow the linker to place this data in flash > rather than RAM (which is generally more scarce). Unfortunately, this > requires that you add a (void *) cast to the service definition, since > the service descriptor's uuid128 pointer is non-const [*]. > > 2. I recommend against using all-caps for that variable name. > Generally, all-caps is reserved for macros. Macros don't obey the usual > rules of the C language, so it is helpful to have a visual indication > that something is actually a macro rather than a regular identifier. > > Thanks, > Chris > > [*] Nimble and a lot of other Mynewt code has eschewed "const". I think > there are some places in the nimble host where using const would > simplify the API by obviating the need for casts, so I think we should > change this in the next release. >
