Re: Scheduling time of Nimble stack

Jiacheng 1) Sorry about not converting msecs to os time ticks. Good catch! 2) I understand using a semaphore to wake up a task but looking at the exact code you have shown, I dont understand why the task would release the semaphore in this case. Doesnt the interrupt release the semaphore? 3)

Re: Newtmgr over BLE

Hi Kevin, On Wed, Jan 25, 2017 at 02:18:01AM +0100, Kevin Townsend wrote: > I'm not sure what the implications would be here on the iOS app we wrote > that is based on the newtmgr protocol and makes use of the current BLE > service and characteristics, although we could rewrite it if necessary.

Re: Newtmgr over BLE

I'm not sure what the implications would be here on the iOS app we wrote that is based on the newtmgr protocol and makes use of the current BLE service and characteristics, although we could rewrite it if necessary. We use the currently defined newtmgr protocol and GATT services/chars to get

Re: Scheduling time of Nimble stack

Thanks, Will, you help me a lot. Since my task is triggered by a semaphore, and the semaphore is released by another interrupt routine, so if my task have no enough time to running and go to sleep, after wake up, it will release the semaphore again. Another minor change is time unit

Re: NimBLE host advertising data API

On Tue, Jan 24, 2017 at 12:40:04PM -0800, will sanfilippo wrote: > I am not sure I have any intelligent comments on this, but that has never > stopped me from commenting in the past, so… No worries. Thanks for the feedback! > > I think a byte buffer interface is fine as long as you have

Newtmgr over BLE

Hello all, Recently, I have mentioned some planned BLE-related changes to the newtmgr tool. I wanted to share some of what I was thinking. Please feel free to comment and criticize as needed. * All BLE code gets removed from the newtmgr tool. The gatt library is also removed. * A separate

Re: NimBLE host advertising data API

+1 ... raw buffer plus helpers offers the best of both worlds imho. Le mar. 24 janv. 2017 à 21:40, will sanfilippo a écrit : > I am not sure I have any intelligent comments on this, but that has never > stopped me from commenting in the past, so… > > > > I think a byte buffer

Re: NimBLE host advertising data API

I am not sure I have any intelligent comments on this, but that has never stopped me from commenting in the past, so… I think a byte buffer interface is fine as long as you have helper functions to create that buffer. Having folks have to figure out how to create an advertisement without any

Re: [ATTENTION] incubator-mynewt-core git commit: os; spin up OS before calling. main() gets called in context of main task.

So you are saying that there will still be well-defined places where things get initialized and that there will be defined ranges for these stages? For example: 0 - 99 Before os_init() is called. 100-199 in os_init() after os_init() code executes 200-299: in os_start() somewhere Realize that

Introduction

Hi there, I have been a lurker on the Mynewt Dev list for a couple of months now, and wanted to introduce myself. I am working on some of the Mynewt documentation and will be helping with some bug fixes for the newt tool also. I am new to embedded systems, IoT and Mynewt (I developed

Re: [ATTENTION] incubator-mynewt-core git commit: os; spin up OS before calling. main() gets called in context of main task.

Ah yes. Split applications should have the same settings for shared packages. Forgot about this when replacing pkg.yml contents with the updates. I’ll try a split use case today. > On Jan 23, 2017, at 7:12 PM, Jacob Rosenthal wrote: > > Looks like this breaks splitty

Re: Scheduling time of Nimble stack

Jiacheng: Given that your task is lower in priority than the LL task, you are going to run into issues if you dont either disable interrupts or prevent the LL task from running. Using interrupt disable as an example (since this is easy), you would do this. The code below is a function that

Re: push more often (was: [01/50] incubator-mynewt-core git commit: ...)

On 23 Jan 2017, at 23:41, Greg Stein wrote: commit 1 of 50 ?? This says to me: push more often. How can the mynewt community review your work, if you never push it? :-) as pointed out, it’s bringing the sensors_branch up to date: Vipul has started working on it, and I brought it up to

Re: push more often (was: [01/50] incubator-mynewt-core git commit: ...)

Those commits were made to a different branch: > >>> Repository: incubator-mynewt-core > >>> Updated Branches: > >>> refs/heads/sensors_branch 6247b5afa -> 2681044e8 That mass of commits was just a big merge from develop to sensors_branch. Sterling was just bringing sensors_branch up to date

Re: Scheduling time of Nimble stack

Hi, Will, My use scenario is when I have an event (with knowing running time) ready to run, I’ll try to get a free time slot (with a required duration) in the Nimble events queue. 1). Only consider Nimble connection events, do not consider scanning events, so only look at the scheduled