Re: Disconnect reason wrong on local termination

On Thu, Jun 30, 2016 at 12:39:00PM -0700, Simon Ratner wrote: > Hi devs, > > I've been looking at the reasons I get in BLE_GAP_EVENT_DISCONNECT to make > sure I cover all edge cases, and this is what I see (on an nrf51-based > board): > > switch (ctxt->disconnect.reason) { > case

Re: Disconnect reason wrong on local termination

On Thu, Jun 30, 2016 at 01:31:00PM -0700, Simon Ratner wrote: > It is sometimes hard to tell if they are "expected", but below are a couple > of sample traces. > > Based on the timestamps, I would say the first two are expected (device was > slow to respond), while the last one is unexpected. In

Re: Using the ADC on nrf52dk

Actually, I get: "error: storage size of 'hr_adc' isn't known” when HR_ADC is declared as hal_adc, but I think it amounts to the same error. ;-) It sounds like what you’re saying is that ADC has not been implemented yet, and if I want/need to use the ADC I’m going to have to implement it

Re: Disconnect reason wrong on local termination

> Based on the timestamps, I would say the first two are expected > ... > 896096:[ts=875093696ssb, mod=4 level=1] GATT procedure initiated: read by > uuid; start_handle=40 end_handle=65535 uuid=0304 > 906398:[ts=885154208ssb, mod=64 level=2] gatt_cli: failed to read chr; > conn_handle=1

Re: Disconnect reason wrong on local termination

Just following up on the BLE_HS_ENOMEM, the most obvious place where ble_gattc_disc_svc_by_uuid returns that is when it doesn't have a free gattc_proc. I have max_gattc_procs set to NIMBLE_OPT(MAX_CONNECTIONS), any reason why that would not be enough? Is it possible procs are not being returned

Re: Disconnect reason wrong on local termination

It is sometimes hard to tell if they are "expected", but below are a couple of sample traces. Based on the timestamps, I would say the first two are expected (device was slow to respond), while the last one is unexpected. In the last trace, the gatt op failed for another reason (rc=6 i.e.

Disconnect reason wrong on local termination

Hi devs, I've been looking at the reasons I get in BLE_GAP_EVENT_DISCONNECT to make sure I cover all edge cases, and this is what I see (on an nrf51-based board): switch (ctxt->disconnect.reason) { case BLE_HS_ENOTCONN: /* I see this when the local host has terminated the

Re: Using the ADC on nrf52dk

I just pulled from develop and my version does not have hal_adc support for the nrf52. I looked in the following place and didn’t see a hal_adc.c file. $ ls repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/ hal_cputime.c hal_gpio.c hal_system.c hal_uart.c hal_flash.c hal_os_tick.c

Re: Arduino Zero/M0 Pro default serial connection changed

Cool. Works now. The cause of my problem was VirtualBox mapping the device into the VM used by docker. On Thu, Jun 30, 2016 at 10:24 AM, p...@wrada.com wrote: > The Edbg serial port build into the arduino zero debug is a cdc serial > port (not FTDI). Linux and Mac should have

Re: Arduino Zero/M0 Pro default serial connection changed

The Edbg serial port build into the arduino zero debug is a cdc serial port (not FTDI). Linux and Mac should have support but Windows requires some additional drivers > On Jun 30, 2016, at 10:20 AM, marko kiiskila wrote: > > Hi Todd, > > my MAC is using USB CDC driver for

Re: Arduino Zero/M0 Pro default serial connection changed

Hi Todd, my MAC is using USB CDC driver for this, and it names the tty’s as /dev/tty.usbmodemXXX. > On Jun 30, 2016, at 10:01 AM, todd mitton wrote: > > I know I'm using the correct port and cable because I'm able to load new > images using newt. I bet my problem is the USB

Using the ADC on nrf52dk

I think I’m finally getting a handle on mynewt … I’m able to add tasks, schedule them, respond to them, etc. so this is some progress. :-) I do have a question about the ADC though. I can find scant info on how to use the ADC. In looking through the header files, I see that hal_adc.h defines