Re: What are the best config settings to reduce ram usage, so that an app runs in 16 kb with least impact on functionality?

LE Data Packet Length Extension feature enabled, would mbuf > block size of 100 still work? Could a PDU occupy more than one mbuf (e.g. > two consecutive blocks)? > > Best, > > Khaled > > On Fri, Jun 16, 2017 at 9:08 PM, will sanfilippo <wi...@runtime.io> wrote: >

Re: What are the best config settings to reduce ram usage, so that an app runs in 16 kb with least impact on functionality?

Alfred: Another thing with the nimble stack. The mbuf block size of 292, which Chris shows reduced to 200, is much larger than it needs to be. I am not sure what the smallest size actually is, but you can set it to 100 bytes and it should work. This can get you more buffers and/or reduce your

Re: Conditional compilation based on BSP name

Ugo: Just as a preface, BSPs are intended to be examples of how one could create a BSP for their own system. It was assumed/expected that folks would take these BSPs and modify them for their own use. Well, at least I thought so anyway. Another decision we made in the BSP and one that we have

Re: Conditional compilation based on BSP name

Ugo: I believe that there is -DBSP_NAME passed to everything. Here is an excerpt debug output from a build. You can see BSP_NAME=nrf52dk 2017/06/14 09:07:57.635 [DEBUG] arm-none-eabi-gcc -DADC_ENABLED=0 -DAPP_NAME=bletest -DAPP_bletest -DARCH_NAME=cortex_m4 -DARCH_cortex_m4 -DBLETEST

Re: [RFC] experimental features and APIs

Not sure that I sent a reply about this but I meant to :-) Seems fine to me. > On Jun 12, 2017, at 4:58 AM, Szymon Janc wrote: > > Hi, > > I was wondering on how we could add 'experimental' features or APIs to Mynewt. > My rationale is that sometimes we may want to

Re: MYNEWT-490

Seems fine to me. > On Jun 12, 2017, at 4:01 PM, marko kiiskila wrote: > > Hi, > > part of the ticket includes renaming os_tick_idle() and os_tick_init() -> > hal_os_tick_idle() and > hal_os_tick_init(), respectively. > > This is a name change in the API, but this contract

Re: BLE connection timeout

Jan: I am not 100% sure but we have seen issues with certain phones due to how the nimble stack controller starts some LL control procedures. This has been addressed in a development branch but I do not think it has been merged into the master branch yet (it will in the upcoming release). I

Re: FCC Pre-scan

uys be interested in patches/mechanisms that > help people with the FCC test? > > Jitesh > > On Thu, Jun 8, 2017 at 4:40 PM, will sanfilippo <wi...@runtime.io> wrote: > >> Question 2: Unless it got added recently and I did not catch it, currently >> the nimble

Re: FCC Pre-scan

Question 2: Unless it got added recently and I did not catch it, currently the nimble stack does not provide support for the FCC test. Question 1: I guess it depends what you mean by take over control. The call to ble_phy_disable() will certainly halt anything going on in the radio. However,

Re: #if directives and the MYNEWT_VAL(..) macro

This is not a bug although some folks might want these things turned on by default. It might also be a bit confusing and hard to find in code or documentation, but the default for alot of these peripheral config variables are by default 0. You need to turn them on if you want to use a certain

Re: nrf52 uicr

Pierre: Accessing the UICR is pretty simple. There is a structure defined in nrf52.h that can be used to read the customer variables. You just do this: NRF_UICR->CUSTOMER[0] Note that Aditi has pointed out that we decided to use some of the customer registers by default. You can change this

Re: Tx Power Adjustment on the nRF52dk

gt; wrote: > >> Ah... interesting. Thanks for the tip... I see the code you're talking >> about. I'll try this out. >> >> Thanks! >> >> On Mon, May 15, 2017 at 4:47 PM, will sanfilippo <wi...@runtime.io> wrote: >> >>> This is definitely a b

Re: Tx Power Adjustment on the nRF52dk

This is definitely a bit confusing in the current code base. To set advertising power for a particular advertising state machine you need to use the multi-advertising code. If you see the code in this function: ble_ll_adv_set_adv_params() you will see that the advsm->adv_txpwr element gets set

Re: Writing PWM api, and nrf51 implementation

split-central-misfit-flash/app/hw/drivers/lf_pwm/hw_drivers_lf_pwm.a(lf_pwm.o): > In function `lf_pwm_init': > /Users/jacobrosenthal/Downloads/chippd3/repos/mynewt-nordic/hw/drivers/lf_pwm/src/lf_pwm.c:182: > undefined reference to `app_timer_init' > collect2: error: ld returned 1 exit s

Re: Writing PWM api, and nrf51 implementation

Jacob: Does the nrf51 have a PWM peripheral? I do not think it does. I looked at the chip spec and nrf51.h and there is no PWM peripheral like the nrf52 in either. > On May 13, 2017, at 7:46 PM, Jacob Rosenthal wrote: > > Im attempting to write a pwm api and nrf51

Re: OS starting before main

; //... >> } >>} > > It is likely that being careful about the order of initialised tasks is the > answer and I just preferred it when I had control over when the OS started! > > Also thanks

Re: Question Regarding Multiple Advertising Instances (BLE_MULTI_ADV_SUPPORT)

o the > host code will be welcomed as well. > > -Gurpreet > > > > On Wed, May 10, 2017 at 4:05 PM, will sanfilippo <wi...@runtime.io> wrote: > >> Hello Gurpreet: >> >> So a few things here: >> >> The multi-advertising support that wa

Re: Question Regarding Multiple Advertising Instances (BLE_MULTI_ADV_SUPPORT)

Hello Gurpreet: So a few things here: The multi-advertising support that was added was “vendor specific”, meaning that it is (or shall I say was) not in the BLE specification at the time the code was written. Bluetooth 5 adds support for multi-advertising and that standard support will be

Re: Problems with erasing flash on nordic devices

then have to deal with reconnecting after any disconnects. > On May 5, 2017, at 5:34 PM, Jacob Rosenthal <jakerosent...@gmail.com> wrote: > > Im not erasing. It is auto erasing on upload. So I cant upload. > > On Fri, May 5, 2017 at 5:32 PM, will sanfilippo <wi...@runt

Re: Problems with erasing flash on nordic devices

possible to update an nrf51 device over ble. *When I > reconnect, it erases again, and again drops the connection. > > So perhaps theres a good way to determine if an image is present and if an > erase is necessary? > > > > On Fri, May 5, 2017 at 5:02 PM, will sanfilippo

Re: newtmgr image upload nrf51dk disconnects with reason=8

> > Does flash erase disable interrupts? > I.e. would running newtmgr on a separate thread help? > >> On Apr 20, 2017, at 4:14 PM, will sanfilippo <wi...@runtime.io> wrote: >> >> Hello: >> >> They are both related (in a way). When you increase the sl

Re: newtmgr image upload nrf51dk disconnects with reason=8

Hello: They are both related (in a way). When you increase the slave latency the supervision timeout sort of increases along with it (in a manner so speaking). The minimum supervision timeout is this: (1 + connSlaveLatency) * connInterval * 2. So if you increase the slave latency you need to

Re: newtmgr image upload nrf51dk disconnects with reason=8

I wonder if this issue is related to other controllers that we have had issues with. Try disabling Data Length Extension. Set BLE_LL_CFG_FEAT_DATA_LEN_EXT in net/nimble/controller/syscfg.yml to 0 Let us know if that changes anything. > On Apr 16, 2017, at 6:13 PM, Jacob Rosenthal

Re: MyNewt and Ignite demo at ApacheCon

Hello Dennis: I have not tried this myself but a colleague pointed me at this: https://www.allaboutcircuits.com/technical-articles/getting-started-with-openocd-using-ft2232h-adapter-for-swd-debugging/ So you could use mynewt and openocd to download something to the adafruit feather board

Re: [DISCUSS] Release policy update for handling feature branches

I think you are correct about this. Someone needs to determine which pull requests against master need to get merged into the various branches. > On Apr 14, 2017, at 11:54 AM, aditi hilbert wrote: > > Hi all, > > It’s good to see our Release policy going into effect post 1.0

Re: Bluetooth 5 support - configurability

11:50 AM, Łukasz Rymanowski > <lukasz.rymanow...@codecoup.pl> wrote: > > Hi, > > On 10 April 2017 at 18:15, will sanfilippo <wi...@runtime.io> wrote: > >> I think #3 is fine as well. If, for some reason, folks do not want to >> claim 5.0 suppor

Re: DC/DC regulator enable for nrf52. Where should it go?

ing whether called by boot > loader or actual system. > > Sterling > >> On Apr 10, 2017, at 6:53 PM, will sanfilippo <wi...@runtime.io> wrote: >> >> Thinking about this more… (which is almost never a good thing with me): >> >> Cortex-M MCU manufactur

Re: DC/DC regulator enable for nrf52. Where should it go?

upgradable. > > Sterling > > On 7 Apr 2017, at 16:32, will sanfilippo wrote: > >> Hello: >> >> I want to add some code that enables the DC/DC regulator for the nordic >> chips. Enabling this regulator reduces power consumption (considerably). For >> exa

Re: Bluetooth 5 support - configurability

I think #3 is fine as well. If, for some reason, folks do not want to claim 5.0 support they can always use release 1.0.0 of Mynewt. > On Apr 10, 2017, at 6:16 AM, Szymon Janc wrote: > > Hello Community, > > We are currently upstreaming Bluetooth 5 functionality into

Re: Use of os_error_t and OS_OK

0 and -1 are SYS_EOK and SYS_EUNKNOWN (new value) respectively, and can be > safely returned as numbers not defines. > > * For other errors, the SYS_* equivalents should be returned. > > Thoughts? > > Sterling > > On 10 Apr 2017, at 16:38, will sanfilippo wrote

Re: I2C not working on nrf52xxx's rb-nano2

Just an FYI: I was playing around with some code for something I was working on and I was able to disable UART0 although I did not try to re-purpose the pins. The UART was certainly not enabled did not attempt to grab the gpio. This was using the nrf52dk bsp though. Anyway, I think it worth a

Re: Use of os_error_t and OS_OK

Not sure if anyone answered this. This is just my opinion of course: * The OS functions should use return type os_error_t. * Those functions should return OS_OK or some other OS error. * Checks against functions with type os_error_t should be against OS_OK and not 0. The bubbling up of errors,

Re: I2C not working on nrf52xxx's rb-nano2

com/RedBearLab/nRF51822-Arduino/issues/38#issuecomment-186752735 > [2] > https://github.com/limal/incubator-mynewt-core/commit/3510504c5cccde7de54086672cde15f945b79a3e > > On Sun, Apr 9, 2017 at 5:30 PM, will sanfilippo <wi...@runtime.io> wrote: > >> Just an FYI: &

DC/DC regulator enable for nrf52. Where should it go?

Hello: I want to add some code that enables the DC/DC regulator for the nordic chips. Enabling this regulator reduces power consumption (considerably). For example, using the LDO when running from flash (cache enabled) is typically 7.4mA; using the DC/DC regulator it goes to 3.7 mA. It would

Re: Problem loading images to nRF52DK board

BTW, I am curious: what modifications are you going to make to the controller? If you do not want or cannot say, no problem. Just interested to hear different use cases/modifications that folks want to do. Oh, and my post was just to get you going quickly; I am sure we can debug your issue. >

Re: Problem loading images to nRF52DK board

Hello Greg: Not sure why you are having problems using the newt tool to download, but JLinkExe can load binary files. There is a command called “loadbin” that will allow you to load a binary file at a given location. Load the bootloader at 0 and the img file that you created at address 0x8000.

Re: Adding platform specific API to get public and/or random static address

Marcel: Thanks for the clarification on the public address and that for BLE the two LSbits of the MSbyte do not apply. I do understand the trickiness of changing the public address but it is certainly helpful for debugging/testing. > On Apr 3, 2017, at 9:38 AM, Marcel Holtmann

Re: Adding platform specific API to get public and/or random static address

Setting the public address from the host came from two things: bletiny and also my recollection of one of the vendor specific HCI commands that was discussed at Linaro Connect in Budapest this past March. I am trying to find the document we discussed in Budapest to confirm that this was one of

Re: Adding platform specific API to get public and/or random static address

Comments inline: > On Apr 1, 2017, at 12:53 AM, Marcel Holtmann wrote: > > Hi Will, > >> There has been some discussion of this already on the list but nothing has >> been done yet so I wanted to resurrect the conversation with some proposals. >> >> What we are trying to

Re: Adding platform specific API to get public and/or random static address

. Thanks for clarifying that! (and reading that long email) Will > On Mar 31, 2017, at 4:28 PM, Christopher Collins <ch...@runtime.io> wrote: > > On Fri, Mar 31, 2017 at 03:49:05PM -0700, will sanfilippo wrote: >> Hello: >> >> There has been some discussion of thi

Adding platform specific API to get public and/or random static address

Hello: There has been some discussion of this already on the list but nothing has been done yet so I wanted to resurrect the conversation with some proposals. What we are trying to do here is the following: 1) Have the controller get a public device address without it being hardcoded. 2) Have

Commit of low power timer support (for nordic platforms)

Hello: Low power timer support for the nordic platforms (both nrf51 and nrf52) was just committed to develop. Here is a basic explanation of the changes and how to turn it on/off. Note that while a reasonable amount of testing was done on this code a bit more needs to be done to verify that

Re: Query on application: Bare metal or using Mynewt RTOS

Amit: I cannot be sure but I think I understand the problem you are having. The nordic delay routines do not use the OS and thus you are sitting in that loop constantly. The watchdog is enabled and you are probably watch dogging since the task that is supposed to tickle the watchdog is not

Re: Initial commit of the "bsn" branch (body sensor network) branch

uling in Bluetooth for/what were the application > requirements you were engineering for? > > Sterling > > On 21 Mar 2017, at 16:21, will sanfilippo wrote: > >> Hello: >> >> Disclaimers: >> 1) Long email follows. >> 2) This is a preliminary ver

Initial commit of the "bsn" branch (body sensor network) branch

Hello: Disclaimers: 1) Long email follows. 2) This is a preliminary version of this code. There are hard-coded things and things I had to hack, mainly because of my ignorance of some areas in the code. I pushed it so some folks (if they want) can take a look and mess around before things get

Re: Debugging blecent application on nrf52dk

oothCore v4.2 spec in > section 5.1.9 - Data Length Update Procedure. > I agree with your conclusion that it sounds like the controller must accept > LL_UNKNOWN_RSP but must not require it. > Thanks again this was really very helpful. > -Pritish > > On Fri, Mar 17, 2017 at 11:0

Re: Debugging blecent application on nrf52dk

o enable data length > extension with the bleprph but that is failing? > > Thanks, > Pritish > > On Fri, Mar 17, 2017 at 10:11 AM, will sanfilippo <wi...@runtime.io> wrote: > >> BTW: Lukasz did have a really good suggestion for future debugging (why >> didnt I

Re: Debugging blecent application on nrf52dk

>stqe_next = 0x0 > > } > >}, > >c_evq = 0x2000313c, > >c_ticks = 0x0, > >c_next = { > > tqe_next = 0x0, > > tqe_prev = 0x0 > >} > > }, > > enc_data = { > >enc_state = 0x1,

Re: Debugging blecent application on nrf52dk

I do not think there is a simple way to debug this. As Chris points out, the first problem is a LL control procedure timeout. I think I can help figure some things out there. There is a function called ble_ll_ctrl_proc_rsp_timer_cb. If you set a breakpoint at this function in the debugger when

Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?

> Thanks, > Pritish > > On Mon, Mar 13, 2017 at 3:07 PM, amit mehta <gmate.a...@gmail.com> wrote: > >> On Mon, Mar 13, 2017 at 10:24 PM, will sanfilippo <wi...@runtime.io> >> wrote: >>> amit: >>> >>> A couple of things: >>&g

Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?

Amit: I do not have a really strong opinion here, so would be interested to hear what others think. I am referring to the API. Certainly, the “get_devaddr” API is appropriate for the nrf chips but not sure if we would want to have multiple API in case we want to port this to other chips and

Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?

thers think? > On Mar 13, 2017, at 1:32 PM, amit mehta <gmate.a...@gmail.com> wrote: > > On Mon, Mar 13, 2017 at 6:06 PM, will sanfilippo <wi...@runtime.io> wrote: >> amit: >> >> There is already a function to return the device id. It is named >> ha

Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?

amit: There is already a function to return the device id. It is named hal_bsp_hw_id() and exists in hw/mcu/nordic/nrf52xxx/src/nrf52_hw_id. Many chips come with some form of unique id which was why this was placed in hw/mcu. I do not think I would put the API for ble device address in the

Re: How to verify porting MyNewt to another board was success?

Well, there are a number of ways to verify that the port is successful. If you get blinky up and running you can be pretty assured that the gpio and core os are working on your board. There are other apps that test other functionality so depending on what you want to verify, you would choose

Re: Hackillinois this weekend in Urbana IL

Do not know how helpful this will be and it is just my own two cents so take it for what it is worth :-) First, this is more of a favor/ask: if you have folks going through the installation process and the documentation, any feedback you can provide on what was easy/good/hard/bad/confusing

Re: Resources Reserved for Mynewt

I dont think a document exists which details all of the used resources. Obviously, it is based on the packages that are used in your application. Some general information: OS uses TIMER1 or RTC1 (for os time) Nimble stack uses TIMER0 for high resolution timer. Nimble stack uses a number of the

Re: Issues with bleprph and blecent on nRF51822xxaa

Hello there Marcos: Indeed, some of the sample apps probably wont run in 16KB RAM. If a malloc fails it should be pretty easy to debug as I would suspect most mallocs in the code assert() if they cant get the memory. Is there a specific app your want to run? > On Feb 16, 2017, at 8:19 PM,

Re: BLE HCI support on NRF52DK

itialized by driving the RESET signal with a GPIO line. > > ALan > > -Original Message- > From: will sanfilippo [mailto:wi...@runtime.io] > Sent: Monday, February 06, 2017 5:55 PM > To: dev@mynewt.incubator.apache.org > Subject: Re: BLE HCI support on NRF52DK &g

[RESULT][VOTE] Release Apache Mynewt 1.0.0-b2-incubating-rc1

Hello all, Voting for Apache Mynewt 1.0.0-b2-incubating-rc1 is now closed. The release has passed this step of the process. The vote breakdown is as follows: +1 Christopher Collins (binding) +1 Sterling Hughes (binding) +1 Jim Jagielski (binding) +1 Szymon Janc +1 Marko Kiiskila (binding) +1

Re: sysint() fails

David: It seems like, from this email, that things are now working for you. Are you still going to vote -1 or are you going to change your vote? > On Feb 8, 2017, at 5:33 AM, David G. Simmons wrote: > > >> On Feb 7, 2017, at 2:38 PM, marko kiiskila

Re: [VOTE] Release Apache Mynewt 1.0.0-b2-incubating-rc1

> [X ] +1 Release this package > [ ] 0 I don't feel strongly about it, but don't object > [ ] -1 Do not release this package because… > +1 (binding) > Hello all, > I am pleased to be calling this vote for the source release of Apache > Mynewt 1.0.0, beta 2. > > Apache Mynewt is a

Re: [DISCUSS] Release Apache Mynewt 1.0.0-b2-incubating-rc1

t; > I can build and run blinky on both Linux and Mac. > >> On Feb 6, 2017, at 5:35 PM, will sanfilippo <wi...@runtime.io> wrote: >> >> Hi all, >> >> This thread is for any and all discussion regarding the release of >> Apache Mynewt 1.0.0-b2-incubating-rc1. All feedback is welcome. >> >> Thanks, >> Will >

Re: sysint() fails

Hello David: I did not attempt to re-test all the apps you mentioned below, but bletiny on the nrf52dk is working just fine. Another note: the release is on branch 1_0_0_b2_dev. That is the branch I would use, or check out the tag (mynewt_1_0_0_b2_rc1_tag). Thanks > On Feb 7, 2017, at 8:07

[DISCUSS] Release Apache Mynewt 1.0.0-b2-incubating-rc1

Hi all, This thread is for any and all discussion regarding the release of Apache Mynewt 1.0.0-b2-incubating-rc1. All feedback is welcome. Thanks, Will

[VOTE] Release Apache Mynewt 1.0.0-b2-incubating-rc1

Hello all, I am pleased to be calling this vote for the source release of Apache Mynewt 1.0.0, beta 2. Apache Mynewt is a community-driven, permissively licensed open source initiative for constrained, embedded applications. Mynewt provides a real-time operating system, flash file system, network

Re: BLE HCI support on NRF52DK

PM, Andrzej Kaczmarek > <andrzej.kaczma...@codecoup.pl> wrote: > > Hi Will, > > On Fri, Feb 3, 2017 at 7:08 PM, will sanfilippo <wi...@runtime.io> wrote: > >> I might be getting a bit confused here so hopefully I am making some >> sense. I seem to recall

Creating branch for 1.0.0 beta2 release

Hello: Just a heads up. I am going to create the 1.0.0 beta 2 release branch.

Re: interrupt latency in mynewt

Jiacheng: How are you measuring the latency? I presume you have a scope on a GPIO input and maybe set a GPIO high when you are inside the ISR and measure the time between them? Or are you measuring the timing using a task? There is certainly some hard limitation on interrupt response time but

Re: os_time_delay in milliseconds / microseconds

os_cputime_delay_ticks does not put the task to sleep; it was meant for short blocking delays. The nrf_delay_ms() function doesnt put the task to sleep either so I am not sure why you are seeing a difference between the two. > On Jan 26, 2017, at 6:03 AM, then yon wrote:

Re: Scheduling time of Nimble stack

-20ms, this > will cause BLE connections to fail. I will continue to work on this issue. > > Best Regards, > > Jiacheng > > > >> 在 2017年1月25日，14:36，will sanfilippo <wi...@runtime.io> 写道： >> >> Jiacheng >> >> 1) Sorry about not

Re: Scheduling time of Nimble stack

be blocked only within 10us. I have an interrupt with most > high priority, it will take 600us~700us, is it safe to block LL task and > other interrupt such as Nimble Radio and OS time tick during this time? > > Best Regards, > > Jiacheng >

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.

endif >>> >>>sysinit(); >>> >>>while (1) { >>>os_eventq_run(os_eventq_dflt_get()); >>>} >>>assert(0); >>> >>>return rc; >>> } >>> >>> So there’s a call to mcu_sim_pars

Re: Scheduling time of Nimble stack

e 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. >> >> Best Regards,

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: [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: [RFC] Reducing size of BLE Security Manager

I have mixed feelings about packed structures. For processors that cannot handle unaligned accesses I have always found that they increased code size. Every access of an element in that structure needs code to determine the alignment of that element. Sure, they save RAM, so if that is what you

Re: MBUF sizing for the bluetooth stack

Simon: I think you are pretty much correct; generally you are better off with smaller size mbufs. However, there are cases where larger mbufs are better (for example, a very large portion of your data packets are large). > On Jan 19, 2017, at 11:57 PM, Simon Ratner wrote: > >

Re: MBUF sizing for the bluetooth stack

> > On Wed, Jan 11, 2017 at 4:57 PM, will sanfilippo <wi...@runtime.io> wrote: > >> Yes; 76 or 80. Note that I have not actually tested with 80 byte mbuf >> blocks. That is the theory though :-) >> >>> On Jan 11, 2017, at 4:31 PM, Simon Ratner <

Re: sys/stats and sys/log

I think the stub approach is fine as well. > On Jan 17, 2017, at 1:43 PM, Kevin Townsend wrote: > > I don't have any issues with the stub approach myself, and it's easy to > switch back and forth (no more work than changing syscfg.yml) > > > On 17/01/17 22:07, marko

Re: Bluetooth specification question after seeing Android 7.1.1 disconnect

.pl> wrote: > > Hi Will, > > On Tue, Jan 17, 2017 at 5:48 AM, will sanfilippo <wi...@runtime.io> wrote: > >> Hello: >> >> Was wondering if there were any folks out there that could comment on >> something regarding a disconnect issue with an And

Bluetooth specification question after seeing Android 7.1.1 disconnect

Hello: Was wondering if there were any folks out there that could comment on something regarding a disconnect issue with an Android Phone running 7.1.1 and our bluetooth stack (the controller). What appears to be happening is this: * Nimble wants to do Data Length Extension and enqueues a

Re: stopping scan & adv in bleprph example

s because in the bleprph example I don't see any function > being called to put the MCU to sleep. > > Does mynewt OS work the same way as FreeRTOS? > > Best Regards, > Chew > > > > > > On Tue, Jan 17, 2017 at 1:57am, will sanfilippo > <wi...@runtime

Re: stopping scan & adv in bleprph example

If by deep sleep you mean “system off” mode requiring some form of wakeup, it is curently not implemented. You would have to hook that in yourself. > On Jan 16, 2017, at 9:22 AM, Christopher Collins wrote: > > Hi Chew, > > On Mon, Jan 16, 2017 at 11:33:23AM +, Lm Chew

Re: MBUF sizing for the bluetooth stack

Yes; 76 or 80. Note that I have not actually tested with 80 byte mbuf blocks. That is the theory though :-) > On Jan 11, 2017, at 4:31 PM, Simon Ratner <si...@proxy.co> wrote: > > Got it; by minimum size you mean the 76/80 bytes? > > On Wed, Jan 11, 2017 at 4:17 PM

Re: MBUF sizing for the bluetooth stack

a payload size of N, I'd like to specify in syscfg.yml: > >MSYS_1_BLOCK_SIZE: '(N + MBUF_HEADER + PKT_HEADER + LL_OVERHEAD + ...)' > > And magically have optimally-sized buffers. > > > On Wed, Jan 11, 2017 at 11:00 AM, will sanfilippo <wi...@runtime.io> wrote: >

Data Length Extension in Nimble

Hello: In order to take full advantage of Data Length Extension the user should set the following syscfg values to 251. BLE_LL_MAX_PKT_SIZE BLE_LL_CONN_INIT_MAX_TX_BYTES Both of these values should be set to 251 in order for both transmitted and received PDU’s to possibly be as large as 251

Re: How to change the CPU time frequency of mynewt and nimble stack

rchiving bootutil.a >>>>> Error: In file included from aes.c:29:0: >>>>> /Users/jiachengwang/dev/myproj/repos/apache-mynewt-core/crypto/mbedtls/include/mbedtls/config.h:2522:10: >>>>> error: #include expects "FILENAME" or >>>>

Re: How to change the CPU time frequency of mynewt and nimble stack

bout 0.1mA current. I already use NRF_TIMER2 to provide a 4 > MHz clock signal output from GPIO of nRF52. By reading the source code of > apache-mynewt-core, my understanding is that NRF_TIMER0 and NRF_TIMER1 is > already used by mynewt OS and nimble stack, is my understanding correct? &g

Re: How to change the CPU time frequency of mynewt and nimble stack

GPIO of nRF52. By reading the source code of > apache-mynewt-core, my understanding is that NRF_TIMER0 and NRF_TIMER1 is > already used by mynewt OS and nimble stack, is my understanding correct? > > Thanks, > > Jiacheng > >> 在 2017年1月9日，01:10，will sanfilippo <wi..

Re: How to change the CPU time frequency of mynewt and nimble stack

Those should be the only two parameters you need to configure. Must be a bug in the controller :-) I think it is worthwhile to point out that CLOCK_FREQ only changes the units of os cputime; it does not affect the speed at which the processor runs. At least, I could not see any other uses of

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

What I am going to say is obvious, but has anyone hooked up an i2c analyzer to see what is actually going on in the two cases? I dont see why the peripheral would act differently based on the address itself; something must be happening on the bus causing the peripheral to act differently. When

Re: Schedule task with strict fixed timing and variable workload

I think there was some discussion re: HAL PWM but I cannot quite recall the end result. Maybe that this would be a driver instead of a HAL? I agree; PWM is very commonly used so having PWM support (in either driver or HAL form) should be added. > On Dec 26, 2016, at 10:26 AM, Kevin Townsend

Re: Schedule task with strict fixed timing and variable workload

There is nothing in the OS to delay until a specific OS time or to cause the scheduler to periodically wake up at a certain rate. There are different ways to go about doing this and it really depends on what you want. Using a task to guarantee timing can be tricky. Some things to be aware of

Re: System init and OS eventq ensure

just need to do it. Will > On Dec 11, 2016, at 10:55 AM, Christopher Collins <ccoll...@apache.org> wrote: > > On Sun, Dec 11, 2016 at 10:11:44AM -0800, will sanfilippo wrote: >> Personally, I keep wanting to try and have the OS start up right away. > > I wonder if t

Re: System init and OS eventq ensure

Personally, I keep wanting to try and have the OS start up right away. There are definitely “issues” with this: a) We do not want to waste idle task stack. b) When tasks are started they would start running right away. This might cause issues where a task does something to a piece of memory that

Re: 255-byte MTU with iPhones

I have not tried it myself; I cannot recall if Chris tried it. He is currently on a plane but will hopefully chime in on this soon. We do not have iphone throughput numbers but we have throughput numbers that we achieved using two nimble devices: we achieved single connection LL throughput

Re: I2C Pin Setup (nRF52)

I think the issue here is when folks are using the nordic SDK as well as our HAL. The idea was that pin configurations would be in hal_bsp.c; nowhere else. When we moved out the nordic SDK, pin definitions from nrf_drv_config.h were moved into pkg.yml. This made for some conflicts. I have an

The nimble scheduler and multiple advertising instances

Hello: Just wanted to see if folks have any comments about the following topic. This has arisen due to our upcoming addition of allowing for multiple advertising instances. It relates to the “priority” of events in the scheduler (connections and advertising events specifically). To make a

Re: NRF52dk ADC

6> and reading an analog voltage from > it anyway. > > dg > >> On Dec 2, 2016, at 12:06 PM, will sanfilippo <wi...@runtime.io> wrote: >> >> I have not implemented an ADC sensor but I have used the ADC to simply get >> readings from an analog volta

  1   2   3   >