HCI UART with console UART

2018-06-27 Thread Jeff Belz
All:

I have to use uart0 as the HCI, but I want to use the console too.   Anyone do 
this before?
I'm assuming I have to change the BSP, but I think it's more that that.

Jeff


Re: Different Bluetooth controller

2018-06-27 Thread Andrzej Kaczmarek
Hi Jeff,

In general, NimBLE host does assume that (depending on features
enabled) certain functionality has to be supported by controller and
it will just try to use it. For example, if Privacy feature is enabled
host assumes that Link Layer Privacy is supported by controller thus
at least 4.2 controller is required for this to work properly. Anyway,
common functions work with 4.1 or even 4.0 controllers - just make
sure to disable all features that controller does not support. On
certain cheap controllers there may be issues during initialization as
they may not like our settings, but that we can usually fix easily.

Best,
Andrzej


On Thu, Jun 28, 2018 at 1:29 AM Jeff Belz  wrote:
>
> All:
>
> I was wondering how mynewt handles different controller.  For example
> CC2564b vs BCM43438
> Both of these have a 4 wire HCI interface, but I would think they would have 
> slightly different command sets.  When working with HCI, is there a list of 
> qualified BT controllers it works with?
>
> Jeff


Re: Different Bluetooth controller

2018-06-27 Thread will sanfilippo
Jeff:

I may not be answering the question you want but the controller itself runs on 
the nordic chips only so you will not be able to run the nimble controller on 
those devices. What *is* supported is the nimble host. The nimble host should 
be able to talk to any controller. The set of HCI commands used is standard and 
the controller basically tells the host what it supports so you should not have 
issues there.

Let us know if you have futher questions.

Will

> On Jun 27, 2018, at 4:29 PM, Jeff Belz  wrote:
> 
> All:
> 
> I was wondering how mynewt handles different controller.  For example
> CC2564b vs BCM43438
> Both of these have a 4 wire HCI interface, but I would think they would have 
> slightly different command sets.  When working with HCI, is there a list of 
> qualified BT controllers it works with?
> 
> Jeff



Different Bluetooth controller

2018-06-27 Thread Jeff Belz
All:

I was wondering how mynewt handles different controller.  For example
CC2564b vs BCM43438
Both of these have a 4 wire HCI interface, but I would think they would have 
slightly different command sets.  When working with HCI, is there a list of 
qualified BT controllers it works with?

Jeff


Re: bleprph using HCI 4 wire

2018-06-27 Thread Andrzej Kaczmarek
Hi Jeff,

It seems you have explicit dependency to net/nimble/transport/ram
somewhere in your configuration (target, I suppose) which you need to
remove. bleprph app already includes net/nimble/transport package
which pulls proper HCI transport package depending on
BLE_HCI_TRANSPORT_* syscfg values and with settings you mentioned in
1st post it will automatically pull net/nimble/transport/uart.

bleuart is not updated to use meta-package for HCI transport so in
order to use it with different HCI transport you will need to manually
remove both net/nimble/controller and net/nimble/transport/ram
packages from its pkg.yml. Also there seem to be some includes from
both of these packages in main.c which are probably not needed and
should be removed as otherwise it won't build.

Best,
Andrzej


On Wed, Jun 27, 2018 at 10:03 PM Jeff Belz  wrote:
>
> Nimble error?
> I have tried the bleprph and bleuart  and both fail at this point in the 
> ble_hci_ram.c
>
> assert(ble_hci_ram_rx_cmd_ll_cb != NULL);
>
> Either I'm missing a setting or maybe an error in Nimble
>
> /This is the whole trace
> #12 0x08020b30 in os_eventq_run (evq=) at 
> repos/apache-mynewt-core/kernel/os/src/os_eventq.c:162
> 162 ev->ev_cb(ev);
> (gdb)
> #11 0x08025c12 in ble_hs_event_start (ev=) at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs.c:498
> 498 rc = ble_hs_start();
> (gdb)
> #10 0x08025bf6 in ble_hs_start () at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs.c:563
> 563 ble_hs_sync();
> (gdb)
> #9  0x08025966 in ble_hs_sync () at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs.c:325
> 325 rc = ble_hs_startup_go();
> (gdb)
> #8  0x0802800e in ble_hs_startup_go () at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs_startup.c:341
> 341 rc = ble_hs_startup_reset_tx();
> (gdb)
> #7  0x08027d52 in ble_hs_startup_reset_tx () at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs_startup.c:326
> 326 rc = 
> ble_hs_hci_cmd_tx_empty_ack(BLE_HCI_OP(BLE_HCI_OGF_CTLR_BASEBAND,
> (gdb)
> #6  0x0802696a in ble_hs_hci_cmd_tx_empty_ack (opcode=opcode@entry=3075, 
> cmd=cmd@entry=0x0,
> cmd_len=cmd_len@entry=0 '\000') at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci.c:332
> 332 rc = ble_hs_hci_cmd_tx(opcode, cmd, cmd_len, NULL, 0, NULL);
> (gdb)
> #5  0x08026906 in ble_hs_hci_cmd_tx (opcode=, 
> cmd=cmd@entry=0x0, cmd_len=,
> evt_buf=evt_buf@entry=0x0, evt_buf_len=evt_buf_len@entry=0 '\000', 
> out_evt_buf_len=out_evt_buf_len@entry=0x0)
> at repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci.c:294
> 294 rc = ble_hs_hci_cmd_send_buf(opcode, cmd, cmd_len);
> (gdb)
> #4  0x08026efc in ble_hs_hci_cmd_send_buf (opcode=opcode@entry=3075, 
> buf=buf@entry=0x0,
> buf_len=buf_len@entry=0 '\000') at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci_cmd.c:122
> 122 return ble_hs_hci_cmd_send(opcode, buf_len, buf);
> (gdb)
> #3  0x08026d0e in ble_hs_hci_cmd_send (opcode=opcode@entry=3075, 
> len=len@entry=0 '\000', cmddata=cmddata@entry=0x0)
> at repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci_cmd.c:90
> 90  rc = ble_hs_hci_cmd_transport(buf);
> (gdb)
> #2  0x08026c9e in ble_hs_hci_cmd_transport (cmdbuf=cmdbuf@entry=0x0)
> at repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci_cmd.c:42
> 42  rc = ble_hci_trans_hs_cmd_tx(cmdbuf);
> (gdb)
> #1  0x0802e834 in ble_hci_trans_hs_cmd_tx (cmd=cmd@entry=0x0)
> at repos/apache-mynewt-nimble/nimble/transport/ram/src/ble_hci_ram.c:89
> 89  assert(ble_hci_ram_rx_cmd_ll_cb != NULL);
> (gdb)
> #0  __assert_func (file=file@entry=0x0, line=line@entry=0, 
> func=func@entry=0x0, e=e@entry=0x0)
> at repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:137
> 137asm("bkpt");
>
> -Original Message-
> From: Christopher Collins 
> Sent: Monday, June 25, 2018 11:25 PM
> To: dev@mynewt.apache.org
> Subject: Re: bleprph using HCI 4 wire
>
> Hi Jeff,
>
> My responses are inline.
>
> On Tue, Jun 26, 2018 at 02:11:46AM +, Jeff Belz wrote:
> > All:
> >
> >
> > I'm using a BroadCom(Cypress)43438 Bluetooth chip that receives a 4
> > wire HCI.  I got one response that said I just have to change the
> > syscfg setting in my target to
> >
> >
> >
> > BLE_HCI_TRANSPORT_NIMBLE_BUILTIN: 0
> > BLE_HCI_TRANSPORT_UART: 1
> >
> >   1.  I can't find any documentation to what these lines do?
>
> The documentation for syscfg settings is in the packages themselves.
> Both of the above settings are defined by the 
> @apache-mynewt-nimble/nimble/transport package.  You can see the full list of 
> settings in a project, along with their descriptions, with this
> command:
>
> newt target config show 
>
> However, I don't think you will see either of these settings if you execute 
> this command.  From the dependency list you quoted, it looks like you are 
> using an older version of Mynewt which 

Re: bleprph using HCI 4 wire

2018-06-27 Thread Christopher Collins
Hi Jeff,

The `ble_hci_ram_rx_cmd_ll_cb` callback should be getting configured by
the controller at startup (assuming you are running the
combined-host-controller).

I have a few questions:
1. What version of Mynewt are you using?
2. What changes have you made to the apps that are failing?

Also, could you please post your bleprph target?  You can display it
with:

newt target show 

Thanks,
Chris

On Wed, Jun 27, 2018 at 08:03:06PM +, Jeff Belz wrote:
> Nimble error?
> I have tried the bleprph and bleuart  and both fail at this point in the 
> ble_hci_ram.c
> 
> assert(ble_hci_ram_rx_cmd_ll_cb != NULL);   
> 
> Either I'm missing a setting or maybe an error in Nimble
> 
> /This is the whole trace
> #12 0x08020b30 in os_eventq_run (evq=) at 
> repos/apache-mynewt-core/kernel/os/src/os_eventq.c:162
> 162 ev->ev_cb(ev);
> (gdb)
> #11 0x08025c12 in ble_hs_event_start (ev=) at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs.c:498
> 498 rc = ble_hs_start();
> (gdb)
> #10 0x08025bf6 in ble_hs_start () at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs.c:563
> 563 ble_hs_sync();
> (gdb)
> #9  0x08025966 in ble_hs_sync () at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs.c:325
> 325 rc = ble_hs_startup_go();
> (gdb)
> #8  0x0802800e in ble_hs_startup_go () at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs_startup.c:341
> 341 rc = ble_hs_startup_reset_tx();
> (gdb)
> #7  0x08027d52 in ble_hs_startup_reset_tx () at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs_startup.c:326
> 326 rc = 
> ble_hs_hci_cmd_tx_empty_ack(BLE_HCI_OP(BLE_HCI_OGF_CTLR_BASEBAND,
> (gdb)
> #6  0x0802696a in ble_hs_hci_cmd_tx_empty_ack (opcode=opcode@entry=3075, 
> cmd=cmd@entry=0x0,
> cmd_len=cmd_len@entry=0 '\000') at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci.c:332
> 332 rc = ble_hs_hci_cmd_tx(opcode, cmd, cmd_len, NULL, 0, NULL);
> (gdb)
> #5  0x08026906 in ble_hs_hci_cmd_tx (opcode=, 
> cmd=cmd@entry=0x0, cmd_len=,
> evt_buf=evt_buf@entry=0x0, evt_buf_len=evt_buf_len@entry=0 '\000', 
> out_evt_buf_len=out_evt_buf_len@entry=0x0)
> at repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci.c:294
> 294 rc = ble_hs_hci_cmd_send_buf(opcode, cmd, cmd_len);
> (gdb)
> #4  0x08026efc in ble_hs_hci_cmd_send_buf (opcode=opcode@entry=3075, 
> buf=buf@entry=0x0,
> buf_len=buf_len@entry=0 '\000') at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci_cmd.c:122
> 122 return ble_hs_hci_cmd_send(opcode, buf_len, buf);
> (gdb)
> #3  0x08026d0e in ble_hs_hci_cmd_send (opcode=opcode@entry=3075, 
> len=len@entry=0 '\000', cmddata=cmddata@entry=0x0)
> at repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci_cmd.c:90
> 90  rc = ble_hs_hci_cmd_transport(buf);
> (gdb)
> #2  0x08026c9e in ble_hs_hci_cmd_transport (cmdbuf=cmdbuf@entry=0x0)
> at repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci_cmd.c:42
> 42  rc = ble_hci_trans_hs_cmd_tx(cmdbuf);
> (gdb)
> #1  0x0802e834 in ble_hci_trans_hs_cmd_tx (cmd=cmd@entry=0x0)
> at repos/apache-mynewt-nimble/nimble/transport/ram/src/ble_hci_ram.c:89
> 89  assert(ble_hci_ram_rx_cmd_ll_cb != NULL);
> (gdb)
> #0  __assert_func (file=file@entry=0x0, line=line@entry=0, 
> func=func@entry=0x0, e=e@entry=0x0)
> at repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:137
> 137asm("bkpt");
> 
> -Original Message-
> From: Christopher Collins  
> Sent: Monday, June 25, 2018 11:25 PM
> To: dev@mynewt.apache.org
> Subject: Re: bleprph using HCI 4 wire
> 
> Hi Jeff,
> 
> My responses are inline.
> 
> On Tue, Jun 26, 2018 at 02:11:46AM +, Jeff Belz wrote:
> > All:
> > 
> > 
> > I'm using a BroadCom(Cypress)43438 Bluetooth chip that receives a 4 
> > wire HCI.  I got one response that said I just have to change the  
> > syscfg setting in my target to
> > 
> > 
> > 
> > BLE_HCI_TRANSPORT_NIMBLE_BUILTIN: 0
> > BLE_HCI_TRANSPORT_UART: 1
> > 
> >   1.  I can't find any documentation to what these lines do?
> 
> The documentation for syscfg settings is in the packages themselves.
> Both of the above settings are defined by the 
> @apache-mynewt-nimble/nimble/transport package.  You can see the full list of 
> settings in a project, along with their descriptions, with this
> command:
> 
> newt target config show 
> 
> However, I don't think you will see either of these settings if you execute 
> this command.  From the dependency list you quoted, it looks like you are 
> using an older version of Mynewt which does not support these two settings.  
> I believe you are using Mynewt 1.3.0; you will want to upgrade to 1.4.0, 
> released about one week ago.  There was a long delay between the releases of 
> 1.3.0 and 1.4.0, and I mistakenly forgot that 1.4.0 was not yet released when 
> I wrote my original email.
> 
> The latest version introduces some fairly major 

RE: bleprph using HCI 4 wire

2018-06-27 Thread Jeff Belz
Nimble error?
I have tried the bleprph and bleuart  and both fail at this point in the 
ble_hci_ram.c

assert(ble_hci_ram_rx_cmd_ll_cb != NULL);   

Either I'm missing a setting or maybe an error in Nimble

/This is the whole trace
#12 0x08020b30 in os_eventq_run (evq=) at 
repos/apache-mynewt-core/kernel/os/src/os_eventq.c:162
162 ev->ev_cb(ev);
(gdb)
#11 0x08025c12 in ble_hs_event_start (ev=) at 
repos/apache-mynewt-nimble/nimble/host/src/ble_hs.c:498
498 rc = ble_hs_start();
(gdb)
#10 0x08025bf6 in ble_hs_start () at 
repos/apache-mynewt-nimble/nimble/host/src/ble_hs.c:563
563 ble_hs_sync();
(gdb)
#9  0x08025966 in ble_hs_sync () at 
repos/apache-mynewt-nimble/nimble/host/src/ble_hs.c:325
325 rc = ble_hs_startup_go();
(gdb)
#8  0x0802800e in ble_hs_startup_go () at 
repos/apache-mynewt-nimble/nimble/host/src/ble_hs_startup.c:341
341 rc = ble_hs_startup_reset_tx();
(gdb)
#7  0x08027d52 in ble_hs_startup_reset_tx () at 
repos/apache-mynewt-nimble/nimble/host/src/ble_hs_startup.c:326
326 rc = 
ble_hs_hci_cmd_tx_empty_ack(BLE_HCI_OP(BLE_HCI_OGF_CTLR_BASEBAND,
(gdb)
#6  0x0802696a in ble_hs_hci_cmd_tx_empty_ack (opcode=opcode@entry=3075, 
cmd=cmd@entry=0x0,
cmd_len=cmd_len@entry=0 '\000') at 
repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci.c:332
332 rc = ble_hs_hci_cmd_tx(opcode, cmd, cmd_len, NULL, 0, NULL);
(gdb)
#5  0x08026906 in ble_hs_hci_cmd_tx (opcode=, cmd=cmd@entry=0x0, 
cmd_len=,
evt_buf=evt_buf@entry=0x0, evt_buf_len=evt_buf_len@entry=0 '\000', 
out_evt_buf_len=out_evt_buf_len@entry=0x0)
at repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci.c:294
294 rc = ble_hs_hci_cmd_send_buf(opcode, cmd, cmd_len);
(gdb)
#4  0x08026efc in ble_hs_hci_cmd_send_buf (opcode=opcode@entry=3075, 
buf=buf@entry=0x0,
buf_len=buf_len@entry=0 '\000') at 
repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci_cmd.c:122
122 return ble_hs_hci_cmd_send(opcode, buf_len, buf);
(gdb)
#3  0x08026d0e in ble_hs_hci_cmd_send (opcode=opcode@entry=3075, 
len=len@entry=0 '\000', cmddata=cmddata@entry=0x0)
at repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci_cmd.c:90
90  rc = ble_hs_hci_cmd_transport(buf);
(gdb)
#2  0x08026c9e in ble_hs_hci_cmd_transport (cmdbuf=cmdbuf@entry=0x0)
at repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci_cmd.c:42
42  rc = ble_hci_trans_hs_cmd_tx(cmdbuf);
(gdb)
#1  0x0802e834 in ble_hci_trans_hs_cmd_tx (cmd=cmd@entry=0x0)
at repos/apache-mynewt-nimble/nimble/transport/ram/src/ble_hci_ram.c:89
89  assert(ble_hci_ram_rx_cmd_ll_cb != NULL);
(gdb)
#0  __assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0, 
e=e@entry=0x0)
at repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");

-Original Message-
From: Christopher Collins  
Sent: Monday, June 25, 2018 11:25 PM
To: dev@mynewt.apache.org
Subject: Re: bleprph using HCI 4 wire

Hi Jeff,

My responses are inline.

On Tue, Jun 26, 2018 at 02:11:46AM +, Jeff Belz wrote:
> All:
> 
> 
> I'm using a BroadCom(Cypress)43438 Bluetooth chip that receives a 4 
> wire HCI.  I got one response that said I just have to change the  
> syscfg setting in my target to
> 
> 
> 
> BLE_HCI_TRANSPORT_NIMBLE_BUILTIN: 0
> BLE_HCI_TRANSPORT_UART: 1
> 
>   1.  I can't find any documentation to what these lines do?

The documentation for syscfg settings is in the packages themselves.
Both of the above settings are defined by the 
@apache-mynewt-nimble/nimble/transport package.  You can see the full list of 
settings in a project, along with their descriptions, with this
command:

newt target config show 

However, I don't think you will see either of these settings if you execute 
this command.  From the dependency list you quoted, it looks like you are using 
an older version of Mynewt which does not support these two settings.  I 
believe you are using Mynewt 1.3.0; you will want to upgrade to 1.4.0, released 
about one week ago.  There was a long delay between the releases of 1.3.0 and 
1.4.0, and I mistakenly forgot that 1.4.0 was not yet released when I wrote my 
original email.

The latest version introduces some fairly major changes, so I suggest you 
upgrade as follows:

1. Download Newt 1.4.0 as described here:
http://mynewt.apache.org/develop/get_started/native_install/index.html

2. Upgrade the Mynewt repos to 1.4.0 by running:

newt upgrade

inside your project directory.

>   2.  How can I make sure it's configuring the right UART?

There is a syscfg setting defined by
@apache-mynewt-nimble/nimble/transport/uart called `BLE_HCI_UART_PORT`.
By default, this is defined to be 0.  You can change its value if you need to 
use a different UART.

>   3.  Do I change the target syscfg or the one in the app folder?

I recommend changing the target's syscfg.  The target configuration overrides 
the app 

Re: newtmgr on Android

2018-06-27 Thread Brian Giori
Hi Andrey,

I have built Android and iOS NewtMgr implementations which are
currently in a "private beta" (if you will) and are still under active
development. The plan is to release these libraries (Apache 2.0) when
they have stabilized, which for Android should be soon.

If you'd like access to the Android repo, I can get you a maven artifact
which you can use in your app to perform firmware upgrades (among
other things). I am using jitpack to host the artifact since the code is
hosted in a private repository on github. In order to get you access to the
jitpack artifacts, I will need the github username for anyone that wants
access.

Brian



On Wed, Jun 27, 2018 at 9:19 AM, Jacob Rosenthal 
wrote:

> I dont know if that runtime sensors app has firmware update, but it has oic
> which would get you close
> https://github.com/runtimeco/android_sensor
>
> Also I have a web bluetooth solution that would work on a lot of android
> phones
> https://github.com/jacobrosenthal/web-newtmgr
>
>
>
> On Wed, Jun 27, 2018 at 8:37 AM andrey.serdt...@yotadevices.com <
> andrey.serdt...@yotadevices.com> wrote:
>
> > Hi all,
> >
> > Does anybody knows if newtmgr is available under Android?
> > The task is to update mynewt device firmware from Android phone.
> >
> > Thank you.
> >
> > BR,
> > Andrey
> >
> >
>


Re: [VOTE] Release Apache Mynewt 1.4.1-rc1

2018-06-27 Thread Sasa Petrovic
+1 (binding)

Best,
Sasa



On Fri, Jun 22, 2018 at 7:14 AM, Szymon Janc  wrote:

> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.4.1.
>
> 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 stacks, and
> support utilities for real-world embedded systems.
>
> This is a bugfix only release fixing BLE connection creation in central
> role
> on Nordic nRF51, flashing issues on Nordic nRF52840 and building errors on
> Windows for newt and newtmgr tools.
>
> For full release notes, please visit the Apache Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> This release candidate was tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test
> +Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.4.1+Test+Results
>
>  Note that only features affected by bugfixes were tested for this
> release. If you feel more testing is needed please provide your results
> here.
>
>   2. The full unit test suite for this release was executed via "newt
>  test all" with no failures.  This testing was performed on the
>  following platforms:
>* OS X 10.13
>* Ubuntu Linux 18.04
>
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/rc1/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit bb43247a7e28a1f5e5d869f1088cb4ae53a1
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit f0ce13e45c51825c35963fb13f2562d5911ef1ed
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit ac0db20a10ea042e253012c30b6261d722e11093
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 4d5d517d2a99c2f2c4b322e872714ea702c1a88f
>
> In addition, the following newt convenience binaries are available:
>   linux: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-
> 1.4.1/
> rc1/apache-mynewt-newt-bin-linux-1.4.1.tgz
>   osx: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-
> 1.4.1/rc1/
> apache-mynewt-newt-bin-osx-1.4.1.tgz
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> --
> pozdrawiam
> Szymon Janc
>
>
>


Re: [VOTE] Release Apache Mynewt 1.4.1-rc1

2018-06-27 Thread Łukasz Rymanowski
Hi

On Fri, Jun 22, 2018, 16:14 Szymon Janc  wrote:

> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.4.1.
>
> 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 stacks, and
> support utilities for real-world embedded systems.
>
> This is a bugfix only release fixing BLE connection creation in central
> role
> on Nordic nRF51, flashing issues on Nordic nRF52840 and building errors on
> Windows for newt and newtmgr tools.
>
> For full release notes, please visit the Apache Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> This release candidate was tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test
> +Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.4.1+Test+Results
>
>  Note that only features affected by bugfixes were tested for this
> release. If you feel more testing is needed please provide your results
> here.
>
>   2. The full unit test suite for this release was executed via "newt
>  test all" with no failures.  This testing was performed on the
>  following platforms:
>* OS X 10.13
>* Ubuntu Linux 18.04
>
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/rc1/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit bb43247a7e28a1f5e5d869f1088cb4ae53a1
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit f0ce13e45c51825c35963fb13f2562d5911ef1ed
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit ac0db20a10ea042e253012c30b6261d722e11093
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 4d5d517d2a99c2f2c4b322e872714ea702c1a88f
>
> In addition, the following newt convenience binaries are available:
>   linux:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/
> rc1/apache-mynewt-newt-bin-linux-1.4.1.tgz
> 
>   osx:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/rc1/
> apache-mynewt-newt-bin-osx-1.4.1.tgz
> 
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ 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)

Best
Łukasz


> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> --
> pozdrawiam
> Szymon Janc
>
>
>
>
>


Re: [VOTE] Release Apache Mynewt 1.4.1-rc1

2018-06-27 Thread Andrzej Kaczmarek
Hi,

+1 (binding)

Best,
Andrzej

On Fri, Jun 22, 2018 at 4:14 PM Szymon Janc  wrote:
>
> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.4.1.
>
> 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 stacks, and
> support utilities for real-world embedded systems.
>
> This is a bugfix only release fixing BLE connection creation in central role
> on Nordic nRF51, flashing issues on Nordic nRF52840 and building errors on
> Windows for newt and newtmgr tools.
>
> For full release notes, please visit the Apache Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> This release candidate was tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test
> +Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.4.1+Test+Results
>
>  Note that only features affected by bugfixes were tested for this
> release. If you feel more testing is needed please provide your results here.
>
>   2. The full unit test suite for this release was executed via "newt
>  test all" with no failures.  This testing was performed on the
>  following platforms:
>* OS X 10.13
>* Ubuntu Linux 18.04
>
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/rc1/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit bb43247a7e28a1f5e5d869f1088cb4ae53a1
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit f0ce13e45c51825c35963fb13f2562d5911ef1ed
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit ac0db20a10ea042e253012c30b6261d722e11093
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 4d5d517d2a99c2f2c4b322e872714ea702c1a88f
>
> In addition, the following newt convenience binaries are available:
>   linux: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/
> rc1/apache-mynewt-newt-bin-linux-1.4.1.tgz
>   osx: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/rc1/
> apache-mynewt-newt-bin-osx-1.4.1.tgz
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> --
> pozdrawiam
> Szymon Janc
>
>


Re: newtmgr on Android

2018-06-27 Thread Jacob Rosenthal
I dont know if that runtime sensors app has firmware update, but it has oic
which would get you close
https://github.com/runtimeco/android_sensor

Also I have a web bluetooth solution that would work on a lot of android
phones
https://github.com/jacobrosenthal/web-newtmgr



On Wed, Jun 27, 2018 at 8:37 AM andrey.serdt...@yotadevices.com <
andrey.serdt...@yotadevices.com> wrote:

> Hi all,
>
> Does anybody knows if newtmgr is available under Android?
> The task is to update mynewt device firmware from Android phone.
>
> Thank you.
>
> BR,
> Andrey
>
>


RE: bleprph using HCI 4 wire

2018-06-27 Thread Jeff Belz
Also  I keep getting these errors when I try to debug, any ideas


Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=0x0, line=0, func=, e=)
at repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
hal_system_reset () at 
repos/apache-mynewt-core/hw/mcu/stm/stm32_common/src/hal_system.c:32
32  asm("bkpt");
(gdb)



-Original Message-
From: Christopher Collins  
Sent: Monday, June 25, 2018 11:25 PM
To: dev@mynewt.apache.org
Subject: Re: bleprph using HCI 4 wire

Hi Jeff,

My responses are inline.

On Tue, Jun 26, 2018 at 02:11:46AM +, Jeff Belz wrote:
> All:
> 
> 
> I'm using a BroadCom(Cypress)43438 Bluetooth chip that receives a 4 
> wire HCI.  I got one response that said I just have to change the  
> syscfg setting in my target to
> 
> 
> 
> BLE_HCI_TRANSPORT_NIMBLE_BUILTIN: 0
> BLE_HCI_TRANSPORT_UART: 1
> 
>   1.  I can't find any documentation to what these lines do?

The documentation for syscfg settings is in the packages themselves.
Both of the above settings are defined by the 
@apache-mynewt-nimble/nimble/transport package.  You can see the full list of 
settings in a project, along with their descriptions, with this
command:

newt target config show 

However, I don't think you will see either of these settings if you execute 
this command.  From the dependency list you quoted, it looks like you are using 
an older version of Mynewt which does not support these two settings.  I 
believe you are using Mynewt 1.3.0; you will want to upgrade to 1.4.0, released 
about one week ago.  There was a long delay between the releases of 1.3.0 and 
1.4.0, and I mistakenly forgot that 1.4.0 was not yet released when I wrote my 
original email.

The latest version introduces some fairly major changes, so I suggest you 
upgrade as follows:

1. Download Newt 1.4.0 as described here:
http://mynewt.apache.org/develop/get_started/native_install/index.html

2. Upgrade the Mynewt repos to 1.4.0 by running:

newt upgrade

inside your project directory.

>   2.  How can I make sure it's configuring the right UART?

There is a syscfg setting defined by
@apache-mynewt-nimble/nimble/transport/uart called `BLE_HCI_UART_PORT`.
By default, this is defined to be 0.  You can change its value if you need to 
use a different UART.

>   3.  Do I change the target syscfg or the one in the app folder?

I recommend changing the target's syscfg.  The target configuration overrides 
the app configuration, and it is best not to change a foreign repo except when 
necessary.  The syscfg system is described in more detail here:
http://mynewt.apache.org/develop/os/modules/sysinitconfig/sysinitconfig.html

>   4.  Do I really need the bootloader? If so, is there documentation to why, 
> I will eventually need to modify this.

The boot loader is not strictly required, but much of the Mynewt infrastructure 
assumes it is present.  When you are getting Mynewt up and running for the 
first time, I recommend you use the boot loader so that you can follow the 
documentation more closely.

Chris


RE: bleprph using HCI 4 wire

2018-06-27 Thread Jeff Belz
A few more questions

1) If I configure to UART 2, what pins does it select.  UART 2 on the STM32F4 
can be configured to different pins.
2) HAL_UART_FLOW_CTL_RTS_CTS <-  Where is this definition
3) When Selection UART 2.  Is that actual UART 2 or is it really UART 1. 
What I mean to say the STM32f412 does not have a UART 0.   It starts from 1.  
So when I type in the "value" 0 in the BLE_HCI_UART_PORT, what UART does it 
select



-Original Message-
From: Christopher Collins  
Sent: Monday, June 25, 2018 11:25 PM
To: dev@mynewt.apache.org
Subject: Re: bleprph using HCI 4 wire

Hi Jeff,

My responses are inline.

On Tue, Jun 26, 2018 at 02:11:46AM +, Jeff Belz wrote:
> All:
> 
> 
> I'm using a BroadCom(Cypress)43438 Bluetooth chip that receives a 4 
> wire HCI.  I got one response that said I just have to change the  
> syscfg setting in my target to
> 
> 
> 
> BLE_HCI_TRANSPORT_NIMBLE_BUILTIN: 0
> BLE_HCI_TRANSPORT_UART: 1
> 
>   1.  I can't find any documentation to what these lines do?

The documentation for syscfg settings is in the packages themselves.
Both of the above settings are defined by the 
@apache-mynewt-nimble/nimble/transport package.  You can see the full list of 
settings in a project, along with their descriptions, with this
command:

newt target config show 

However, I don't think you will see either of these settings if you execute 
this command.  From the dependency list you quoted, it looks like you are using 
an older version of Mynewt which does not support these two settings.  I 
believe you are using Mynewt 1.3.0; you will want to upgrade to 1.4.0, released 
about one week ago.  There was a long delay between the releases of 1.3.0 and 
1.4.0, and I mistakenly forgot that 1.4.0 was not yet released when I wrote my 
original email.

The latest version introduces some fairly major changes, so I suggest you 
upgrade as follows:

1. Download Newt 1.4.0 as described here:
http://mynewt.apache.org/develop/get_started/native_install/index.html

2. Upgrade the Mynewt repos to 1.4.0 by running:

newt upgrade

inside your project directory.

>   2.  How can I make sure it's configuring the right UART?

There is a syscfg setting defined by
@apache-mynewt-nimble/nimble/transport/uart called `BLE_HCI_UART_PORT`.
By default, this is defined to be 0.  You can change its value if you need to 
use a different UART.

>   3.  Do I change the target syscfg or the one in the app folder?

I recommend changing the target's syscfg.  The target configuration overrides 
the app configuration, and it is best not to change a foreign repo except when 
necessary.  The syscfg system is described in more detail here:
http://mynewt.apache.org/develop/os/modules/sysinitconfig/sysinitconfig.html

>   4.  Do I really need the bootloader? If so, is there documentation to why, 
> I will eventually need to modify this.

The boot loader is not strictly required, but much of the Mynewt infrastructure 
assumes it is present.  When you are getting Mynewt up and running for the 
first time, I recommend you use the boot loader so that you can follow the 
documentation more closely.

Chris


Re: Linking of tests when app itself has a main

2018-06-27 Thread marko kiiskila
Hi René,

unittest framework was developed assuming that apps themselves
would not have test suites. Only individual packages/libraries.

So the method you described is pretty much what you’d need to do.
Or alternatively create a library out of the components you want to
create unittests for.

> On Jun 27, 2018, at 11:42 AM, Rene Beckmann  wrote:
> 
> Hello,
> 
> I hope this is the right place to ask this, I'm very sorry if not.
> I am currently experimenting with Apache MyNewt, have written a tiny app
> (apps/simple) and created a test suite (apps/simple/test) for it.
> The apps/simple/test/pkg.yml contains "apps/simple/" as pkg.deps.
> The problem is that my app itself contains a main function, as well as the
> test suite (guarded by #if MYNEWT_VAL(SELFTEST) ). When running "newt test
> apps/simple", newt properly compiles the test, seems to find its main
> function, however it happily overrides it with the one found in the main
> app, so the test does not run. The test project found in the docs tests a
> library, which does not contain a main function, so this is not covered. I
> could help myself by using:
> #if MYNEWT_VAL(SELFTEST)
> #else
> int main...
> #endif
> However, that's neither pretty nor do I believe that this is the correct
> way to do it. Maybe someone can point me to something that makes newt
> ignore the app's main by default?
> 
> Regards,
> René Beckmann
> -- 
> 
> René Beckmann
> 
> Student Assistant
> 
> 
> http://www.itemis.de
> 
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> Amtsgericht Dortmund, HRB 20621
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus,
> Jennifer Fiorentino