Re: ble_gattc_disc_svc_by_uuid problems

Yes that did it. And it looks like that patch is upstreamed in there. Sadly looks like flash and ram grew a good bit and Im going to have to fight that for a while again. On Tue, Dec 27, 2016 at 10:02 PM, Christopher Collins wrote: > Hi Jacob, > > You will need to upgrade

Re: ble_gattc_disc_svc_by_uuid problems

Hi Jacob, You will need to upgrade newt as well. You can do that as follows: cd $GOPATH && git checkout develop && git pull && go install Hopefully that fixes the compile problem. Please report back if you encounter any issues. Thanks, Chris On Tue, Dec 27, 2016 at

Re: ble_gattc_disc_svc_by_uuid problems

Thanks for the quick replies. I changed to repository.apache-mynewt-core: type: github vers: 0-latest user: apache repo: incubator-mynewt-core Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newt run nrf51822xxaa_blecenthr 0.0.0 Compiling main.c Compiling misc.c Compiling

Re: ble_gattc_disc_svc_by_uuid problems

Hi Jacob, On Tue, Dec 27, 2016 at 02:37:01PM -0700, Jacob Rosenthal wrote: > Hey all, been working with mynewt for a week or so now, trying to > understand the code and slim the nimble stack down for nrf51822qfaa > targets. Playing with central role now (modified blecent), and Im having > some

ble_gattc_disc_svc_by_uuid problems

Hey all, been working with mynewt for a week or so now, trying to understand the code and slim the nimble stack down for nrf51822qfaa targets. Playing with central role now (modified blecent), and Im having some trouble searching for a single svc by uuid (to save peer struct memory, rather than

Re: Schedule task with strict fixed timing and variable workload

+1 - I agree with this thread. https://issues.apache.org/jira/browse/MYNEWT-522 On 26 Dec 2016, at 10:26, Kevin Townsend wrote: Hi Will, Thanks for the feedback. 1) Unless you are the highest priority task, other tasks can run which could cause delays, and thus you are not waking up at the

Re: [nRF52 HAL I2C] Possible 'probe' issue?

Hi Greg, /* Scan all valid I2C addresses (0x03..0x77) */ for (addr = 0x08; addr < 0x78; addr++) { fix the comment :-P I fixed that locally, yes ... caught it after copying and pasting :) Well, the address isn't necessarily "invalid", it just isn't defined by the I2C

Re: [nRF52 HAL I2C] Possible 'probe' issue?

On Tue, Dec 27, 2016 at 3:32 AM, Greg Stein wrote: >... > Those addresses are *reserved* per the I2C spec. > To be explicit, I'm referring to: http://www.nxp.com/documents/user_manual/UM10204.pdf

Re: [nRF52 HAL I2C] Possible 'probe' issue?

On Mon, Dec 26, 2016 at 5:31 PM, Kevin Townsend wrote: > Hi Greg, > > Well, unexpected but the problem is indeed the faulty address > requests at the beginning and correctly setting the start > address to 0x08 causes the LSM303 to respond: > Excellent! >... > /*