Re: Adding service to bleprph

[Stephane D'Alu]

On 06/01/2016 08:32 PM, Christopher Collins wrote:

On Wed, Jun 01, 2016 at 07:24:01PM +0200, Stephane D'Alu wrote:

Hello again,

I was trying to add a service/characteristic to the bleprph example, and
thought it would be as simple as:

* add a gatt_svr_chr_access_ function
* add the service definition in gatt_svr_svcs
* increase some configuration values (max_services, max_attrs)
to be safe

Once done, I'm not able to discover services anymore.
Did I miss something?

(Using gcc 4.9.2, and newt 0.9.0)


Hi Stephane,

It looks like you found a bug in the nimble host read-group-type
request handler.  With the rearranged registered attributes, the host
fails to send the response to the client's initial service discovery
request.

I have pushed the attached commit to the develop branch.  If you want to
use the develop branch, you'll need to do the following:

1. Make the following change to your project.yml file:

FROM:

 repository.apache-mynewt-core:
 type: github
 vers: 0-latest
 user: apache
 repo: incubator-mynewt-core

TO:

 repository.apache-mynewt-core:
 type: github
 vers: 0-dev
 user: apache
 repo: incubator-mynewt-core

(change the "vers" field).

2. Upgrade your packages with "newt upgrade", e.g.,

 [ccollins@iori:~/tmp/myproj]$ newt upgrade
 apache-mynewt-core
 Would you like to upgrade repository apache-mynewt-core from 0.7.9-none to 
0.0.0-none ? [Yn] y

Thanks!
Chris




I've tried the patch, it's working fine. Thanks!

I'll continue playing with the BLE stack, what is your advise staying on 
0.9 or moving to 0-dev?




--
Stephane D'Alu

Re: Adding service to bleprph

[Christopher Collins]

On Wed, Jun 01, 2016 at 07:24:01PM +0200, Stephane D'Alu wrote:
> Hello again,
> 
> I was trying to add a service/characteristic to the bleprph example, and 
> thought it would be as simple as:
> 
> * add a gatt_svr_chr_access_ function
> * add the service definition in gatt_svr_svcs
> * increase some configuration values (max_services, max_attrs)
>to be safe
> 
> Once done, I'm not able to discover services anymore.
> Did I miss something?
> 
> (Using gcc 4.9.2, and newt 0.9.0)

Hi Stephane,

That is indeed all you should need to do.  However, when I apply your
patch, I observe the same results.  I'll get back to you after I spend
some time debugging this.

Thanks,
Chris

Re: GDB scripts

[will sanfilippo]

I think having a gdbscript or scripts is an excellent idea but I dont think I 
would put them in libs/util. I dont like saying that without offering an 
alternative… but I just did :-)


> On Jun 1, 2016, at 10:25 AM, Christopher Collins  wrote:
> 
> On Wed, Jun 01, 2016 at 10:04:05AM -0700, Vipul Rahane wrote:
>> Hello,
>> 
>> While debugging a bunch of things, I felt the need for a few gdb scripts to 
>> print out the data structures that we would use regularly. I was thinking of 
>> creating a common gdb script which would contain different functions. This 
>> could reside in "libs/util" since we do not have a “tools" directory.
>> 
>> The developer would then just source the common script.
>> 
>> All suggestions are welcome.
> 
> Some gdb scripts are sorely needed, and I think that is a great idea.  I
> wrote some small gdb macros ("functions"?) for inspecting mbufs; if you
> create one or more gdb scripts, I'll follow your lead and add mine.
> 
> Chris

Re: GDB scripts

[Christopher Collins]

On Wed, Jun 01, 2016 at 10:04:05AM -0700, Vipul Rahane wrote:
> Hello,
> 
> While debugging a bunch of things, I felt the need for a few gdb scripts to 
> print out the data structures that we would use regularly. I was thinking of 
> creating a common gdb script which would contain different functions. This 
> could reside in "libs/util" since we do not have a “tools" directory.
> 
> The developer would then just source the common script.
> 
> All suggestions are welcome.

Some gdb scripts are sorely needed, and I think that is a great idea.  I
wrote some small gdb macros ("functions"?) for inspecting mbufs; if you
create one or more gdb scripts, I'll follow your lead and add mine.

Chris

GDB scripts

[Vipul Rahane]

Hello,

While debugging a bunch of things, I felt the need for a few gdb scripts to 
print out the data structures that we would use regularly. I was thinking of 
creating a common gdb script which would contain different functions. This 
could reside in "libs/util" since we do not have a “tools" directory.

The developer would then just source the common script.

All suggestions are welcome.

Regards,
Vipul Rahane

Re: Enabling the Nordic HAL gpio external IRQ detection

[Sterling Hughes]

Hi Wayne,

I’m working on fleshing out the HAL for Nordic chips as we speak, but 
going slowly.


If you’d like to make the changes, I’d make sure to merge anything 
you did into my work, and we’d appreciate the contribution.  If 
you’d like me to make them, I can reorg some stuff and make sure to 
get that in first, but can’t promise it will be before early next week 
at this point, given everything else going on.


Best,

Sterling

On 1 Jun 2016, at 1:24, Wayne Keenan wrote:


Hi,

I'd like to detect button pressed via IRQ based edge detection because 
polling gpio pins is currently not a practical solution for my 'app'.


I could just remove  the #if defines in the hal .c and just try it but 
those are obviously there for a 'bigger picture' reason.


I couldn't find an open issue on JIRA so wondered if anyone could 
please let me know a bit more and if this is on anyones radar?


All the best
Wayne

Re: Triggering GATT Notification's

[Christopher Collins]

On Wed, Jun 01, 2016 at 07:04:02AM +0100, Wayne Keenan wrote:
> Because I'm creating a 'ble_gatt_svc_def' at runtime these are the steps
> I'm having todo to be able to keep hold of the characteristic handle in
> order to be able to call 'ble_gatts_chr_updated(handle)' to send the
> notification when needed:
> 
> 1. When initialising the 'ble_gatt_chr_def' the  'arg' field is set to a
> marker value.
> 
> 2. In my 'gatt_svr_register_cb' callback if a ble_gatt_chr_def.arg marker
> value is found then the 'ctxt->chr_reg.def_handle' is stashed in a global
> var.

That will work, but as you say, the need for the "marker arg" is a bit
unwieldy.  I think you are correct - there isn't currently a good way to
do this.  There is an alternative approach that I came up with, but I am
not sure it is an improvement over what you are currently doing, so it
has been relegated to the bottom of this email!

After reading your email and looking at the code some more, I think
there are a few changes that need to be made to the nimble host
immediately:

1. The characteristic-registration-callback should receive a pointers to
both the service definition and the characteristic definition (currently
it only receives a pointer to the characteristic definition).  Without
the service in hand, it is impossible to identify the characteristic by
UUIDs.

2. (As you mentioned) A function to retrieve the attribute handles
corresponding to the characteristic with a specified
service-UUID/characteristic-UUID pair.

In addition, this is not directly related to the problem being
discussed, but I noticed we need a third change:

3. The characteristic access callback also needs to receive a pointer to
the service definition (rather than just a pointer to the characteristic
definition).  This chnage is needed for the same reason as 1 above: so
that the characteristic can be reliably identified by UUID.

[...]
> Is it safe to cache the 'union ble_gatt_register_ctxt *ctxt' pointer
> given as a parameter 'gatt_svr_register_cb' to use later?

No, it is not safe.  The ctxt object is located on the stack, so you
need to make copies of anything you might need later.

> Being able to call Newt GATT API's like the following would help alleviate
> steps 1,2 and help with step 3:
> 
> a) uuit16_t gatt_get_handle_for_chr(serviceUUID, charUUID)

Agreed.

> b) int gatt_write_chr(uint16_t handle, void* data, uint len, bool
> sendNotificationIfEnabled);

There is the following function:

int
ble_att_svr_write_local(uint16_t attr_handle, void *data,
uint16_t data_len);

When a characteristic is written via this function call, the subsequent
characteristic access callback indicates that the write was done locally
by specifying a connection handle of BLE_HS_CONN_HANDLE_NONE (0x).

The above function will always send notifications to all clients who are
subscribed to the corresponding characteristic.  Perhaps the
characteristic access callback should have the option of disabling
notifications for a particular write.  Alternatively, If you want to
update a characteristic without sending any notifications, you can
always bypass the nimble stack entirely and just write directly to the
attribute data.

[...]

Thanks again for you feedback.  It is very much appreciated.

Chris

-

As promised, below is a technique that eliminates the need for the
marker arg.  As I said, it is a bit too ugly for me to recommend with a
straight face, but I thought I should include it for.. I don't know...
some reason :).  The technique identifies characteristics by memory
address.

#define SVC_IDX_GAP 0
#define CHR_IDX_GAP_DEV_NAME0
#define CHR_IDX_GAP_APPEARANCE  1

static const struct ble_gatt_svc_def my_svcs[] = {
[SVC_IDX_GAP] = {
/*** Service: GAP. */
.type = BLE_GATT_SVC_TYPE_PRIMARY,
.uuid128 = BLE_UUID16(BLE_GAP_SVC_UUID16),
.characteristics = (struct ble_gatt_chr_def[]) {
[CHR_IDX_GAP_DEV_NAME] = {
/*** Characteristic: Device Name. */
.uuid128 = BLE_UUID16(BLE_GAP_CHR_UUID16_DEVICE_NAME),
.access_cb = gatt_svr_chr_access_gap,
.flags = BLE_GATT_CHR_F_READ,
},

[CHR_IDX_GAP_APPEARANCE] = {
/*** Characteristic: Appearance. */
.uuid128 = BLE_UUID16(BLE_GAP_CHR_UUID16_APPEARANCE),
.access_cb = gatt_svr_chr_access_gap,
.flags = BLE_GATT_CHR_F_READ,
},

/* [...] */

0, /* No more characteristics in this service. */
}
0, /* No more services. */
},
};


static void
gatt_svr_register_cb(uint8_t op, union ble_gatt_register_ctxt *ctxt,
 void *arg)
{
switch (op) {
case BLE_GATT_REGISTER_OP_CHR:
if 

Re: Enabling the Nordic HAL gpio external IRQ detection

[will sanfilippo]

It is on our radar to port all the current HAL to the nordic chip and this 
would include generating an interrupt on a gpio level change. Not quite sure 
when that will occur but it near the top of the list to do.


> On Jun 1, 2016, at 1:24 AM, Wayne Keenan  wrote:
> 
> Hi,
> 
> I'd like to detect button pressed via IRQ based edge detection because 
> polling gpio pins is currently not a practical solution for my 'app'.
> 
> I could just remove  the #if defines in the hal .c and just try it but those 
> are obviously there for a 'bigger picture' reason.  
> 
> I couldn't find an open issue on JIRA so wondered if anyone could please let 
> me know a bit more and if this is on anyones radar?
> 
> All the best
> Wayne

Re: bletiny and bleprph

[Stephane D'Alu]

On 05/31/2016 11:18 PM, chris collins wrote:

Hi Stephane,

It is not every day that you see a negative overflow :).  What version of
gcc are you using?


It's 4.8.4 20141219 (release) (4.8.4-1+11-1), on debian

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/4.8/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.8.4/configure --build=x86_64-linux-gnu 
--prefix=/usr --includedir='/usr/lib/include' 
--mandir='/usr/lib/share/man' --infodir='/usr/lib/share/info' 
--sysconfdir=/etc --localstatedir=/var --disable-silent-rules 
--libexecdir='/usr/lib/lib/gcc-arm-none-eabi' --disable-maintainer-mode 
--disable-dependency-tracking --enable-languages=c,c++ --prefix=/usr/lib 
--infodir=/usr/share/doc/gcc-arm-none-eabi/info --mandir=/usr/share/man 
--htmldir=/usr/share/doc/gcc-arm-none-eabi/html 
--pdfdir=/usr/share/doc/gcc-arm-none-eabi/pdf --bindir=/usr/bin 
--libexecdir=/usr/lib --libdir=/usr/lib --with-system-zlib 
--enable-multilib --disable-decimal-float --disable-libffi 
--disable-libgomp --disable-libmudflap --disable-libquadmath 
--disable-libssp --disable-libstdcxx-pch --disable-libstdc++-v3 
--disable-nls --disable-shared --disable-threads --disable-tls 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-none-eabi 
--with-gnu-as --with-gnu-ld --with-headers=no --without-newlib 
--with-pkgversion=4.8.4-1+11-1 --without-included-gettext 
--with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r 
INHIBIT_LIBC_CFLAGS=-DUSE_TM_CLONE_REGISTRY=0 
AR_FOR_TARGET=arm-none-eabi-ar AS_FOR_TARGET=arm-none-eabi-as 
LD_FOR_TARGET=arm-none-eabi-ld NM_FOR_TARGET=arm-none-eabi-nm 
OBJDUMP_FOR_TARGET=arm-none-eabi-objdump 
RANLIB_FOR_TARGET=arm-none-eabi-ranlib 
READELF_FOR_TARGET=arm-none-eabi-readelf 
STRIP_FOR_TARGET=arm-none-eabi-strip

Thread model: single
gcc version 4.8.4 20141219 (release) (4.8.4-1+11-1)



I've just tried on FreeBSD with gcc 5.3.1 20160307 (release),
and that's building fine.

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-arm-embedded-5_3-2016q1-20160330/bin/../lib/gcc/arm-none-eabi/5.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: 
/usr/obj/usr/ports/devel/gcc-arm-embedded/work/gcc-arm-none-eabi-5_3-2016q1-20160330/src/gcc/configure 
--target=arm-none-eabi 
--prefix=/usr/obj/usr/ports/devel/gcc-arm-embedded/work/install/gcc-arm-embedded-5_3-2016q1-20160330 
--infodir=/usr/obj/usr/ports/devel/gcc-arm-embedded/work/install/gcc-arm-embedded-5_3-2016q1-20160330/share/doc/gcc-arm-none-eabi/info 
--mandir=/usr/obj/usr/ports/devel/gcc-arm-embedded/work/install/gcc-arm-embedded-5_3-2016q1-20160330/share/doc/gcc-arm-none-eabi/man 
--htmldir=/usr/obj/usr/ports/devel/gcc-arm-embedded/work/install/gcc-arm-embedded-5_3-2016q1-20160330/share/doc/gcc-arm-none-eabi/html 
--pdfdir=/usr/obj/usr/ports/devel/gcc-arm-embedded/work/install/gcc-arm-embedded-5_3-2016q1-20160330/share/doc/gcc-arm-none-eabi/pdf 
--libexecdir=/usr/obj/usr/ports/devel/gcc-arm-embedded/work/install/gcc-arm-embedded-5_3-2016q1-20160330/lib 
--with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local 
--with-isl=/usr/local --disable-isl-version-check 
--with-cloog=/usr/local --with-libelf=/usr/local 
--enable-languages=c,c++ --enable-plugins --disable-decimal-float 
--disable-libffi --disable-libgomp --disable-libmudflap 
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch 
--disable-nls --disable-shared --disable-threads --disable-tls 
--with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes 
--with-python-dir=share/gcc-arm-none-eabi 
--with-sysroot=/usr/obj/usr/ports/devel/gcc-arm-embedded/work/install/gcc-arm-embedded-5_3-2016q1-20160330/arm-none-eabi 
--with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r,armv8-m.base,armv8-m.main 
--with-pkgversion='GNU Tools for ARM Embedded Processors'

Thread model: single
gcc version 5.3.1 20160307 (release) [ARM/embedded-5-branch revision 
234589] (GNU Tools for ARM Embedded Processors)





I am not able to reproduce the issue with the following gcc:

[ccollins@ccollins-mac:~/repos/apache/mynewt/core]$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc-arm-none-eabi/20140805/bin/../lib/gcc/arm-none-eabi/4.8.4/lto-wrapper
Target: arm-none-eabi
Configured with:
/Users/build/GCC-4-8-build/gcc-arm-none-eabi-4_8-2014q3-20140805/src/gcc/configure
--target=arm-none-eabi
--prefix=/Users/build/GCC-4-8-build/gcc-arm-none-eabi-4_8-2014q3-20140805/install-native
--libexecdir=/Users/build/GCC-4-8-build/gcc-arm-none-eabi-4_8-2014q3-20140805/install-native/lib
--infodir=/Users/build/GCC-4-8-build/gcc-arm-none-eabi-4_8-2014q3-20140805/install-native/share/doc/gcc-arm-none-eabi/info
--mandir=/Users/build/GCC-4-8-build/gcc-arm-none-eabi-4_8-2014q3-20140805/install-native/share/doc/gcc-arm-none-eabi/man

Re: Triggering GATT Notification's

[Wayne Keenan]

Hiya Chris,


On 31 May 2016 at 16:36, Christopher Collins  wrote:

>
>
> There are a few ways to send notifications:
>
> 1. The stack sends them automatically to subscribed clients when a
>characteristic value changes.  The client subscribes to notifications
>(or indications) for a particular characteristic by writing to the
>corresponding client characteristic configuration descriptor (CCCD).
>
>
I didn't know newt would automatically do that, thanks for letting me know.

Because I'm creating a 'ble_gatt_svc_def' at runtime these are the steps
I'm having todo to be able to keep hold of the characteristic handle in
order to be able to call 'ble_gatts_chr_updated(handle)' to send the
notification when needed:


1. When initialising the 'ble_gatt_chr_def' the  'arg' field is set to a
marker value.

2. In my 'gatt_svr_register_cb' callback if a ble_gatt_chr_def.arg marker
value is found then the 'ctxt->chr_reg.def_handle' is stashed in a global
var.

3. (In  theory) update the characteristic value
4. Invoke 'ble_gatts_chr_updated(handle)'


At step 3 I say in theory because currently I'm not...  is it safe to cache
the 'union ble_gatt_register_ctxt *ctxt' pointer given as a parameter
'gatt_svr_register_cb' to use later?


Being able to call Newt GATT API's like the following would help alleviate
steps 1,2 and help with step 3:

a) uuit16_t gatt_get_handle_for_chr(serviceUUID, charUUID)
b) int gatt_write_chr(uint16_t handle, void* data, uint len, bool
sendNotificationIfEnabled);



>
> The nimble stack hasn't gotten a lot of practical use, so there are
> undoubtedly some aspects of the API that are lacking common sense.  Now
> is the perfect time to make changes to the API while Mynewt is still in
> its beta phase, and input like yours is extremely valuable.  If you have
> the time, I was hoping you could add some more details concerning what
> you as an application developer would like to see exposed by the nimble
> host.
>

OK, cool.



> You mentioned a function which would send a custom notification to all
> connected devices.  Is this exactly what you are looking for, or were
> you just trying to make a compromise with nimble's current API?
>

Just trying to understand.

>
> An additional facility that the host needs to provide is: a means for
> the application to discover who is currently connected.  As you
> indicated in your email, currently it is up to the application to cache
> this information, which is certainly not ideal.  This is something that
> will need to get added in the next release.
>

That could be useful, although it would be convenient if something like API
example 'b' above
automatically notified all the relevant (connected and subscribed) central
devices.


>
All the best
Wayne