I'm encountering some problems with the nRF51 plugin v1.2 for BDS, none are show stoppers but I'm reporting them here so others are aware of them and maybe they'll get fixed in future.
Specifically, if I have a characteristic in the model with type float or float32, the plug-in generates the following definition for the characteristic type:
/**@brief ProblemService float characteristic structure. */
typedef struct
{
float_t value;
} ble_problemservice_problemservice_float_characteristic_t;
By default float_t isn't defined (unlike int32_t for example). I can work around that with my own define or typedef for float_t.
However in the c file, a call is made to bds_float_encode(...), which isn't defined in the app_util_bds.h header where all the other bds_xxxxx_encode and decode functions are defined. Again - not a show stopper as I can implement my own - but why isn't it present in the SDK header file.
The second problem occurs taking the model to the next level. If I define a characteristic as having type uint16_t and then define bit fields within that type, the BDS generates the following xml:
<Value>
<Field
name="Flags">
<Requirement>Mandatory</Requirement>
<Format>uint16</Format>
<Unit>org.bluetooth.unit.unitless</Unit>
<BitField>
<Bit
index="0"
size="1"
name="BIT0" />
<Bit
index="1"
size="1"
name="BIT1" />
<Bit
index="2"
size="1"
name="BIT2" />
</BitField>
<Repeated>false</Repeated>
</Field>
</Value>
I would very much expect that the nRF plugin would generate me a characteristic structure that looks like:
typedef struct
{
uint16_t bit0:1;
uint16_t bit1:1;
uint16_t bit2:1;
} problemservice_bit_flags_flags_t;
I appreciate there may be some endian issues with bit fields here but they aren't insurmountable.
However instead of this I get:
typedef struct
{
enum_flags_bit0_t bit0;
enum_flags_bit1_t bit1;
enum_flags_bit2_t bit2;
} problemservice_bit_flags_flags_t;
However the enum_flags_bitx_t types are not defined in the header anywhere. There's no real work around for that.
In my real project I've reverted to not using bit definitions on my flag characteristic, and I'm managing the definitions outside of the BDS Plug-in generated code.
Hopefully these observations will make it back to the plug-in development team & we'll see an update soon.
I've attached an example BDS project showing both issues.
Phil Beeson
