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

commit 1 of 50 ?? This says to me: push more often. How can the mynewt community review your work, if you never push it? On Mon, Jan 23, 2017 at 9:02 PM, wrote: > Repository: incubator-mynewt-core > Updated Branches: > refs/heads/sensors_branch 6247b5afa -> 2681044e8 > >

Re: Scheduling time of Nimble stack

Thanks, Will, It seems I can not get the things work by the simple way. I just want to find out a free time slot at high level to access PHY resource such as CPU and radio RF exclusively. With your explain, I should interleave my events into BLE events at low level in the same schedule queue.

Re: Scheduling time of Nimble stack

Jiacheng: First thing with the code excerpt below: TAILQ_FIRST always gives you the head of the queue. To iterate through all the queue elements you would use TAILQ_FOREACH() or you would modify the code to get the next element using TAILQ_NEXT. I would just use TAILQ_FOREACH. There is an

Re: bleuart example causes crash

Hi Chris, Thanks, now it no longer get the crash message. 0:[ts=0ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x03 ocf=0x0003 len=0 2:[ts=15624ssb, mod=4 level=0] 0x03 0x0c 0x00 3:[ts=23436ssb, mod=4 level=0] Command complete: cmd_pkts=1 ogf=0x3 ocf=0x3 sta 5:[ts=39060ssb, mod=4 level=0]

Scheduling time of Nimble stack

Hi, I’m trying to find out a free time slot between Nimble scheduled events. I try to go through all items on the schedule queue global variable “g_ble_ll_sched_q” to find out all the scheduled LL events near future, function as

newtmgr firmware update with BLE transport

Anybody used the ble transport for newtmgr image update? Im told it doesnt work in osx, anyone have a link to an open issue? I havent gotten in linux docker or native yet either. nrf51 16kbram, bleloader with splitty app, all upstream sources, newtmgr with serial confirmed working dfu service

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

Looks like this breaks splitty as app, bleprph as loader Error: Syscfg ambiguities detected: Setting: OS_MAIN_TASK_PRIO, Packages: [apps/bleprph, apps/splitty] Setting history (newest -> oldest): OS_MAIN_TASK_PRIO: [apps/splitty:10, apps/bleprph:1, kernel/os:0xfe] Setting

Re: bleuart example causes crash

Hi Chew, It looks like the problem is a broken task handler. In bleuart's main.c, the bleuart_task_handler() function should call os_eventq_run() in an infinite loop, but it only calls it once. Marko just fixed this bug in develop with his default task changes. Chris On Fri, Jan 20, 2017 at

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

I pushed this change to develop. You’ll need to update the newt tool as part of this change; as sysinit calls should not include call to os_init() anymore. After this change you can specify multiple calls to be made to your package from sysinit(). Tell newt to do this by having this kind of

Re: Program board without J-Link/OpenOCD.

Hi Marcos, > On Jan 23, 2017, at 8:34 AM, Marcos Scheeren wrote: > > I'm using a Black Magic Probe to program my nRF51822xxAA 16k RAM based > boards, (which all worked well with the Nordic SoftDevice and RIOT OS). > After a lot of hacking and fiddling I got the Blinky

Re: [RFC] endianness API cleanup

Szymon: Indeed, those endianness macros were put in ble.h because they were non-standard and acted on a buffer as opposed to just swapping bytes. Internally (quite some time ago) we debated using packed structures for PDU protocol elements and we just never ended up deciding on what to do

Re: Program board without J-Link/OpenOCD.

Hi Marcos, I don't know if I can solve this problem, but I can at least answer a few of your questions. Hopefully someone more knowledgeable can fill in the gaps. On Mon, Jan 23, 2017 at 02:34:11PM -0200, Marcos Scheeren wrote: [...] > To my understanding, the newt create-image command outputs

Program board without J-Link/OpenOCD.

Hi, I'm using a Black Magic Probe to program my nRF51822xxAA 16k RAM based boards, (which all worked well with the Nordic SoftDevice and RIOT OS). After a lot of hacking and fiddling I got the Blinky example and Console/Shell over UART running. The issue is that the BMP connects to the board