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

Jiacheng: OK, there were some more issues with setting a non-1MHz clock. I tested this with 1, 2 and 4 MHz using LightBlue (ios). I pushed the changes to develop so it should work now (one hopes). > On Jan 10, 2017, at 6:47 PM, WangJiacheng wrote: > > Thanks,

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

Hi Chris, My iOS is the latest 10.2, and the test devices are iPAD mini2, iPhone 6P, iPhone SE, both have the same disconnection issue (after several seconds). With "BLE_LL_CFG_FEAT_DATA_LEN_EXT: 0”, the disconnection issue is still there. Thanks, Jiacheng > 在 2017年1月11日，11:06，Christopher

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

Hi Jiacheng, On Wed, Jan 11, 2017 at 10:47:24AM +0800, WangJiacheng wrote: > More information about nimble stack with 2 MHz CPU frequency. nimble-bleprph > can be connected by LightBlue, but after several seconds, it is disconnected > with message “Disconnected Alert: The peripheral has

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

Thanks, Chris, It’s working now. More information about nimble stack with 2 MHz CPU frequency. nimble-bleprph can be connected by LightBlue, but after several seconds, it is disconnected with message “Disconnected Alert: The peripheral has disconnected.” With 4 MHz CPU frequency,

Re: Getting Unhandled interrupt (17)

Dear Fabio, Thanks for your help, it is working perfectly now. The issues was both radio and swi handler missing. Thank you very much for your help. Regards, Then Yoong Ze On 10/1/2017 8:53 PM, Fabio Utzig wrote: On Tue, Jan 10, 2017, at 07:10 AM, then yon wrote: Beside that the

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

Hi Jiacheng, I think your version of newt is still slightly out of date. You can install the latest as follows: cd $GOPATH/src/mynewt.apache.org/newt/newt && git checkout develop&& git pull origin develop && go install

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

Sterling, Thanks. Yes, the newt is already updated. “newt version” has return "Apache Newt (incubating) version: 1.0.0-dev”. Best Regards, Jiacheng > 在 2017年1月11日，08:58，Sterling Hughes 写道： > > Hi Jiacheng, > > You need to update your newt tool along with the new

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

Hi Jiacheng, You need to update your newt tool along with the new develop. Best, Sterling On 10 Jan 2017, at 16:46, WangJiacheng wrote: Hi, Will, I need more help, I have an error message when compile the target. I’m currently working on the release branch, so upgrade to dev branch by:

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

Hi, Will, I need more help, I have an error message when compile the target. I’m currently working on the release branch, so upgrade to dev branch by: 1. change file project.yml from "vers: 0-latest” to "vers: 0-dev” 2. upgrade to dev branch “newt upgrade” Then compile the target by

State of 1.0.0 beta/rc, develop branch

Hi devs, Just wanted to ask for a quick summary of where the code is going. I see that 1.0.0-b1 was tagged at Nov 29th; is that basically frozen for the 1.0.0 release in terms of compatibility, or will the code currently on develop make it into subsequent 1.0.0 beta/rc releases? If not, is it

Re: macOS Sierra Support

There were two things I needed to do to get GDB to work. You need the latest GDB (which it looks like you have) and then codesign the binary. Even though it refers to an older version of MacOS, I found the following instructions under 2.1 in this webpage helpful:

Re: macOS Sierra Support

If no "brew cleanup" was run, you can always "brew switch" to another version. On Tue, Jan 10, 2017, at 04:00 PM, David G. Simmons wrote: > Oh, yeah, because then it updates your gcc toolchain, and then all hell > breaks loose. There is a way to back one update out. I think I documented > that

Re: macOS Sierra Support

don’t do brew update/brew upgrade (or maybe use homebrew. :-) On 10 Jan 2017, at 9:53, David G. Simmons wrote: I'm running the latest Sierra without issue ... DSimmons-Pro:myproj dsimmons$ newt -v build air_q Building target targets/air_q Loading compiler

Re: macOS Sierra Support

I'm running the latest Sierra without issue ... DSimmons-Pro:myproj dsimmons$ newt -v build air_q Building target targets/air_q Loading compiler /Users/dsimmons/dev/myproj/repos/apache-mynewt-core/compiler/arm-none-eabi-m4, def debug Compiling src in base directory:

macOS Sierra Support

Hi, On the latest develop with the latest macOS Sierra and homebrew, If I have a target: targets/slim_slinky app=apps/slinky bsp=hw/bsp/native build_profile=debug (used to be optimized :-) And I try and build: $ newt run slim_slinky Error: In file included from

Mac OS X App

Like the iOS app, the Mac OS X app (available at https://www.dropbox.com/sh/u7wvu5hianw5thp/AAAnAzPLBB9XwXH4OqZnOyXra?dl=0 ) now does search. You no longer have to conform to any edicts in your app. Search for BLE

Re: 2nd UART on NRF52DK

> On Jan 10, 2017, at 12:02 PM, marko kiiskila wrote: > > the baud rate for senseair UART was 9600bps, so it should be ok. > > I’ve tested the bitbanger on nrf52 with up to 19200 as my console. > If I remember correctly, the hal timer used by the bitbanger was running > at

Re: 2nd UART on NRF52DK

Hi David, the baud rate for senseair UART was 9600bps, so it should be ok. I’ve tested the bitbanger on nrf52 with up to 19200 as my console. If I remember correctly, the hal timer used by the bitbanger was running at 1MHz. > On Jan 10, 2017, at 6:22 AM, David G. Simmons

iOS App Testers

Hi all, Still looking for folks willing to test the iOS app. Here's the latest rundown: 1) You need a device running iOS 10.x (latest iOS) 2) You won't need to make any special changes to your myNewt BLE App a) use the new 'Search' function to find your myNewt device, select the

2nd UART on NRF52DK

I see that the NRF52DK has a second UART defined as a "bit-bang" UART. As I've said earlier, I'm working on the air_quality demo, and part of that is moving it over to the NRF52DK board from the STM32F3-Discovery board. I'm doing is because a) the discovery board doesn't have bluetooth or any

Re: air_quality app

> On Jan 9, 2017, at 6:55 PM, Kevin Townsend wrote: > > I think it should be '/include/pkgname/pgkname.h' for the include files. > Here's an example I have locally with 'tsl2561' as the root folder where this > command was run: > > $ tree -L 3 > . > ├── include > │ └──

Re: Getting Unhandled interrupt (17)

On Tue, Jan 10, 2017, at 07:10 AM, then yon wrote: > Beside that the SWI0_EGU0_IRQHandler is a default peripheral interrupt > handler defined in gcc_startup_nrf52.s (just like TIMER2_IRQHandler); it > doesn't seem to be correct by defining it our-self. gcc_startup_nrf52.s defines weak

Re: Getting Unhandled interrupt (17)

Hi, IRQ 17 is the Radio interrupt handler. I think your implementing a new radio stack (?), e.g. not using Nimble, and may have just overlooked setting up that handler for your stack. Regards Wayne > On 10 Jan 2017, at 09:10, then yon wrote: > > Dear Fabio, > > Sorry

Re: Getting Unhandled interrupt (17)

Dear Fabio, Sorry for the late response, have been interrupted by other task. I have tried on your recommendation but it doesn't make any different. Beside that the SWI0_EGU0_IRQHandler is a default peripheral interrupt handler defined in gcc_startup_nrf52.s (just like TIMER2_IRQHandler); it