[jira] [Resolved] (MYNEWT-365) newt can't handle files with spaces

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-365.

Resolution: Fixed

Thanks Tim.  I agree with everything you said.  There really was no reason we 
were using the shell to execute external commands other than convenience.

I have pushed a fix for this ticket.  Now newt uses the Go exec package to 
execute external commands.

> newt can't handle files with spaces
> ---
>
> Key: MYNEWT-365
> URL: https://issues.apache.org/jira/browse/MYNEWT-365
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Affects Versions: v0_9_0
> Environment: Any
>Reporter: Tim
>    Assignee: Christopher Collins
>Priority: Minor
>
> I was just looking at the code that decides where gcc is run from (so I can 
> see if I can make it always run from /workspace, so full paths are used), 
> when I noticed you don't handle program arguments properly.
> See [this 
> code|https://github.com/apache/incubator-mynewt-newt/blob/8abc4f2c2bb1ab784a854cdf5662e79d88a41407/newt/toolchain/compiler.go#L262]
> {code}
>   cmd += " -c " + "-o " + objPath + " " + file +
>   " " + c.cflagsString() + " " + c.includesString()
> {code}
> Command line arguments should be stored as a {{[]string}} instead of a 
> space-delimited {{string}}. Then you don't need to worry about spaces or 
> escaping or anything like that. In other words something like this:
> {code}
> func (c *Compiler) CompileFileCmd(file string,
>   compilerType int) ([]string, error) {
>   objFile := strings.TrimSuffix(file, filepath.Ext(file)) + ".o"
>   objPath := filepath.ToSlash(c.dstDir + "/" + objFile)
>   cmd := make([]string)
>   switch compilerType {
>   case COMPILER_TYPE_C:
>   cmd = cmd.append(c.ccPath)
>   case COMPILER_TYPE_ASM:
>   cmd = cmd.append(c.asPath)
>   default:
>   return nil, util.NewNewtError("Unknown compiler type")
>   }
>   cmd = append(cmd, "-c", "-o", objPath, file)
>   // There will be some special handling for these, depending on what 
> they contain (I'm not sure of the format of these exactly).
> //c.cflagsString(), c.includesString()
>   return cmd, nil
> }
> {code}
> And then don't use ShellCommand() to run it. Is there any reason that you're 
> using {{sh -c}} rather than just running the command directly? It's going to 
> make porting to Windows a pain. Similarly for code like this:
> {code}
> func CopyFile(srcFile string, destFile string) error {
>   _, err := ShellCommand(fmt.Sprintf("mkdir -p %s", 
> filepath.Dir(destFile)))
>   if err != nil {
>   return err
>   }
>   if _, err := ShellCommand(fmt.Sprintf("cp -Rf %s %s", srcFile,
>   destFile)); err != nil {
>   return err
>   }
>   return nil
> }
> {code}
> That won't work on Windows and also won't work with files containing spaces. 
> Better to use Go's proper functions for creating directories and copying 
> files. (Unfortunately there isn't a built-in equivalent of {{cp -Rf}} but if 
> you google it there is lots of example code.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-499) newt - APP_NAME value ambiguous for split images

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-499:
--

 Summary: newt - APP_NAME value ambiguous for split images
 Key: MYNEWT-499
 URL: https://issues.apache.org/jira/browse/MYNEWT-499
 Project: Mynewt
  Issue Type: Bug
  Components: Newt
Reporter: Christopher Collins
Assignee: Sterling Hughes


Newt automatically creates a few macros on the command line when it builds a 
target:

* {{ARCH_}}
* {{ARCH_NAME=""}}
* {{APP_}}
* {{APP_NAME=""}}
* {{BSP_}}
* {{BSP_NAME=""}}

There is a problem with the two APP defines.  A split image consists of two 
apps (the "loader" and the "app"), so there is not a single correct value to 
specify during compilation.

There are two issues here:

* Code cannot rely on consistent values for the APP defines when it is part of 
a split image
* Newt performs unnecessary compiling and linking operations for repeat builds 
of split targets.  This is because the command-line invocation changes between 
builds, as the APP name is not consistent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-498) Newt - depgraph and syscfg calculate twice per build

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-498:
--

 Summary: Newt - depgraph and syscfg calculate twice per build
 Key: MYNEWT-498
 URL: https://issues.apache.org/jira/browse/MYNEWT-498
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins


Building with -ldebug shows that dependencies, syscfg, and APIs get resolved 
twice.  In the code, this happens in the following places:
* {{resolve/resolve.go (ResolveCfg())}}
* {{builder/build.go (PrepBuild())}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYNEWT-491) Double calling init functions should be disallowed

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-491.

Resolution: Fixed

> Double calling init functions should be disallowed
> --
>
> Key: MYNEWT-491
> URL: https://issues.apache.org/jira/browse/MYNEWT-491
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Sysinit
>Affects Versions: v1_0_0_beta1
>Reporter: Sterling Hughes
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> When "init" functions are specified to sysinit, that should be the only place 
> they are called.  They should not be directly called, or bad things happen.
> There should be a macro SYSINIT_ASSERT_CALLED_ONCE() (name it better), at the 
> beginning of these init functions, that asserts on double init.  It can be 
> hard to debug when this function is called twice, and I think it will be very 
> common for users to not notice the init function exported by the package, and 
> instead call it directly, so we should find helpful ways to inform them (at 
> least when build_profile=debug).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-491) Double calling init functions should be disallowed

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-491:
---
Description: 
When "init" functions are specified to sysinit, that should be the only place 
they are called.  They should not be directly called, or bad things happen.

There should be a macro SYSINIT_ASSERT_CALLED_ONCE() (name it better), at the 
beginning of these init functions, that asserts on double init.  It can be hard 
to debug when this function is called twice, and I think it will be very common 
for users to not notice the init function exported by the package, and instead 
call it directly, so we should find helpful ways to inform them (at least when 
build_profile=debug).

  was:
tgcc function anemWhen "init" functions are specified to sysinit, that should 
be the only place they are called.  They should not be directly called, or bad 
things happen.

There should be a macro SYSINIT_ASSERT_CALLED_ONCE() (name it better), at the 
beginning of these init functions, that asserts on double init.  It can be hard 
to debug when this function is called twice, and I think it will be very common 
for users to not notice the init function exported by the package, and instead 
call it directly, so we should find helpful ways to inform them (at least when 
build_profile=debug).


> Double calling init functions should be disallowed
> --
>
> Key: MYNEWT-491
> URL: https://issues.apache.org/jira/browse/MYNEWT-491
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Sysinit
>Affects Versions: v1_0_0_beta1
>    Reporter: Sterling Hughes
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> When "init" functions are specified to sysinit, that should be the only place 
> they are called.  They should not be directly called, or bad things happen.
> There should be a macro SYSINIT_ASSERT_CALLED_ONCE() (name it better), at the 
> beginning of these init functions, that asserts on double init.  It can be 
> hard to debug when this function is called twice, and I think it will be very 
> common for users to not notice the init function exported by the package, and 
> instead call it directly, so we should find helpful ways to inform them (at 
> least when build_profile=debug).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-491) Double calling init functions should be disallowed

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-491:
---
Description: 
tgcc function anemWhen "init" functions are specified to sysinit, that should 
be the only place they are called.  They should not be directly called, or bad 
things happen.

There should be a macro SYSINIT_ASSERT_CALLED_ONCE() (name it better), at the 
beginning of these init functions, that asserts on double init.  It can be hard 
to debug when this function is called twice, and I think it will be very common 
for users to not notice the init function exported by the package, and instead 
call it directly, so we should find helpful ways to inform them (at least when 
build_profile=debug).

  was:
When "init" functions are specified to sysinit, that should be the only place 
they are called.  They should not be directly called, or bad things happen.

There should be a macro SYSINIT_ASSERT_CALLED_ONCE() (name it better), at the 
beginning of these init functions, that asserts on double init.  It can be hard 
to debug when this function is called twice, and I think it will be very common 
for users to not notice the init function exported by the package, and instead 
call it directly, so we should find helpful ways to inform them (at least when 
build_profile=debug).


> Double calling init functions should be disallowed
> --
>
> Key: MYNEWT-491
> URL: https://issues.apache.org/jira/browse/MYNEWT-491
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Sysinit
>Affects Versions: v1_0_0_beta1
>    Reporter: Sterling Hughes
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> tgcc function anemWhen "init" functions are specified to sysinit, that should 
> be the only place they are called.  They should not be directly called, or 
> bad things happen.
> There should be a macro SYSINIT_ASSERT_CALLED_ONCE() (name it better), at the 
> beginning of these init functions, that asserts on double init.  It can be 
> hard to debug when this function is called twice, and I think it will be very 
> common for users to not notice the init function exported by the package, and 
> instead call it directly, so we should find helpful ways to inform them (at 
> least when build_profile=debug).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYNEWT-238) newt target build succeeds without a project defined.

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-238.

Resolution: Cannot Reproduce

It looks like this issue has been fixed.

In modern newt-language, the issue was that newt didn't detect when a target 
does not specify an app.

Current behavior:

{noformat}
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newt build blinky-sim
Building target targets/blinky-sim
Error: Target does not specify an app package (target.app)
{noformat}

> newt target build succeeds without a project defined.
> -
>
> Key: MYNEWT-238
> URL: https://issues.apache.org/jira/browse/MYNEWT-238
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Reporter: Paul Dietrich
>        Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> target_test_hcsr04
>   arch=cortex_m0
>   bsp=hw/bsp/arduino_zero
>   compiler=arm-none-eabi-m0
>   compiler_def=debug
>   name=target_test_hcsr04
>   vers=0.0.1
> consider this above.  when I run 
> Pauls-MacBook-Pro-2:larva paulfdietrich$ newt target build target_test_hcsr04
> Successfully run!
> but nothing was compiled or build
>  Obviously I am missing a project, but that didn't seem to matter to new tool



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYNEWT-488) Cleanup legacy branches

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-488.

Resolution: Fixed

> Cleanup legacy branches
> ---
>
> Key: MYNEWT-488
> URL: https://issues.apache.org/jira/browse/MYNEWT-488
> Project: Mynewt
>  Issue Type: Bug
>Affects Versions: v1_0_0_beta1
>Reporter: Sterling Hughes
>        Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> Let's cleanup the legacy branches (i.e. remove them), so that its easier for 
> people to find their way around the code base.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Mynewt 1.0.0-b1-incubating-rc2

[Christopher Collins]

+1 (binding)

Chris

On Tue, Nov 29, 2016 at 06:30:37PM -0800, Christopher Collins wrote:
> Hello all,
> 
> I am pleased to be calling this vote for the source release of Apache
> Mynewt 1.0.0, beta 1 (rc2).  This is the second release candidate for
> Mynewt 1.0.0-b1.  The vote for the first release candidate was cancelled
> due to licensing issues with third-party bundled software.  Details
> concerning what has changed since the previous release candidate can be
> found at the end of this email.
> 
> 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.
> 
> 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.0.0-b1+Test+Results
> 
> 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.10.5
>  * Linux 4.4.6 (Gentoo)
> 
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b1-incubating/rc2/
> 
> The commits under consideration are as follows:
> 
> blinky:
> repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky
> commit: b6918edc174b764f1e0b4ef4f4652aca8fedf8dd
> 
> core:
> repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core
> commit: c6a8f88f6b8dc7c8eee6dc75a34c9b6ea295b05d
> 
> newt:
> repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
> commit: 59ec3af372952382390cfd988e503d8cf3d5b34b
> 
> In addition, the following newt convenience binaries are available:
> linux: 
> https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b1-incubating/rc2/apache-mynewt-newt-bin-linux-1.0.0-b1-incubating.tgz
> osx: 
> https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b1-incubating/rc2/apache-mynewt-newt-bin-osx-1.0.0-b1-incubating.tgz
> 
> 
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS
> 
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PPMC 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.
> 
> As indicated, here is a list of issues with the previous release
> candidate (rc1) that have been resolved:
> * Pointers for several third-party libraries added to the LICENSE
>   files.
> * Some acknowledgements added to core's NOTICE file, as required by
>   the licensing terms of some bundled third-party software.
> * Removal of third-party files with licenses that are incompatible
>   with an Apache project.  Specifically:
> * net/ip/lwip_base/include/netif/ppp/pppoe.h
> * net/ip/lwip_base/include/netif/ppp/vj.h
> * net/ip/lwip_base/src/netif/ppp/pppoe.c
> * net/ip/lwip_base/src/netif/ppp/vj.c
>   These files specified a 4-clause BSD license (or equivalent).
> 
> Thanks,
> Chris

Re: Subscription Request and Question.

[Christopher Collins]

On Wed, Nov 30, 2016 at 08:08:58AM -0800, aditi hilbert wrote:
> Rodrigo,
> 
> The NimBLE description is accurate. Mynewt offers SM. The second one is 
> woefully outdated - I’ll fix that today.
> Yes, NimBLE supports OOB.

A small clarification - nimble supports OOB for legacy pairing, but not for
secure connections.

Chris

[DISCUSS] Release Apache Mynewt 1.0.0-b1-incubating-rc2

[Christopher Collins]

Hello all,

This thread is for any and all discussion regarding the release of
apache-mynewt-1.0.0-b1-incubating-rc2.  All feedback is welcome.

Thanks,
Chris

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

[Christopher Collins]

On Tue, Nov 29, 2016 at 08:04:59AM -0800, Christopher Collins wrote:
> For the rest of the dev list: Justin's fundings are captured in his
> email here:
> https://lists.apache.org/thread.html/b042d83e1985281e8dd8a040ebf1817ce71019c16c5951ca9be11aef@%3Cgeneral.incubator.apache.org%3E

Er, that should be "findings".  Though maybe some funding would be an
easy way out of future -1 votes :).

Chris

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

[Christopher Collins]

Hi Justin,

On Tue, Nov 29, 2016 at 02:20:38PM +1100, Justin Mclean wrote:
> Hi,
> 
> Sorry but I just voted -1 on that release as it has a number of IMO
> significant issues. Given teh great work done on LICENSE/NOTICE
> initially  I had assumed these were being kept upto date but that
> doesn’t seem to be the case.
> 
> Apologies for not catching these issues sooner but with ApacheCon and
> holidays I’ve not had as much time to spend on my mentor/incubator
> roles.

No need to apologize.  I appreciate all the work you've done to keep us
in line :).  I'm sure the rest of the Mynewt community shares that
sentiment.

For the rest of the dev list: Justin's fundings are captured in his
email here:
https://lists.apache.org/thread.html/b042d83e1985281e8dd8a040ebf1817ce71019c16c5951ca9be11aef@%3Cgeneral.incubator.apache.org%3E

Boiling it down, the referenced email identifies three problems:

1. Out of date LICENSE files
2. A bundled source file is not Apache compatible (LwIP; pppoe.c;
   four-clause BSD license)
3. A few security items missing from the Mynewt export list
   (tinycrypt and polarSSL).

Item 1: this is the biggest issue.  There is not much to say here, other
than I somehow completely forgot to take care of this.  All of the new
third-party code was reviewed to ensure it can be included in an Apache
project, and exceptions for these libraries were added to the
.rat-excludes file, but the last critical step was not done.  I want to
apologize to everyone for missing this.  Because of this mistake, we
will need restart the release process, which means a new vote will be
called on the dev list.

Item 2: I wasn't actually aware that the four-clause BSD license is
incompatible with Apache projects.  In the general@ thread, Justin
referred to another thread discussing this particular license:
https://lists.apache.org/thread.html/557a49d678809e2c543ef465dc36b2bd02eb02fda3c484f204468e39@%3Clegal-discuss.apache.org%3E.
The legal stuff is way over my head, so I will take others' word that
this license is not acceptable.  I am not sure what the solution is for
Mynewt, but we may end up just removing this particular file from the
release.

Item 3: Cheking the security export list is missing from our release
process
(https://cwiki.apache.org/confluence/display/MYNEWT/Release+Process).
We'll need to add it.  For this release, I believe Aditi is looking into
adding the necessary items to the export list.

Once again, I am sorry to everyone for not being thorough enough with
this release.  When the next vote is called, it would be appreciated if
you could cast another vote.  The next release candidate will likely be
functionally identical to the first one, with the possible exception of
the removal of the pppoe.c file.  I will include details in the
upcoming vote email.

Finally, please don't hesitate to voice any questions or concerns.

Thanks,
Chris

[CANCEL][VOTE] Release Apache Mynewt 1.0.0-b1-incubating-rc1

[Christopher Collins]

Hello all,

Voting for the release of Apache Mynewt 1.0.0, beta 1, rc1 has been cancelled
due to some out of date LICENSE files.

Sorry for the confusion, and thank you to everyone who voted.  A second
release candidate will be put up for a vote on the dev list shortly.

Thanks,
Chris

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Christopher Collins]

Thanks, Justin.  Somehow I completely forgot to update the LICENSE
files this time around.  I'll cancel the vote.

Chris

On Tue, Nov 29, 2016 at 02:13:02PM +1100, Justin Mclean wrote:
> Hi,
> 
> -1 binding due to LICENSE issues (see below) and cryptography issues 
> (tinycrypt and polarssl) and there’s a license incompatible with Apache 
> license 2.0 in the release. [5] (4 clause BSD)
> 
> It looks like tinycrypt and polarssl has been added  since last release but 
> not listed here(?) [2]
> 
> I checked:
> - artefacts include incubating
> - signatures and hashes good
> - NOTICE is good
> - LICENSE is missing quite a few items (see below)
> - DISCLAIMER exists
> - All source files have headers
> - No unexpected binary files in release
> 
> The LICENSE files for core and newt are identical to last release but several 
> 3rd party items have been added
> 
> For core:
> - BSD licensed  tiny crypt  copyright (c) 2015, Intel Corporation [3]
> - BSD license PPP copyright (c) 1994-2002 Paul Mackerras [4]+
> - BSD license CHAP/MD5 copyright (c) 1994-2002 Paul Mackerras [4]+
> - BSD license CHAP copyright (c) 1995 Eric Rosenquist. [4]
> - PD license EAP for PP  2001 by Sun Microsystems, Inc. [4]
> - BSD license PPP Encryption copyright (c) 2002 Google, Inc.[4]
> - BSD license EUI64 copyright (c) 1999 Tommi Komulainen[4]+
> - BSD license assorted files copyright (c) 1984-2000 Carnegie Mellon 
> University. [4]+
> - MIT licensed PPP copyright (c) 2003 by Marc Boucher and Copyright (c) 1997 
> Global Election Systems Inc. [4]+
> - BSD licensed files copyright 2016 STMicroelectronics [6]
> - BSD licensed code based on XySSL copyright (C) 2006-2008  Christophe Devine 
> [7]
> - BSD licensed polarssl  copyright (C) 2009  Paul Bakker [7]
> - BSD license SNMP copyright (c) 2001, 2002 Leon Woestenberg and copyright 
> (c) 2001, 2002 Axon Digital Design B.V. [8] (and other files)
> - BSD licensed lwIP TCP/IP stack copyright (c) 2001, 2002 Swedish Institute 
> of Computer Science. [9]
> - BSD licensed IGMP copyright (c) 2002 CITEL Technologies Ltd. [10]
> - BSD license AutoIP copyright (c) 2007 Dominik Spies [11]
> - BSD license files copyright (c) 2013 - 2015, Freescale Semiconductor, Inc. 
> [12]
> - BSD licensed coap copyright 2016 Intel Corporation and 2013, Institute for 
> Pervasive Computing, ETH Zurich [13] 
> - and about a dozen others (including ARM and Nordic Semiconductor) as I gave 
> up at this point
> 
> Note the lines marked + have an additional clause (required notice) that 
> effects the NOTICE file (I think).
> 
> For newt:
> - PD licensed code copyright (c) 2012 Miki Tebeka [14]
> - 20 or so MIT(?) licensed files [15] copyright Ugorji Nwoke [15]
> - MIT licensed go coap copyright (c) 2013 Dustin Sallings [16]
> - BSD licensed gatt  copyright (c) 2014 PayPal Inc [17]
> - MIT licensed xpc [18]
> - MIT licensed gioctl copyright (c) 2014 Mark Wolfe [19]
> 
> This file [5] is licensed under a 4 clause BSD license which is not on the 
> list of approved licenses. 
> 
> Also looks like you download page need updating to provide links to download 
> the voted on artefacts for the last release. [1]
> 
> Thanks,
> Justin
> 
> 1. https://mynewt.apache.org/download/
> 2. https://www.apache.org/licenses/exports/
> 3. ./apache-mynewt-core-1.0.0-b1-incubating/crypto/tinycrypt/*
> 4. ./apache-mynewt-core-1.0.0-b1-incubating/net/ip/lwip_base/src/netif/ppp/*
> 5. 
> ./apache-mynewt-core-1.0.0-b1-incubating/net/ip/lwip_base/src/netif/ppp/pppoe.c
> 6. 
> ./apache-mynewt-core-1.0.0-b1-incubating/hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/*
> 7. 
> ./apache-mynewt-core-1.0.0-b1-incubating/net/ip/lwip_base/src/netif/ppp/polarssl/*
> 8. 
> ./apache-mynewt-core-1.0.0-b1-incubating/net/ip/lwip_base/include/lwip/apps/snmp.h
> 9. ./apache-mynewt-core-1.0.0-b1-incubating/net/ip/lwip_base/
> 10. 
> ./apache-mynewt-core-1.0.0-b1-incubating/net/ip/lwip_base/src/core/ipv4/igmp.c
> 11. 
> ./apache-mynewt-core-1.0.0-b1-incubating/net/ip/lwip_base/src/core/ipv4/autoip.c
> 12. 
> ./apache-mynewt-core-1.0.0-b1-incubating/hw/mcu/nxp/src/ext/sdk-2.0-frdm-k64f_b160321/devices/MK64F12/*
> 13. ./apache-mynewt-core-1.0.0-b1-incubating/net/oic/src/messaging/coap/*
> 14. 
> ./apache-mynewt-newt-1.0.0-b1-incubating/newtmgr/vendor/github.com/Sirupsen/logrus/alt_exit.go
> 15  
> ./apache-mynewt-newt-1.0.0-b1-incubating/newtmgr/vendor/github.com/ugorji/go/codec/*.go
> 16 
> ./apache-mynewt-newt-1.0.0-b1-incubating/newtmgr/vendor/github.com/dustin/go-coap/LICENSE
> 17 
> ./apache-mynewt-newt-1.0.0-b1-incubating/newtmgr/vendor/github.com/runtimeinc/gatt/*
> 18 
> ./apache-mynewt-newt-1.0.0-b1-incubating/newtmgr/vendor/github.com/runtimeinc/gatt/xpc/*
> 19. 
> ./apache-mynewt-newt-1.0.0-b1-incubating/newtmgr/vendor/github.com/runtimeinc/gatt/linux/gioctl/*
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: 

Re: BLE Questions

[Christopher Collins]

Argh... I messed up the call to ble_gatts_chr_updated().  I forgot to
pass the characteristic handle to this function.  The corrected code is
below:

/* Update characteristic value. */
gatt_svr_new_alert_val[0] = 10;
gatt_svr_new_alert_val[1] = 20;
gatt_svr_new_alert_val[2] = 30;
gatt_svr_new_alert_val[3] = 40;
gatt_svr_new_alert_val_len = 4

/* Look up characteristic handle. */
uint16_t chr_val_handle;
rc = ble_gatts_find_chr(BLE_UUID16(GATT_SVR_SVC_ALERT_UUID),
BLE_UUID16(GATT_SVR_CHR_NEW_ALERT),
NULL, _val_handle);
assert(rc == 0);


ble_gatts_chr_updated(chr_val_handle);

Sorry about that,
Chris

On Mon, Nov 28, 2016 at 03:01:52PM -0800, Christopher Collins wrote:
> On Mon, Nov 28, 2016 at 04:33:23PM -0500, David G. Simmons wrote:
> > Thanks to both of you for hugely helpful answers! 
> > 
> > Now, the last bit ... 
> > 
> > Where is the value -- or the variable, more accurately -- associated
> > with a characteristic defined? So that I know which one to update. :-) 
> 
> The source of the characteristic data is determined by the GATT callback
> function.  In English, your app defines a variable to hold the
> characteristic value, and the callback retrieves this variable when the
> characteristic is read.  To change the value of the characteristic,
> write to the source variable that the callback reads from.
> 
> Looking at bleprph's alert notification service callback:
> 
> case GATT_SVR_CHR_NEW_ALERT:
> if (ctxt->op == BLE_GATT_ACCESS_OP_WRITE_CHR) {
> rc = gatt_svr_chr_write(ctxt->om, 0,
> sizeof gatt_svr_new_alert_val,
> gatt_svr_new_alert_val,
> _svr_new_alert_val_len);
> return rc;
> } else if (ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR) {
> rc = os_mbuf_append(ctxt->om, _svr_new_alert_val,
> sizeof gatt_svr_new_alert_val);
> return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
> }
> 
> This callback uses the "gatt_svr_new_alert_val" variable to hold the
> "new alert" characteristic value.  So, if you wanted send a notification
> with the four-byte value {10,20,30,40} to to all subscribed peers, you
> might do something like this (not compiled!):
> 
> /* Update characteristic value. */
> gatt_svr_new_alert_val[0] = 10;
> gatt_svr_new_alert_val[1] = 20;
> gatt_svr_new_alert_val[2] = 30;
> gatt_svr_new_alert_val[3] = 40;
> gatt_svr_new_alert_val_len = 4
> 
> /* Look up characteristic handle. */
> uint16_t chr_val_handle;
> rc = ble_gatts_find_chr(BLE_UUID16(GATT_SVR_SVC_ALERT_UUID),
> BLE_UUID16(GATT_SVR_CHR_NEW_ALERT),
> NULL, _val_handle);
> assert(rc == 0);
> 
> 
> ble_gatts_chr_updated();
> 
> I hope that clears things up.  If not, I probably am not explaining it
> well, so please don't hesitate to ask again :).
> 
> There are a few secondary issues this email raises that I should mention
> for completeness:
> 
> 1. Using ble_gatts_find_chr() is not the preferred way to determine a
> characteristic's attribute handle.  Rather, it is better to discover
> this information at registration time via the "val_handle" pointer in
> the characteristic definition.  For an example of how this is done, see
> the New Alert characteristic definition in
> net/nimble/host/services/ans/src/ble_svc_ans.c.
> 
> 2. The above point leads to this one: why does bleprph re-implement the
> Alert Notification Service when there is already an ANS Mynewt package?!
> This is my screw-up; I merged the ANS pull request without removing the
> duplicate implementation from the sample apps.
> 
> Thanks,
> Chris
> 
> > 
> > dg
> > 
> > > On Nov 28, 2016, at 4:30 PM, Christopher Collins <ccoll...@apache.org> 
> > > wrote:
> > > 
> > > As long as you specify one of the BLE_GATT_CHR_F_NOTIFY or
> > > BLE_GATT_CHR_F_INDICATE flags in the characteristic definition, the
> > > characteristic will be subscribable.
> > > 
> > > When a peer subscribes to a characteristic, the stack signals this event
> > > to the application via the GAP event callback associated with the peer.
> > > When a peer unsubscribes, this is signalled via the same mechanism.  For
> > > rationale on why the GAP event callback is used here, see this email:
> > > https://lists.apache.org/thread.html/8706f7914d2b716a02c25bdfc57fe942f7c7fca82446dd3523014d43

Re: BLE Questions

[Christopher Collins]

On Mon, Nov 28, 2016 at 04:33:23PM -0500, David G. Simmons wrote:
> Thanks to both of you for hugely helpful answers! 
> 
> Now, the last bit ... 
> 
> Where is the value -- or the variable, more accurately -- associated
> with a characteristic defined? So that I know which one to update. :-) 

The source of the characteristic data is determined by the GATT callback
function.  In English, your app defines a variable to hold the
characteristic value, and the callback retrieves this variable when the
characteristic is read.  To change the value of the characteristic,
write to the source variable that the callback reads from.

Looking at bleprph's alert notification service callback:

case GATT_SVR_CHR_NEW_ALERT:
if (ctxt->op == BLE_GATT_ACCESS_OP_WRITE_CHR) {
rc = gatt_svr_chr_write(ctxt->om, 0,
sizeof gatt_svr_new_alert_val,
gatt_svr_new_alert_val,
_svr_new_alert_val_len);
return rc;
} else if (ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR) {
rc = os_mbuf_append(ctxt->om, _svr_new_alert_val,
sizeof gatt_svr_new_alert_val);
return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
}

This callback uses the "gatt_svr_new_alert_val" variable to hold the
"new alert" characteristic value.  So, if you wanted send a notification
with the four-byte value {10,20,30,40} to to all subscribed peers, you
might do something like this (not compiled!):

/* Update characteristic value. */
gatt_svr_new_alert_val[0] = 10;
gatt_svr_new_alert_val[1] = 20;
gatt_svr_new_alert_val[2] = 30;
gatt_svr_new_alert_val[3] = 40;
gatt_svr_new_alert_val_len = 4

/* Look up characteristic handle. */
uint16_t chr_val_handle;
rc = ble_gatts_find_chr(BLE_UUID16(GATT_SVR_SVC_ALERT_UUID),
BLE_UUID16(GATT_SVR_CHR_NEW_ALERT),
NULL, _val_handle);
assert(rc == 0);


ble_gatts_chr_updated();

I hope that clears things up.  If not, I probably am not explaining it
well, so please don't hesitate to ask again :).

There are a few secondary issues this email raises that I should mention
for completeness:

1. Using ble_gatts_find_chr() is not the preferred way to determine a
characteristic's attribute handle.  Rather, it is better to discover
this information at registration time via the "val_handle" pointer in
the characteristic definition.  For an example of how this is done, see
the New Alert characteristic definition in
net/nimble/host/services/ans/src/ble_svc_ans.c.

2. The above point leads to this one: why does bleprph re-implement the
Alert Notification Service when there is already an ANS Mynewt package?!
This is my screw-up; I merged the ANS pull request without removing the
duplicate implementation from the sample apps.

Thanks,
Chris

> 
> dg
> 
> > On Nov 28, 2016, at 4:30 PM, Christopher Collins <ccoll...@apache.org> 
> > wrote:
> > 
> > As long as you specify one of the BLE_GATT_CHR_F_NOTIFY or
> > BLE_GATT_CHR_F_INDICATE flags in the characteristic definition, the
> > characteristic will be subscribable.
> > 
> > When a peer subscribes to a characteristic, the stack signals this event
> > to the application via the GAP event callback associated with the peer.
> > When a peer unsubscribes, this is signalled via the same mechanism.  For
> > rationale on why the GAP event callback is used here, see this email:
> > https://lists.apache.org/thread.html/8706f7914d2b716a02c25bdfc57fe942f7c7fca82446dd3523014d43@%3Cdev.mynewt.apache.org%3E
> >  
> > <https://lists.apache.org/thread.html/8706f7914d2b716a02c25bdfc57fe942f7c7fca82446dd3523014d43@%3Cdev.mynewt.apache.org%3E>
> > 
> > As Mike indicated, your application tells the stack that a
> > characteristic's value has changed via the ble_gatts_chr_updated()
> > function.  It is up to the application to actually change the value
> > prior to calling this function.
> > 
> > If you are not sure which handle is associated with a particular
> > characteristic, you can perform a lookup by
> > service-characteristic-UUID-pair using the ble_gatts_find_chr()
> > function.
> 
> --
> David G. Simmons
> (919) 534-5099
> Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog> • 
> Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter 
> <http://twitter.com/TechEvangelist1> • GitHub <http://github.com/davidgs>
> /** Message digitally signed for security and authenticity.  
> * If you cannot read the PGP.sig attachment, please go to 
>  * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!!
>  * Public key available at keyserver.pgp.com <http://keyserver.pgp.com/>
> **/
> ♺ This email uses 100% recycled electrons. Don't blow it by printing!
> 
> There are only 2 hard things in computer science: Cache invalidation, naming 
> things, and off-by-one errors.
> 
> 

Re: BLE Questions

[Christopher Collins]

Hi David,

Mike wrote a good reply, but a few things that were said are based on an
older version of the nimble stack.  Thankfully, some parts have improved
since 0.9.0.  My response is below.

On Mon, Nov 28, 2016 at 03:42:01PM -0500, David G. Simmons wrote:
[...]
> GATT_SVR_CHR_NEW_ALERT is a 'subscribable' UUID, and I would expect that 
> 
> case GATT_SVR_CHR_NEW_ALERT:
> if (ctxt->op == BLE_GATT_ACCESS_OP_WRITE_CHR) {
> rc = gatt_svr_chr_write(ctxt->om, 0,
> sizeof gatt_svr_new_alert_val,
> gatt_svr_new_alert_val,
> _svr_new_alert_val_len);
> return rc;
> } else if (ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR) {
> rc = os_mbuf_append(ctxt->om, _svr_new_alert_val,
> sizeof gatt_svr_new_alert_val);
> return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
> }
> 
> would get called when I subscribe to this characteristic. But it does not. 
> 
> So, if I want to have a subscribable service characteristic, How do I
> implement that, and where does the characteristic value get updated so
> that it is propagated to the connected device (if any)? 

As long as you specify one of the BLE_GATT_CHR_F_NOTIFY or
BLE_GATT_CHR_F_INDICATE flags in the characteristic definition, the
characteristic will be subscribable.

When a peer subscribes to a characteristic, the stack signals this event
to the application via the GAP event callback associated with the peer.
When a peer unsubscribes, this is signalled via the same mechanism.  For
rationale on why the GAP event callback is used here, see this email:
https://lists.apache.org/thread.html/8706f7914d2b716a02c25bdfc57fe942f7c7fca82446dd3523014d43@%3Cdev.mynewt.apache.org%3E

As Mike indicated, your application tells the stack that a
characteristic's value has changed via the ble_gatts_chr_updated()
function.  It is up to the application to actually change the value
prior to calling this function.

If you are not sure which handle is associated with a particular
characteristic, you can perform a lookup by
service-characteristic-UUID-pair using the ble_gatts_find_chr()
function.

Thanks,
Chris

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

[Christopher Collins]

FYI - the general@ vote thread can be found here:
https://lists.apache.org/thread.html/84cc007ab334ab12c2d0b75ea63c840630cee8bbf45c9561479521df@%3Cgeneral.incubator.apache.org%3E

Thanks,
Chris

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

[Christopher Collins]

Hello all,

I am pleased to be calling this vote for the source release of Apache
Mynewt 1.0.0, beta 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.

For full release notes, please visit the Apache Mynewt Wiki:
https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes

[VOTE] thread:
https://lists.apache.org/thread.html/81f0abec5177734af735ad251c0a63a397656032b646f89aa8d8c9d2@%3Cdev.mynewt.apache.org%3E

[RESULT][VOTE] thread:
https://lists.apache.org/thread.html/998ab676cfa8624237e71c38d2e6b53773a180322f25a957ba7a35c2@%3Cdev.mynewt.apache.org%3E

[DISCUSS] thread:
https://lists.apache.org/thread.html/f419185576b86206daf4b7eeb379ec48a294a2722ab7028d408e5584@%3Cdev.mynewt.apache.org%3E

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.0.0-b1+Test+Results

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.10.5
 * Linux 4.4.6 (Gentoo)

The release candidate to be voted on is available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b1-incubating/rc1/

The commits under consideration are as follows:

blinky:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky
commit: b6918edc174b764f1e0b4ef4f4652aca8fedf8dd

core:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core
commit: c6a8f88f6b8dc7c8eee6dc75a34c9b6ea295b05d

newt:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
commit: 59ec3af372952382390cfd988e503d8cf3d5b34b

In addition, the following newt convenience binaries are available:
linux: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b1-incubating/rc1/apache-mynewt-newt-bin-linux-1.0.0-b1-incubating.tgz
osx: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b1-incubating/rc1/apache-mynewt-newt-bin-osx-1.0.0-b1-incubating.tgz

The release candidate is signed with a GPG key available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS

The vote is open for at least 72 hours and passes if a majority of at
least three +1 PPMC 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...

The vote is open for at least 72 hours and passes if a majority of at
least three +1 PPMC votes are cast.

Thanks,
Chris

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Christopher Collins]

Hello all,

Voting for Apache Mynewt 1.0.0-b1-incubating-rc1 is now closed.  The
release has passed this step of the process.  The vote breakdown is as
follows:

+1 Aditi Hilbert(binding)
+1 Christopher Collins  (binding)
+1 David G. Simmons
+1 Jim Jagielski(binding)
+1 Kevin Townsend
+1 Vipul Rahane (binding)
+1 Will Sanfilippo  (binding)

Total: +5 binding, +2 non-binding

We can now call a vote on the general@incubator list.

Thank you to all who voted.

Chris

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

[Christopher Collins]

+1 (binding).

Chris

On Tue, Nov 22, 2016 at 05:58:37PM -0800, Christopher Collins wrote:
> Hello all,
> 
> I am pleased to be calling this vote for the source release of Apache
> Mynewt 1.0.0, beta 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.
> 
> 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.0.0-b1+Test+Results
> 
> 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.10.5
>  * Linux 4.4.6 (Gentoo)
> 
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b1-incubating/rc1/
> 
> The commits under consideration are as follows:
> 
> blinky:
> repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky
> commit: b6918edc174b764f1e0b4ef4f4652aca8fedf8dd
> 
> core:
> repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core
> commit: c6a8f88f6b8dc7c8eee6dc75a34c9b6ea295b05d
> 
> newt:
> repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
> commit: 59ec3af372952382390cfd988e503d8cf3d5b34b
> 
> In addition, the following newt convenience binaries are available:
> linux: 
> https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b1-incubating/rc1/apache-mynewt-newt-bin-linux-1.0.0-b1-incubating.tgz
> osx: 
> https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b1-incubating/rc1/apache-mynewt-newt-bin-osx-1.0.0-b1-incubating.tgz
> 
> 
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS
> 
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PPMC 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.
> 
> Thanks,
> Chris

Re: HW configuration of Nimble (HCI)

[Christopher Collins]

Hi Oleg,

On Wed, Nov 23, 2016 at 03:07:11PM +0300, Oleg Persidskiy wrote:
> good time dear Engineers!
> 
> Have a question about your newt Nimble (HCI) subproject.
> (sorry I'm a newbie with newt ~ 1 day)

Great!

> During the test (I use nRF52 own board) faced with a problem , where I can
> reconfigure
> PORT IO pins, SPEED & etc. parameters ?
> 
> nRF5x SoC has very flexible PIO configuration ability but I cannot set my
> board paratemetrs to Nimble HCI driver (it default uses nRF52DK based board
> configuration).
> 
> Summary I need to
> 1. decrease the HCI_UART speed to 19200 (long line capacity issue)
> 2. remap IO pins Numbers: RX/TX/CTS/RTS according to my board.
> 3. change Protocol 8 bit to 9 bit (w parity)

This is one area of Mynewt that could definitely use some better
documentation.  To adjust these settings, you need to use the syscfg
mechanism.  In short, each package defines system-wide settings via
something called syscfg.  Your project can then override the default
values of these settings in various packages, usually the app or target.
For simplicity, I would recommend overriding these settings at the
target level for now.

Here is how you would override these settings.  Note: For the following,
I am assuming you are using the nRF52dk BSP.  If you are not, the
following will still probably work, but you may want to adjust the
comments accordingly.

* Create a file called "syscfg.yml" in your target directory
  (targets//syscfg.yml)

* Add the following contents to this file:

syscfg.vals:
# @apache-mynewt-core/hw/bsp/nrf52dk
UART_0_PIN_TX:  
UART_0_PIN_RX:  
UART_0_PIN_RTS: 
UART_0_PIN_CTS: 

# @apache-mynewt-core/net/nimble/transport/uart
BLE_HCI_UART_BAUD:  19200
BLE_HCI_UART_DATA_BITS: 9
BLE_HCI_UART_STOP_BITS: (*)
BLE_HCI_UART_PARITY:(**)

Replace pin-num values as appropriate.

I wasn't sure which values are appropriate for stop bits or parity.
Valid parity values are:
HAL_UART_PARITY_NONE,
HAL_UART_PARITY_ODD,
HAL_UART_PARITY_EVEN,

This file will reconfigure your project as specified.  You can see a
list of all the settings in your project with the "newt target config
" command.  The settings are organized by their defining
package.  As indicated by the comments above, the settings in this case
come from the nrf52dk BSP package and the nimble UART transport package.

> 
> 
> Thanks you a lot!
> 
> Oleg.

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

[Christopher Collins]

Hello all,

This thread is for any and all discussion regarding the release of
apache-mynewt-1.0.0-b1-incubating-rc1.  All feedback is welcome.

Thanks,
Chris

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

[Christopher Collins]

Hello all,

I am pleased to be calling this vote for the source release of Apache
Mynewt 1.0.0, beta 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.

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.0.0-b1+Test+Results

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.10.5
 * Linux 4.4.6 (Gentoo)

The release candidate to be voted on is available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b1-incubating/rc1/

The commits under consideration are as follows:

blinky:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky
commit: b6918edc174b764f1e0b4ef4f4652aca8fedf8dd

core:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core
commit: c6a8f88f6b8dc7c8eee6dc75a34c9b6ea295b05d

newt:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
commit: 59ec3af372952382390cfd988e503d8cf3d5b34b

In addition, the following newt convenience binaries are available:
linux: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b1-incubating/rc1/apache-mynewt-newt-bin-linux-1.0.0-b1-incubating.tgz
osx: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b1-incubating/rc1/apache-mynewt-newt-bin-osx-1.0.0-b1-incubating.tgz


The release candidate is signed with a GPG key available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS

The vote is open for at least 72 hours and passes if a majority of at
least three +1 PPMC 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.

Thanks,
Chris

[jira] [Resolved] (MYNEWT-339) BLE host - Retry when an ATT send fails due to mbuf shortage

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-339.

Resolution: Fixed

> BLE host - Retry when an ATT send fails due to mbuf shortage
> 
>
> Key: MYNEWT-339
> URL: https://issues.apache.org/jira/browse/MYNEWT-339
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The GATT layer should not give up so easily when the layer below it
> (ATT) fails due to memory exhaustion - it should just try again a bit
> later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Shell Tutorial

[Christopher Collins]

Hi David,

On Thu, Nov 17, 2016 at 01:32:17PM -0500, David G. Simmons wrote:
> 
> I'm thinking of writing up a Tutorial on how to enable the Console and Shell 
> in a Mynewt app -- especially since things have changed a bit with the Event 
> Queue and task management.
> 
> If I am understanding things correctly (and there's no guarantee that I am) 
> here's what needs to happen:
> 
> 1) App needs to have an event Queue if it doesn't already
> 2) pkg.yml file needs to include
> - sys/console/full
> - sys/shell
> 3) syscfg.yml needs to set SHELL_TASK: 1
> 
> What else? 

That looks correct to me.  The only other step that might be missing is:
enable specific shell commands with the appropriate syscfg settings
(e.g., OS_CLI, STATS_CLI).

Chris

[jira] [Resolved] (MYNEWT-344) BLE Host - Don't wake up every second

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-344.

Resolution: Fixed

> BLE Host - Don't wake up every second
> -
>
> Key: MYNEWT-344
> URL: https://issues.apache.org/jira/browse/MYNEWT-344
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The host currently wakes up once a second to see if there is any work to do.  
> This is both stupid and wasteful in terms of power.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-487) BLE Host - Execute GATT procedure callback on timeout

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-487:
--

 Summary: BLE Host - Execute GATT procedure callback on timeout
 Key: MYNEWT-487
 URL: https://issues.apache.org/jira/browse/MYNEWT-487
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_0_0_rel


When a GATT procedure times out, the callback does not get executed.  The 
rationale was probably that the app doesn't need to know about that since it 
has gotten notified about the terminated connection instead.  However, for 
logging and reporting reasons, every GATT procedure should be paired with a 
callback invocation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Smoke testing latest release

[Christopher Collins]

FYI- I have added a 1.0.0-b1 test results page to the wiki:
https://cwiki.apache.org/confluence/display/MYNEWT/1.0.0-b1+Test+Results

Hopefully this will make it easier to coordinate testing efforts.

Thanks,
Chris

On Fri, Nov 11, 2016 at 08:55:40AM -0800, will sanfilippo wrote:
> Hello David:
> 
> As I said in my email, the smoke test consists of erasing the flash, loading 
> the bootloader then loading the image. The steps are (using my target names):
> 
> # Clean and buiild all the images.
> 
> newt clean arduino_zero_boot
> newt clean arduino_zero_blinky
> newt build arduino_zero_boot
> newt build arduino_zero_blinky
> newt create-image arduino_zero_blinky 0.0.0
> 
> # Erase the flash
> newt debug arduino_zero_blinky
> 
> (gdb) mon at91samd chip-erase
> chip erased
> chip erased
> (gdb) x/32wx 0
> 0x0:  0x  0x  0x  0x
> 0x10: 0x  0x  0x  0x
> 0x20: 0x  0x  0x  0x
> 0x30: 0x  0x  0x  0x
> 0x40: 0x  0x  0x  0x
> 0x50: 0x  0x  0x  0x
> 0x60: 0x  0x  0x  0x
> 0x70: 0x  0x  0x  0x
> (gdb) q
> 
> # Load bootloader
> newt load arduino_zero_boot
> 
> # Load image
> newt load arduino_zero_blinky
> 
> Now it blinky.
> 
> My targets:
> wes@~/dev/wes$ newt target show arduino_zero_boot
> targets/arduino_zero_boot
> app=@apache-mynewt-core/apps/boot
> bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
> build_profile=optimized
> syscfg=BSP_ARDUINO_ZERO=1
> wes@~/dev/wes$ newt target show arduino_zero_blinky
> targets/arduino_zero_blinky
> app=apps/blinky
> bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
> build_profile=optimized
> syscfg=BSP_ARDUINO_ZERO=1
> 
> > On Nov 11, 2016, at 8:38 AM, David G. Simmons  wrote:
> > 
> > 
> > How did you smoke test these?
> > 
> > I am trying to do the same this morning, and have run into problems. 
> > 
> > 
> > DSimmons-Pro:arduino_zero dsimmons$ newt load arduino_boot -v
> > Loading bootloader
> > Load command: BOOT_LOADER="1" FEATURES="BASELIBC_PRESENT BOOT_LOADER 
> > BSP_ARDUINO_ZERO_PRO CLOCK_FREQ FLASH_MAP_MAX_AREAS MSYS_1_BLOCK_COUNT 
> > MSYS_1_BLOCK_SIZE OS_CPUTIME_FREQ SANITY_INTERVAL SPI_0_TYPE SPI_1_TYPE 
> > TIMER_0 UART_0 WATCHDOG_INTERVAL" FLASH_OFFSET="0x0" IMAGE_SLOT="0" 
> > CORE_PATH="/Users/dsimmons/dev/arduino_zero/repos/apache-mynewt-core" 
> > BSP_PATH="/Users/dsimmons/dev/arduino_zero/repos/mynewt_arduino_zero/hw/bsp/arduino_zero"
> >  
> > BIN_BASENAME="/Users/dsimmons/dev/arduino_zero/bin/targets/arduino_boot/app/apps/boot/boot"
> >   
> > /Users/dsimmons/dev/arduino_zero/repos/mynewt_arduino_zero/hw/bsp/arduino_zero/arduino_zero_download.sh
> >  
> > /Users/dsimmons/dev/arduino_zero/repos/mynewt_arduino_zero/hw/bsp/arduino_zero
> >  
> > /Users/dsimmons/dev/arduino_zero/bin/targets/arduino_boot/app/apps/boot/boot
> > Error: Downloading 
> > /Users/dsimmons/dev/arduino_zero/bin/targets/arduino_boot/app/apps/boot/boot.elf.bin
> >  to 0x0
> > Open On-Chip Debugger 0.9.0 (2015-11-15-05:39)
> > Licensed under GNU GPL v2
> > For bug reports, read
> > http://openocd.org/doc/doxygen/bugs.html
> > Info : only one transport option; autoselect 'swd'
> > adapter speed: 500 kHz
> > adapter_nsrst_delay: 100
> > cortex_m reset_config sysresetreq
> > Info : CMSIS-DAP: SWD  Supported
> > Info : CMSIS-DAP: JTAG Supported
> > Info : CMSIS-DAP: Interface Initialised (SWD)
> > Info : CMSIS-DAP: FW Version = 01.1F.0118
> > Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
> > Info : CMSIS-DAP: Interface ready
> > Info : clock speed 500 kHz
> > Info : SWD IDCODE 0x0bc11477
> > Info : at91samd21g18.cpu: hardware has 4 breakpoints, 2 watchpoints
> > Error: Target not halted
> > 
> > 
> > 
> > load - Load app image to target for .
> > 
> > Usage:
> >  newt load  [flags]
> > 
> > Flags:
> >  -j, --extrajtagcmd string   extra commands to send to JTAG software
> > 
> > Global Flags:
> >  -l, --loglevel string   Log level (default "WARN")
> >  -o, --outfile stringFilename to tee output to
> >  -q, --quiet Be quiet; only display error output
> >  -s, --silentBe silent; don't output anything
> >  -v, --verbose   Enable verbose output when executing commands
> > DSimmons-Pro:arduino_zero dsimmons$
> > 
> > Just to make sure, I checked all my repository sources, and newt is up to 
> > date:
> > 
> > DSimmons-Pro:newt dsimmons$ newt version
> > Apache Newt (incubating) version: 1.0.0-develop
> > DSimmons-Pro:newt dsimmons$ pwd
> > /Users/dsimmons/dev/go/src/mynewt.apache.org/newt
> > DSimmons-Pro:newt dsimmons$ git status -v
> > On branch 1_0_0_b1_dev
> > nothing to commit, working tree clean
> > 
> > And the repos in the project are 

Re: OS event queue changes

[Christopher Collins]

Hi David,

On Mon, Nov 14, 2016 at 01:06:14PM -0500, David G. Simmons wrote:
> Hi Chris,
> 
> Thanks for this detailed write-up on the new os_event and event queue
> handling. 
> 
> I'm working on adding it all to the existing tutorial on creating and
> managing tasks. 
> 
> I'm working on folding this all together with modifying the blinky app
> to use the new event_q and add a shell task to blinky which will, I
> hope, solve the problem of making Blinky a 'playground' again while
> also providing the new event queue model in a tutorial. 
> 
> My main question is if any of the other demo applications have been
> updated to use the new model outlined here or if I'll need to go
> through them all and update them as well. 

The other sample apps have been updated to use the new eventq API.  For
apps which already created their own event queues, the only required
change was to designate the default event queue via a call to
os_eventq_dflt_set().

For apps which did not create an event queue (e.g., slinky, ocf_sample),
an event queue and an additional task were added.  The new task just
calls os_eventq_run() in a loop.

Thanks,
Chris

1.0.0-b1 BLE testing

[Christopher Collins]

Hello all,

I did some BLE testing for the upcoming release (test plan is here:
https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan).
Everything seems to be good.  There were a few issues that were
identified and fixed during testing; the below results correspond to
what is currently in the release branch (1_0_0_b1_dev).

In the below listings, the units under test and peer devices are
indicated on the far left of each result line.

Thanks,
Chris

---

bleprph
* Units under test:
  nRF51dk   1
  nRF52dk   2

* Peer devices:
  iphonei
  osx   o
  galaxyg

Steps:
[Peer devices: iPhone/LightBlue, OSX/LightBlue, Galaxy/BleDebugger]
* Central connects and disconnects several times; ensure:
1 og|2iog   bleprph does not crash 
1 og|2iog   bleprph immediately resumes advertising after disconnect
|2n Central initiates secure-connections just-works pairing

1 og|2iog Central initiates legacy just-works pairing
1 og|2iog Central restores encrypted connection via bonding

---

bletiny
* Units under test:
nRF51dk 1
nRF52dk 2

* Peer devices:
iphone  i
osx o
galaxy  g
mynewt  m

Steps
bletiny as peripheral
1   |2  Peripheral performs undirected advertising
1   |2iog   Central pairs with peripheral
1   |2iog   Central restores encrypted connection via bonding
1iog|2iog   Central reads characteristic
1iog|2iog   Central writes characteristic
1iog|2iog   Central enables indications
1iog|2iog   Peripheral sends indication when characteristic changes
1iog|2iog   Two centrals connect to peripheral

bletiny as central
1im |2imGeneral connection establishment procedure
1im |2imService discovery
1   |2imCentral pairs with peripheral
1   |2imCentral restores encrypted connection via bonding
1im |2imCentral reads characteristic
1im |2imCentral writes characteristic
1im |2imCentral enables indications
1im |2imCentral connects to two peripheral

---

blehci
* Units under test
nRF51dk 1
nRF52dk 2

* Peer devices:
BlueZ-Linux b

Steps
1b  |2b Connect to a third-party device (either master or slave).
1b  |2b Send some data (e.g., service discovery).
1b  |2b Ensure connection stays up.

Re: OS Event Queue errors in blinky

[Christopher Collins]

Hi David,

That is an interesting find.  The problem is that blinky does not set a
default eventq for taskless packages to use.  If a package requires an
event queue, and none has been designated, it triggers a crash with a
failed assert.

Blinky in its original state doesn't crash because it doesn't use any
packages that require an event queue.  Blinky doesn't actually create an
event queue at all; its task handler is just a simple blink-and-sleep
loop.

I am a bit conflicted about what to do here.  On one hand, blinky is the
"hello world" of Mynewt, so it is good to keep it as simple as possible.
Adding event queue processing to its task handler, or an additional
task, would be at odds with this goal.  On the other hand, blinky is
also meant to be a playground or sandbox for new users, it should be
easy to add new packages.

Since we are hoping to release soon, I'm inclined to say let's keep
blinky how it is for now.  We can figure out the right solution for the
next release.  I'm certainly open to hearing opposing viewpoints,
though.

Thanks,
Chris

On Fri, Nov 11, 2016 at 01:18:07PM -0500, David G. Simmons wrote:
> I've gotten the blinky app up on the Arduino Zero Pro, and just for fun, I 
> enabled the Console and shell, hooked it up to my FT232H and got ...
> 
> 200976:Assert ; failed in os_eventq.c:314
> 200976:Unhandled interrupt (2), exception sp 0x20007f48
> 200976: r0:0x  r1:0x  r2:0x8000  r3:0xe000ed00
> 200976: r4:0x  r5:0x013a  r6:0x00016200  r7:0x0003
> 200976: r8:0x000927c0  r9:0xca61 r10:0xbffd8dd3 r11:0xd6beeff1
> 200976:r12:0xf7fe  lr:0xd1bd  pc:0xd1ca psr:0x811b
> 200976:ICSR:0x0440f002
> 
> Now, the blinky app is still running just fine, but from os_eventq.c, line 
> 314:
> 
> if (*evq == NULL) {
> eventq_dflt = os_eventq_dflt_get();
> if (eventq_dflt != NULL) {
> os_eventq_designate(evq, eventq_dflt, start_ev);
> }
> 
> /* The system is misconfigured if there is still no parent eventq.  
> The
>  * application should have explicitly specified a parent queue for 
> each
>  * package, or indicated a default.
>  */
> assert(*evq != NULL);
> 
> --
> David G. Simmons
> (919) 534-5099
> Web  • Blog  • 
> Linkedin  • Twitter 
>  • GitHub 
> /** Message digitally signed for security and authenticity.  
> * If you cannot read the PGP.sig attachment, please go to 
>  * http://www.gnupg.com/  Secure your email!!!
>  * Public key available at keyserver.pgp.com 
> **/
> ♺ This email uses 100% recycled electrons. Don't blow it by printing!
> 
> There are only 2 hard things in computer science: Cache invalidation, naming 
> things, and off-by-one errors.
> 
> 

dev

[Christopher Collins]

Hello all,

I wanted to send a quick note about the planned 1.0.0 beta 1 release.
The pre-release branch has the following name:

1_0_0_b1_dev

This branch has been created in the following repos:

incubator-mynewt-blinky
incubator-mynewt-core
incubator-mynewt-newt
mynewt_arduino_zero

If for some crazy reason you would like to do some testing of the
upcoming release, you should do your testing against this branch.

Last minute bug and license fixes will go into this branch.  Other
development work will go into the develop branch only.

All questions and comments are welcome.

Thanks,
Chris

Re: [HEADS UP] MERGE INTO MASTER! (was: Re: 1_0_0_b1_dev branches)

[Christopher Collins]

On Thu, Nov 10, 2016 at 08:04:45PM +, Sterling Hughes wrote:
> just making sure people see this :)

This is the final heads up :).  I'll be merging develop into master
shortly.

For those who are interested in using the latest code, there is one
major change you should know about prior to pulling:

Backwards-compatiblity-breaking changes have been made to the boot
loader.  Consequently, before using the latest, you will need to
completely erase the boot and images slots in your devices' flash and
upload a new boot loader.  The latest code may appear to work with an
old boot loader, but you will eventually run into issues if you perform
image management (image list, upload, etc.).  The least painful way
forward is to just erase your flash entirely, replace the boot loader,
and forget about it.  Sorry about this this one; hopefully it is the
last time!

A more comprehensive list of changes will go out soon, but I thought
this one deserved special mention.

Thanks,
Chris

Re: 1_0_0_b1_dev branches

[Christopher Collins]

FYI - I will be merging the develop branch into master later today.  If
you are using the master branch, and you are not prepared to switch over
to the latest, then be careful with git pulls and newt syncs!

Thanks,
Chris

On Thu, Nov 10, 2016 at 08:30:28AM -0800, Christopher Collins wrote:
> (changing subject to prevent mail from being categorized as a commit)
> 
> On Thu, Nov 10, 2016 at 01:23:36PM +0100, Sterling Hughes wrote:
> > Is the idea to merge these from develop or master?
> > 
> > I think we should probably merge develop->master now, prior to branching 
> > anything.  We should only be branching releases off of master (which 
> > I’m assuming is the intention.)
> 
> Oops - I forgot about master when I created these branches.  I don't
> think it makes much of a difference in practice which branch the dev
> branches come from, but I agree that using master feels more correct.
> It is probably best to delete these branches and recreate them after
> merging develop to master.  If there are no objections, I will do this
> in the next few hours.
> 
> Thanks,
> Chris

1_0_0_b1_dev branches

[Christopher Collins]

(changing subject to prevent mail from being categorized as a commit)

On Thu, Nov 10, 2016 at 01:23:36PM +0100, Sterling Hughes wrote:
> Is the idea to merge these from develop or master?
> 
> I think we should probably merge develop->master now, prior to branching 
> anything.  We should only be branching releases off of master (which 
> I’m assuming is the intention.)

Oops - I forgot about master when I created these branches.  I don't
think it makes much of a difference in practice which branch the dev
branches come from, but I agree that using master feels more correct.
It is probably best to delete these branches and recreate them after
merging develop to master.  If there are no objections, I will do this
in the next few hours.

Thanks,
Chris

Re: Nordic SDK license not Apache-compatible?

[Christopher Collins]

Hi Justin,

On Thu, Nov 10, 2016 at 08:33:54AM +1100, Justin Mclean wrote:
> Hi,
> 
> > The first clause, Grant of License, seems to be problematic:
> 
> Look like it "non-sub licensable” may be an issue? And "solely in
> connection with a Nordic Integrated Circuit” reads like a field of use
> restriction to me [1]
> 
> Section 4 of the license re distribution may also be a concern.

That was indeed my fear.  Thanks for calling attention to section 4 as
well.

> Their modified BSD license also may be an issue as it also looks to
> includes a field of use restriction.

You are right - I hadn't noticed that.  However, the fourth clause
is missing in the actual commits that were made to address this ticket
(https://github.com/ARMmbed/ble-nrf51822/commit/6d1bf116e156b870099694f0ce27076c236c4f44).
  Maybe there was some additional communication between the mbed team and 
Nordic that let to the actual changes.

> I assume this is optional in that not everyone would need to use it?

Yes, these files are optional in the sense that Mynewt can still be
used without them.  However, someone wishing to use Mynewt with a Nordic
MCU will probably won't get very far without them.

> 1. https://www.apache.org/legal/resolved#category-x

Thanks, Chris

Nordic SDK license not Apache-compatible?

[Christopher Collins]

Hello all,

I was checking some of the licenses in Mynewt, and I came across a
potential licensing issue.  The Nordic SDK v11 appears to use a license
that is too restrictive for an Apache project:


http://developer.nordicsemi.com/nRF5_SDK/nRF5_SDK_v11.x.x/doc/11.0.0/license.txt

The first clause, Grant of License, seems to be problematic:

1.  Grant of License 
Subject to the terms in this Agreement Nordic grants Licensee a
limited, non-exclusive, non-transferable, non-sub licensable,
revocable license ("License"): (a) to use the SDK as a development
platform solely in connection with a Nordic Integrated Circuit ("nRF
IC"), (b) to modify any source code contained in the SDK solely as
necessary to implement products developed by Licensee that
incorporate an nRF IC ("Licensee Product"), and (c) to distribute
the SDK solely as implemented in Licensee Product.  Licensee shall
not use the SDK for any purpose other than specifically authorized
herein.

I see that ARM got permission to replace this license with a BSD license
in some of the SDK files
(https://github.com/ARMmbed/ble-nrf51822/issues/1).  Unfortunately, they
don't use all the files we need, so we can't just replace our version
with the one from the mbed repo.

Does anyone happen to have any magic solution to this problem?  Maybe
Nordic has indicated somewhere that these files are meant to be
BSD-licensed?

Thanks,
Chris

OS event queue changes

[Christopher Collins]

Hello all,

Recently a pretty big change was made to Mynewt's event queue model.
The Mynewt documentation gives a good overview of how event queues used
to work
(http://mynewt.apache.org/develop/os/core_os/event_queue/event_queue/).

Here is the old os_event struct:

struct os_event {
uint8_t ev_queued;
uint8_t ev_type;
void *ev_arg;
STAILQ_ENTRY(os_event) ev_next;
};

Here is the new one:

typedef void os_event_fn(struct os_event *ev);

struct os_event {
uint8_t ev_queued;
os_event_fn *ev_cb;
void *ev_arg;
STAILQ_ENTRY(os_event) ev_next;
};

The difference: the ev_type field was replaced with a callback function
pointer.  A task handler using the old event queue code would dispatch
events based on the event's type.  For example, here is the relevant
part of the old newtmgr task handler:

while (1) {
ev = os_eventq_get(_nmgr_evq);
switch (ev->ev_type) {
case OS_EVENT_T_MQUEUE_DATA:
nt = (struct nmgr_transport *) ev->ev_arg;
nmgr_process(nt);
break;
case OS_EVENT_T_TIMER:
ocf = (struct os_callout_func *)ev;
ocf->cf_func(CF_ARG(ocf));
break;
}
}

Now that the ev_type field has been replaced with a callback function
pointer, the dispatch logic is moved out of the task handler and gets
built into each event.  A task handler now just pulls an event off its
queue and blindly calls its callback function.  A helper function was
added to do just this: os_eventq_run().  As an example, the task handler
for the bleprph application is below:

static void
bleprph_task_handler(void *unused)
{
while (1) {
os_eventq_run(_evq);
}
}

The callback associated with an event is specified when the event gets
initialized.  For example, here are some statically-initialized events
in the nimble host:

static void ble_hs_event_tx_notify(struct os_event *ev);
static void ble_hs_event_reset(struct os_event *ev);

/** OS event - triggers tx of pending notifications and indications. */
static struct os_event ble_hs_ev_tx_notifications = {
.ev_cb = ble_hs_event_tx_notify,
};

/** OS event - triggers a full reset. */
static struct os_event ble_hs_ev_reset = {
.ev_cb = ble_hs_event_reset,
};

As indicated, the callback function receives a single parameter: a
pointer to the event being processed.  If the event is allocated
dynamically, the callback function probably frees the event.

The above text summarizes what was changed.  Now I want to explain the
rationale.  This change was motivated by a desire to reduce the required
number of tasks in a Mynewt application.  Each extraneous task strains a
device's RAM because it requires the allocation of a dedicated stack.
An application was forced to use a lot of tasks because library packages
would create their own task at initialization time.  For example, nearly
all of the sample apps use the shell and newtmgr packages, both of which
used a dedicated task.

Most of the packages that create a dedicated task don't actually need
one.  These packages don't have any real-time timing requirements, and
therefore no need to preempt the system.  The only reason these packages
were creating a task was to simplify their design and API.  If these
packages could just "piggyback" on some application task, they could
still benefit from a task-oriented design without the cost of a
dedicated task.  However, there is a problem with this idea.  If the
dedicated tasks are eliminated and the work is moved into an application
task, how does the application task know what to do with events meant
for a library?  Even if the application developer is willing to add all
the necessary cases to the task's event dispatch switch, the event types
are ambiguous, since the per-user event type number space is assumed to
be unique for each task.

The solution to this problem is to replace the event type with a
callback function pointer.  Now, the task handler doesn't have to know
whether it just dequeued a shell event or a newtmgr event, it just calls
the associated function.

Packages with timing requirements should still create a dedicated task.
For example, the nimble controller is not affected by this change.
Packages without timing requirements should not create a task.  Instead,
they should initialize their required events at init-time, and provide a
function which allows the application to designate the event queue to be
used.  For example, the nimble host exposes the following function:

void ble_hs_evq_set(struct os_eventq *evq);

It is a bit of a burden to require the application to set each package's
event queue.  To mitigate this burden, the following function has been
added to the OS:

void os_eventq_dflt_set(struct os_eventq *evq);

This function designates a default event queue.  If a 

[jira] [Created] (MYNEWT-478) Dependency failures when repo's local name differs from remote name

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-478:
--

 Summary: Dependency failures when repo's local name differs from 
remote name
 Key: MYNEWT-478
 URL: https://issues.apache.org/jira/browse/MYNEWT-478
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins


The user's project.yml file designates a local name for each remote repo.  The 
local name is what newt uses to identify a repo.  For example, given the 
following project.yml file:

{noformat}
project.name: "my_project"

project.repositories:
- gaga

repository.gaga:
type: github
vers: 0-latest
user: apache
repo: incubator-mynewt-core
{noformat}

, the "newt install" command will create a directory called "repos/gaga".  This 
is a problem, because packages in other repos don't refer to this repo as 
"@gaga", the refer to it as "@apache-mynewt-core".

Suggested fix: remove the concept of local repo names.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Angled-brackets vs. quotes in #include directives

[Christopher Collins]

On Mon, Nov 07, 2016 at 09:45:48AM -0800, marko kiiskila wrote:
> > On Nov 7, 2016, at 8:43 AM, Christopher Collins <ccoll...@apache.org> wrote:
> > Is there a particular reason that you would prefer this?  By my reading
> > of the standard, using angled-brackets for this purpose contradicts
> > their specified purpose, at least in spirit.
> 
> Familiarity of practice, I guess.
> 
> http://lxr.free-electrons.com/source/kernel/sched/core.c 
> <http://lxr.free-electrons.com/source/kernel/sched/core.c>
> https://www.freebsd.org/cgi/man.cgi?query=style=9 
> <https://www.freebsd.org/cgi/man.cgi?query=style=9>
> 
> However, I’m not too tied to this, if you have a very strong preference.

I don't think the Linux or FreeBSD kernels are a good example of
portable code!  Honestly, I don't think there is any practical benefit
in doing it my way.  My only interest in this issue is that I wince
whenever I see user headers being included with angle-brackets.  If
there is any practical reason to do something different, then we should
do it - that's why I asked if there was a particular reason for the
preference.

I think someone will update the coding standards file with some rule,
and everyone will be happy :).

Chris

Re: Angled-brackets vs. quotes in #include directives

[Christopher Collins]

On Mon, Nov 07, 2016 at 08:08:14AM -0800, marko kiiskila wrote:
> Good idea to write this down.
> 
> I’d also like to include header files from other packages to be in the
> group included with angle brackets.
> Then “header.h” means local and  is for non-local.

Is there a particular reason that you would prefer this?  By my reading
of the standard, using angled-brackets for this purpose contradicts
their specified purpose, at least in spirit.

This is from n1570 (free draft of the 2011 standard, available at
http://www.iso-9899.info/n1570.html):

(6.10.2)
 2   A preprocessing directive of the form
# include  new-line
 searches a sequence of implementation-defined places for a header
 identified uniquely by the specified sequence between the < and >
 delimiters, and causes the replacement of that directive by the
 entire contents of the header. How the places are specified or the
 header identified is implementation-defined.

 3   A preprocessing directive of the form
# include "q-char-sequence" new-line
 causes the replacement of that directive by the entire contents of
 the source file identified by the specified sequence between the "
 delimiters. The named source file is searched for in an
 implementation-defined manner. If this search is not supported, or
 if the search fails, the directive is reprocessed as if it read
# include  new-line
 with the identical contained sequence (including > characters, if
 any) from the original directive.

The relevant difference among these paragraphs is "header" vs. "source
file."  When you use angle-brackets, the compiler includes
implementation-specific source.  This is usually a plain C file, but it
could also be some sort of precompiled header or dynamically generated
magic.  With double quotes, a file always gets included.  Since we don't
control the implementation (and in fact expect Mynewt to build with
several different implementations), it would seem that we should only
use angled-brackets for implementation-supplied files.

Chris

Re: Connect timeout not always accurate

[Christopher Collins]

Hello all,

Will found a bug in the host, which is probably (hopefully!) the only
bug here.  I plan on testing and committing a fix for this bug later
today.  In the meantime, here is the bug:

/*  (ble_hs_heartbeat_sched(), ble_hs.c) */

/* Reset heartbeat timer if it is not currently scheduled or if the
 * specified time is sooner than the current expiration time.
 */
if (!os_callout_queued(_hs_heartbeat_timer.cf_c) ||
OS_TIME_TICK_LT(ticks_from_now, ble_hs_heartbeat_timer.cf_c.c_ticks)) {
//  

ble_hs_heartbeat_timer_reset(ticks_from_now);
}

The mistake is marked with a // comment above.  A relative time
(ticks_from_now) is being compared to an absolute time (cf_c.c_ticks),
which of course yields nonsense.  I will need to double-check, but I
think this issue is not caught by the any unit tests because each test
starts at time 0, eliminating the distinction between absolute and
relative time.  It would be good to advance the OS time by some amount
prior to running timer-dependent tests.  I will make sure I can get the
appropriate tests to fail before I fix the bug.

Thanks Will and Simon!

Chris

On Sun, Nov 06, 2016 at 08:44:40PM -0800, Christopher Collins wrote:
> Hi Simon,


> 
> On Sun, Nov 06, 2016 at 01:50:42PM -0800, Simon Ratner wrote:
> > Hi devs,
> > 
> > I am seeing some variance in the handling of `duration_ms` param to
> > `ble_gap_connect` (on develop). Below are two log traces that demonstrate
> > it. In both cases, duration_ms=1280; the first shows the timeout event
> > (status=13) after 535 ticks (4280 ms), while the second timeout is at a
> > much more respectable 169 ticks (1352 ms).
> > 
> > ```
> > 23352163:[ts=2050146956ssb, mod=4 level=1] GAP procedure initiated:
> > connect; peer_addr_type=1 peer_addr=46:e9:00:75:ce:af scan_itvl=16
> > scan_window=16 itvl_min=16 itvl_max=32 latency=0 supervision_timeout=256
> > min_ce_len=16 max_ce_len=768
> > 23352693:[ts=2054287572ssb, mod=4 level=1] GAP procedure initiated:
> > advertise; disc_mode=2 peer_addr_type=0 peer_addr=none adv_channel_map=0
> > own_addr_type=0 adv_filter_policy=0 adv_itvl_min=338 adv_itvl_max=338
> > adv_data_len=28
> > 23352698:[ts=2054326632ssb, mod=64 level=2] gatt_cli: connection failed;
> > status=13
> > ```
> > 
> > ```
> > 23355205:[ts=2073912596ssb, mod=4 level=1] GAP procedure initiated:
> > connect; peer_addr_type=1 peer_addr=46:e9:00:75:ce:af scan_itvl=16
> > scan_window=16 itvl_min=16 itvl_max=32 latency=0 supervision_timeout=256
> > min_ce_len=16 max_ce_len=768
> > 23355333:[ts=2074912596ssb, mod=4 level=1] GAP procedure initiated:
> > advertise; disc_mode=2 peer_addr_type=0 peer_addr=none adv_channel_map=0
> > own_addr_type=0 adv_filter_policy=0 adv_itvl_min=338 adv_itvl_max=338
> > adv_data_len=28
> > 23355374:[ts=2075232888ssb, mod=64 level=2] gatt_cli: connection failed;
> > status=13
> > ```
> 
> Hmm, I see what you mean.  I think this is probably a bug in the host,
> though I don't see any obvious issues in the code.  I can think of a few
> other possibilities, but they are proably not all that likely.  I want
> to mention them here just so we can rule them out.
> 
> 1. Host event processing code is being starved due to tx or rx of too
> many BLE data packets.
> 
> 2. Host parent task doesn't get a chance to run for an extended period
> of time because higher priority tasks are continuously busy.
> 
> Option 1 concerns data packets only, not events from the controller,
> such as advertising reports.  I think this could only be the case if
> your device is sending or receiving notifications at a very high rate
> (e.g., faster than 10 ms).
> 
> Option 2 depends on how tasks in the application are prioritized.  Does
> your application create a task that could have gotten stuck in a busy
> loop or similar for 30 seconds?
> 
> If neither of these sound likely, then it is probably a bug in Mynewt
> that I will need to replicate.  I noticed from the log that you are
> connecting and advertising at the same time, which I will try.  Is there
> anything else you can say about what your application might have been
> doing when the problem occurred?
> 
> Thanks,
> Chris

Angled-brackets vs. quotes in #include directives

[Christopher Collins]

Hello all,

We've been a bit inconsistent with our use of angled-brackets vs. quotes
in #include directives.  There is a simple rule for this one: use
quotes for user headers; angled-brackets for headers supplied by the
implementation.  "Implementation" is a technical term meaning the
combination of compiler, standard library, linker, assembler, etc.

In other words,

GOOD:

#include 
#include 
#include "os/os.h"

BAD:

#include 
#include 
#include 

BAD:

#include "stdio.h"
#include "assert.h"
#include "os/os.h"

Thanks,
Chris

[jira] [Resolved] (MYNEWT-470) newt build should remove build artifacts left over from previous build when it starts

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-470.

Resolution: Fixed

> newt build should remove build artifacts left over from previous build when 
> it starts
> -
>
> Key: MYNEWT-470
> URL: https://issues.apache.org/jira/browse/MYNEWT-470
> Project: Mynewt
>  Issue Type: Bug
>Reporter: Marko Kiiskila
>        Assignee: Christopher Collins
> Fix For: v1_0_0_beta1
>
>
> I don't know when this broke but...
> newt build should remove any .img/.bin/.elf file when it starts.
> Now I can do 'newt build', 'newt load', and it will use .img created in some 
> previous time. We should notice if you do 'newt build', without doing 'newt 
> create-image'.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-468) Potentially an issue with NRF51 Bootloader

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-468.
--
Resolution: Fixed

It seems to be working now.

> Potentially an issue with NRF51 Bootloader
> --
>
> Key: MYNEWT-468
> URL: https://issues.apache.org/jira/browse/MYNEWT-468
> Project: Mynewt
>  Issue Type: Bug
>  Components: Bootloader
>Affects Versions: v1_0_0_beta1
>Reporter: Sterling Hughes
>    Assignee: Christopher Collins
> Fix For: v1_0_0_beta1
>
>
> Bootloader potentially has issues, we should make sure to test the NRF51 well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: os_events manamgnent

[Christopher Collins]

(responding to Runtime only)

I will reply to Wayne's email this morning, and follow it up with a
message to dev regarding the recent eventq changes.  I just wanted to
send this note so no one spends time writing a response.

Thanks,
Chris

On Fri, Nov 04, 2016 at 01:08:50PM +, Wayne Keenan wrote:
> sorry for the typo'ed subject and also these corrections are required:
> 
> In the first post example this line:
> my_event(_EVENT_QUEUE, my_event);
> should be:
> os_eventq_put(_EVENT_QUEUE, my_event);
> 
> 
> In the second post example this line:
> 
> rc = my_event(_EVENT_QUEUE, OS_EVENT_T_PERUSER+1, arg ); //*1
> 
> 
> should read:
> 
> rc = os_eventq_put(_EVENT_QUEUE, OS_EVENT_T_PERUSER+1, arg ); //*1
> 
> 
> 
> All the best
> Wayne
> 
> On 4 November 2016 at 12:57, Wayne Keenan  wrote:
> 
> > Hi,
> >
> > I had to move from the commonly found  'statically allocated' os_event
> > usage pattern to something dynamic.
> >
> > This is what I'm using:
> >
> > // Post event:
> >
> > struct os_event* my_event = (struct os_event
> > *)os_memblock_get(_mbuf_mpool);
> >
> > if (!my_event) {
> > // TODO: scream loudly
> > return;
> > }
> > my_event->ev_queued = 0;
> > my_event->ev_arg = arg;
> > my_event->ev_type=OS_EVENT_T_PERUSER+1;   // *1
> > my_event(_EVENT_QUEUE, my_event);
> >
> >
> >
> > // Poll handler:
> >
> > case OS_EVENT_T_PERUSER+1:
> > my_data = ev->ev_arg;
> > os_eventq_remove(_evq, ev);
> > os_memblock_put(_mbuf_mpool, ev);   //* 2
> > process_data(my_data);
> > break;
> >
> >
> > This seems to work and will fail quickly (reset) if step *2 isn't
> > performed,  but I have some questions.
> >
> > 1. Is this really correct?  I've not seen it in the samples or the docs.
> > 2. The samples and docs didn't make *2 obvious,  e.g. who owns the memory
> > pool.
> > 3. Would it be better if the Task didn't care which pool the memory came
> > from? i.e. inter task events.
> > 4. I've assumed OS_EVENT_T_PERUSER+n is a valid thing todo, is it? until
> > what n? is there a documented range limit?
> >
> >
> > It would be nice to have the API that perhaps look something like this:
> >
> > // Post:
> > rc = my_event(_EVENT_QUEUE, OS_EVENT_T_PERUSER+1, arg ); //*1
> > if (rc) {
> > // TODO: scream loudly
> > return;
> > }
> >
> >
> > At *1 a default application pool, registered with the OS,  is used (which
> > would require additional API  and setup in the application main startup)
> >
> >
> > // Poll:
> > struct os_event ev;
> >
> > os_eventq_get(_evq, );   // *1
> >
> > switch (ev->ev_type) {
> > case OS_EVENT_T_PERUSER+1:
> > my_data = ev->ev_arg;
> > process_data(my_data);
> > break;
> > }
> >
> >
> > At *1 the event data is copied and the event itself is released by '
> > os_eventq_get'
> >
> >
> > All the best
> > Wayne
> >

Re: STM32F3-Discovery problems

[Christopher Collins]

Hi David,

On Wed, Nov 02, 2016 at 11:51:36AM -0400, David G. Simmons wrote:
> 
> I'm hoping that this isn't just more of my git-idiocy, but ... trying to get 
> the STM32F3-Discovery board to load the blinky app, and keep getting:
> 
> DSimmons-Pro:myproj dsimmons$ newt build stmf3_boot
> Building target targets/stmf3_boot
> Error: Error reading 
> /Users/dsimmons/dev/myproj/repos/mynewt_stm32f3/hw/bsp/stm32f3discovery/bsp.yml:
>  open : no such file or directory
> 
> So, is this yet another instance of my inabilit y manage git? Or is something 
> else going on? 

No, definitely not your fault :).  It looks like we have been negligent
in keeping the stm32f3 repo up to date with develop.  I'm afraid there
is a fair bit of work to do here to get it working with the latest.

Thanks,
Chris

Re: More bletiny

[Christopher Collins]

On Fri, Oct 28, 2016 at 10:12:26AM -0700, aditi hilbert wrote:
> I thought you are compiling all the config options by package
> irrespective of what is used in any particular target.
> 
> Documenting how to do a newt target config  eliminates the
> need to statically document settings. So that is better.

Just in case clarification is needed, the "newt target config" command
only shows you the settings defined by packages that the target pulls
in.

There are probably a lot of useful configuration commands missing from
newt.  A command to show all the settings defined by a particular
package, or all packages, would be useful.  

The reason the "target config" command is target-specific is that, in
addition to showing setting definitions, it also indicates setting
overrides.  I.e., it tells you which packages override which settings,
and with which values.

Chris

Re: More bletiny

[Christopher Collins]

Hi David,

On Thu, Oct 27, 2016 at 06:03:22PM -0400, David G. Simmons wrote:
> There must be more to it than this ... 
> 
> # Package: apps/bletiny
> 
> syscfg.vals:
> SHELL_TASK: 1
> STATS_NAMES: 1
> 
> I can confirm that changing SHELL_TASK to 0 does indeed disable the
> shell, but STATS_NAME does not seem to enable stats. 

That syscfg.yml file looks good to me.  However, I think you may need to
enable some additional settings.  The STATS_NAMES setting causes name
strings to be included in the build, but the stats won't necessarily be
accessible.  

A good way to see the available settings is to use the "newt target
configure " command.  When I use this command on a target
of mine, I see the following settings defined by the sys/stats package:

[ccollins@pseudoephedrine:~/repos/mynewt/core]$ newt target config 
bleprph-nrf52dk
# [...]

* PACKAGE: sys/stats
  * Setting: STATS_CLI
* Description: Expose the "stat" shell command.
* Value: 0
  * Setting: STATS_NAMES
* Description: Include and report the textual name of each 
statistic.
* Value: 0
  * Setting: STATS_NEWTMGR
* Description: Expose the "stat" newtmgr command.
* Value: 0

(Before someone calls me out, yes, the descriptions were all "TBD" until
about five seconds ago! :)

I think you probably want one or both of STATS_CLI / STATS_NEWTMGR.

Sorry for the confusion.  The default behavior of some packages has
changed, and we haven't done a very good job of explaining it on the dev
list.

Chris

Re: Develop branch issues

[Christopher Collins]

On Wed, Oct 26, 2016 at 09:26:38AM -0400, David G. Simmons wrote:
> Fixed ... GIT is some serious black-magic. 
> 
> I was somehow on branch 0.10.0-dev, so I reset my HEAD to
> origin/develop and it all worked. Can now biuild and load ble_tiny. 

That is a relief to hear.  I was out of ideas!

And yes, I can't argue with the comment about git :).

Chris

Re: Develop branch issues

[Christopher Collins]

On Mon, Oct 24, 2016 at 03:49:51PM -0400, David G. Simmons wrote:
> Thanks Chris,
> 
> I'm using develop as I'm working on updating all the docs for the
> 1.0Beta release, and it's rough going in places. :-) 
> 
> I've taken your suggestions and erased the NRF52 device using J-Link
> and that was successful. 
> 
> I've made sure that the repos are on the develop branch 
> 
> DSimmons-Pro:apache-mynewt-core dsimmons$ git branch
> * develop
>   master
> 
> I have targets all set:
> DSimmons-Pro:nrf52dk dsimmons$ newt target show
> targets/blink_nordic
> app=apps/blinky
> bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> build_profile=debug
> targets/my_blinky_sim
> app=apps/blinky
> bsp=@apache-mynewt-core/hw/bsp/native
> build_profile=debug
> targets/myble
> app=@apache-mynewt-core/apps/bletiny
> bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> build_profile=optimized
> cflags=-DSTATS_NAME_ENABLE
> targets/nrf52_boot
> app=@apache-mynewt-core/apps/boot
> bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> build_profile=optimized
> 
> And they look correct (to me)
> 
> newt build nrf52_boot
> Building target targets/nrf52_boot
> Error: Compiler package not specified by BSP
> 
> So, the earlier errors were no doubt caused by something else, and
> something NOT in the develop branch. That being said, there's clearly
> a new step involved in setting the "compiler package" that I'm not
> aware of. 

Recently, many BSP settings were moved out of the BSP's pkg.yml file and
into a new file: bsp.yml.  Among these settings is the compiler package
that should be used to build projects for the BSP.

Is it possible that you don't have the latest newt tool?  An older
version won't know to look for the bsp.yml file, so it won't find the
compiler reference.  Similarly, if you have a new newt tool but an older
core repo, the newt tool will be looking for a bsp.yml file that doesn't
exist.

Let me know if these don't sound like reasonable possiblities and I'll
dig deeper!

Chris

Re: os_time_delay() changed?

[Christopher Collins]

On Fri, Oct 21, 2016 at 11:20:00AM -0700, will sanfilippo wrote:
> Yes, possibly. We never should have used 500 there. It should be in
> terms of OS_TICKS_PER SEC. Some bsps now use 128 ticks per second
> 
> So that is probably it.

To add to Will's answer, if you are dealing with large time values that
may not survive a conversion without overflow, you will probably want to
use the following function:

int
os_time_ms_to_ticks(uint32_t ms, uint32_t *out_ticks)

This function returns a nonzero value if the result won't fit in the
destination uint32_t.

Chris

Re: Odd connection by newt

[Christopher Collins]

On Wed, Oct 12, 2016 at 12:36:45PM -0400, David G. Simmons wrote:
> Hi Chris,
> 
> I run a program called Little Snitch on my mac that monitors all
> incoming and outgoing network activity. I have the screws tightened
> down pretty hard on it, so it always asks before it allows an incoming
> or outgoing connection from a program to a new address. 
> 
> But in the interim, I have figured it out ... I dig a little deeper,
> and found this:
> 
> DSimmons-Pro:client dsimmons$ dig raw.githubusercontent.com
> 
> ; <<>> DiG 9.8.3-P1 <<>> raw.githubusercontent.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37344
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;raw.githubusercontent.com.   IN  A
> 
> ;; ANSWER SECTION:
> raw.githubusercontent.com. 6  IN  CNAME   github.map.fastly.net.
> github.map.fastly.net.687 IN  CNAME   
> prod.github.map.fastlylb.net.
> prod.github.map.fastlylb.net. 6   IN  A   151.101.32.133
> 
> So apparently github is using a shared-hosting or load-balancer that
> resolves to the same address as a bunch of other websites. Like
> andyshora.com  and deladdiogames.com
>  and probably others. 
> 
> I'm guessing that TCPDump doesn't attempt to resolve the host name for
> the IP address, but LittleSnitch does, and gets a (seemingly random)
> hostname back from the shared host/load balancer and therein lies the
> issue. 

Oh wow, that is interesting.  When I tried, I must have gotten "lucky,"
because github didn't use any unusual looking addresses.

Thanks for following up.

Chris

Re: Odd connection by newt

[Christopher Collins]

On Wed, Oct 12, 2016 at 09:16:00AM -0400, David G. Simmons wrote:
> Good morning,
> 
> I'm a bit of a security wonk about some things, so I watch what my machine is 
> doing -- network wise -- pretty carefully. This morning, I was doing a 
> brand-new newt install and came across something odd. 
> 
> For some reason, newt tries to make a connection to andyshora.com 
>  on port 443. 
> andyshora.com -> 151.101.32.133
>Server Name: ETHEREUMCLASIC.COM
>IP Address: 151.101.32.133
>Registrar: GOOGLE INC.
>Whois Server: whois.google.com
>Referral URL: http://domains.google.com
> 
> 
> Why on earth would Newt be attempting this connection? If I deny the 
> connection request, newt fails. 

I don't see that same behavior.  While running tcpdump, I executed the
following commands (latest develop branch of newt):

newt new myproj3
cd myproj3
newt install

The only peer I see newt connecting to is github (a variety of IP
addresses).

Which branch of newt are you using?  Also, out of curiosity, how did you
determine that it is newt that tries to connect to that domain?

Thanks,
Chris

[jira] [Created] (MYNEWT-429) Image upload while running split image causes crash

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-429:
--

 Summary: Image upload while running split image causes crash
 Key: MYNEWT-429
 URL: https://issues.apache.org/jira/browse/MYNEWT-429
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_0_0_beta1


To trigger this crash: 

1. Run a split image such that both the loader and app are in use (i.e., split 
status is set to 'test' or 'run')
2. Upload an image to the device with newtmgr

The board crashes because imgmgr doesn't think slot 1 is in use; it thinks only 
the app in slot 2 is active.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYNEWT-426) Mbuf exhaustion; cause: Reboot log gets registered twice

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-426.

Resolution: Fixed

> Mbuf exhaustion; cause: Reboot log gets registered twice
> 
>
> Key: MYNEWT-426
> URL: https://issues.apache.org/jira/browse/MYNEWT-426
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
>
> When the reboot log's FCB rolls over, the reboot log gets registered two 
> extra times.  This creates a cycle in the log list, causing subsequent "logs 
> list" responses to be infinitely large.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-426) Mbuf exhaustion; cause: Reboot log gets registered twice

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-426:
--

 Summary: Mbuf exhaustion; cause: Reboot log gets registered twice
 Key: MYNEWT-426
 URL: https://issues.apache.org/jira/browse/MYNEWT-426
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins


When the reboot log's FCB rolls over, the reboot log gets registered two extra 
times.  This creates a cycle in the log list, causing subsequent "logs list" 
responses to be infinitely large.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Unsolicited Notify with newtmgr over BLE

[Christopher Collins]

On Wed, Oct 05, 2016 at 05:07:00PM -0700, Mike Ryan wrote:
> On Thu, Oct 06, 2016 at 02:00:25AM +0200, Kevin Townsend wrote:
> > I remember some discussions previously about unsolicited notifies
> > and whether this was or wasn't supported in the BLE spec
> 
> My reading of the spec suggests that it is not legal. Referring to
> Client Characteristic Configuration on PDF page 2228 of Core v4.2 (Vol.
> 3 Part G Sec 3.3.3.3):
> 
> > The Client Characteristic Configuration descriptor value shall be set
> > to the default value at each connection with non-bonded devices.
> 
> Later in the same section:
> 
> > The default value for the Client Characteristic Configuration
> > descriptor value shall be 0x.
> 
> This suggests that the value for notifications will be 0. A value of 1
> signifies "the Characteristic Value shall be notified". It's safe to
> assume that a value of 0 therefore means that the value shall not be
> notified.

I think you're right about that - a CCCD should not be set to one unless
the peer writes to it.  What I'm not so sure about is whether it is
prohibited to send a notification to an unsubscribed peer.  I didn't see
any language in the spec indicating that this is illegal.  The ability
to send unsolicited notifications is useful, and I don't see a reason
why it shouldn't be allowed.

That said, I believe iOS will drop incoming notifications for a
characteristic that doesn't have a CCCD.  I don't believe android has
this limitation.  If iOS requires the characteristic to be subscribable,
then I think we need to comply.

Thanks,
Chris

Re: Directory re-org conversation

[Christopher Collins]

On Thu, Sep 15, 2016 at 03:50:25PM -0700, Sterling Hughes wrote:
> Hey,
> 
> I wanted to get this kicked off, so we can make the changes fairly 
> quickly after the sterly_refactor merge next week (while still giving 
> enough time for discussion.)
[...]

Sounds good to me.  That would be a definite improvement.  There is only
thing I wasn't too sure about:

> - fcb is moved from sys/fcb to fs/fcb

I understand how a flash circular buffer can be considered a type of
file system, but I wonder if the resemblance is strong enough to put it
in a directory called "fs".  Currently, the fs directory contains two
packages:

* fs/fs
* fs/nffs

fs is the generic file system API; nffs is one implementation of that
API.  Putting these two packages in a directory called "fs" makes
sense.  The fcb package doesn't implement the fs API, so it seems a bit
of a stretch to call it one.

I realize we don't want thousands of base directories, so we can't be
too granular in the directory organization.  Maybe it would be better to
rename the fs base directory to something else (store?).  Then all three
packages could go in there without raising eyebrows.

Thanks,
Chris

Re: System config and init

[Christopher Collins]

On Sat, Sep 24, 2016 at 05:47:35PM -0700, Christopher Collins wrote:
[...]
> If two packages with the same priority attempt to override the same
> setting, newt raises an error and aborts the build.  The remedy for this
> problem is for a higher-priority package to override the setting as
> well.

Correction: If two packages with the same priority attempt to override
the same setting *with different values*, newt raises an error and
aborts the build.

Put another way:

Newt reports an error and aborts the build upon detection of an
ambiguous syscfg override.  A syscfg setting is ambiguous if both of the
following are true:

* The final 2+ overrides are done by packages of the same priority
* Of the above overrides, not all values are identical

Hypothetical examples:

1. Ambiguous:

[sys/log/pkg.yml]
pkg.syscfg_defs:
LOG_LEVEL:
description: 'TBD'
value: 0

[net/nimble/host/pkg.yml]
pkg.syscfg_vals:
LOG_LEVEL: 1

[libs/os/pkg.yml]
pkg.syscfg_vals:
LOG_LEVEL: 0

This is ambiguous because two packages of the same priority
(net/nimble/host and libs/os are both library packages) override a
setting with different values.

2. Unambiguous:

[sys/log/pkg.yml]
pkg.syscfg_defs:
LOG_LEVEL:
description: 'TBD'
value: 0

[net/nimble/host/pkg.yml]
pkg.syscfg_vals:
LOG_LEVEL: 1

[libs/os/pkg.yml]
pkg.syscfg_vals:
LOG_LEVEL: 0

[apps/myapp/pkg.yml]
pkg.syscfg_vals:
LOG_LEVEL: 3

The ambiguity is resolved because a higher priority package overrides
the setting.

3. Unambiguous:

[sys/log/pkg.yml]
pkg.syscfg_defs:
LOG_LEVEL:
description: 'TBD'
value: 0

[net/nimble/host/pkg.yml]
pkg.syscfg_vals:
LOG_LEVEL: 1

[libs/os/pkg.yml]
pkg.syscfg_vals:
LOG_LEVEL: 1

Both overrides specify identical values, so there is no ambiguity.

4. Unambiguous:

[sys/log/pkg.yml]
pkg.syscfg_defs:
LOG_LEVEL:
description: 'TBD'
value: 0

[net/nimble/host/pkg.yml]
pkg.syscfg_vals:
LOG_LEVEL: 1

The original setting definition does not factor into ambiguity
detection.  There is only one override here, so an ambiguity is not
possible.

Thanks,
Chris

System config and init

[Christopher Collins]

Hello all,

I thought it would be a good idea to summarize the system configuration
and initialization feature that has been pushed to develop.  This
feature is definitely a work in progress, and this email is meant to
further its development.  In other words, there is a lot of room for
improvement, so please don't hold back with any feedback.

Much of this email will be identical to the previous syscfg summary.  If
you are already familiar with the feature, you may want to skip to the
list of open questions and unresolved issues at the end.

Proposal:
1. Move package initialization out of apps (main()) and into BSPs
   and auto-generated C files.
2. Specify package configuration in the pkg.yml hierarchy.

Motivations:
1. Simplify process of creating an app (no more boilerplate
   code).
2. Simplify system configuration and make it more cohesive (don't
   specify config within C code).
3. Ability to audit entire system configuration via the "newt
   config" command.

### Summary

System initialization happens in two stages:
1. BSP init (bsp_init())
2. sysinit (sysinit())

(1) BSP init sets up everything that is BSP specific:
* Flash map
* Driver initialization: UART, ADC, SPI, etc.

(2) Sysinit sets up all the libraries which aren't BSP or hardware
dependent (os, msys, network stacks, etc).  The initialization code is
implemented in the appropriate package.  Newt generates C code which
executes each package's initialization function.

### Syscfg header file generation

The system knows what to initialize and how to initialize it based on
the contents of the following header file:

/include/syscfg/syscfg.h

For example:

targets/bleprph-nrf52dk/include/syscfg/syscfg.h

This header file is generated by newt during the build process.  Newt
arranges for all packages to have access to this header file.

The syscfg.h header file consists of three sections:
* Settings
* Indication of which packages are present
* Indication of which APIs are available

Here is an abbreviated syscfg.h:

/*** Settings */

#ifndef MYNEWT_VAL_CLOCK_FREQ
#define MYNEWT_VAL_CLOCK_FREQ (100)
#endif

#ifndef MYNEWT_VAL_MSYS_1_BLOCK_COUNT
#define MYNEWT_VAL_MSYS_1_BLOCK_COUNT (15)
#endif

#ifndef MYNEWT_VAL_MSYS_1_BLOCK_SIZE
#define MYNEWT_VAL_MSYS_1_BLOCK_SIZE (260)
#endif

/*** Packages */

#ifndef MYNEWT_PKG_LIBS_NEWTMGR
#define MYNEWT_PKG_LIBS_NEWTMGR (1)
#endif

#ifndef MYNEWT_PKG_LIBS_NEWTMGR_TRANSPORT_BLE
#define MYNEWT_PKG_LIBS_NEWTMGR_TRANSPORT_BLE (1)
#endif

#ifndef MYNEWT_PKG_SYS_CONFIG
#define MYNEWT_PKG_SYS_CONFIG (1)
#endif

/*** APIs */

#ifndef MYNEWT_API_BLE_DRIVER
#define MYNEWT_API_BLE_DRIVER (1)
#endif

#ifndef MYNEWT_API_BLE_TRANSPORT
#define MYNEWT_API_BLE_TRANSPORT (1)
#endif

#ifndef MYNEWT_API_CONSOLE
#define MYNEWT_API_CONSOLE (1)
#endif

Newt generates the syscfg.h file from information in pkg.yml files.
This proposal adds two items to the pkg.yml structure:

1. pkg.syscfg_defs
2. pkg.syscfg_vals

Both of these items are optional.

(1) pkg.syscfg_defs is an associative array of setting definitions.  The
setting name is indicated by the element key.  A setting definition has
the following fields:
* description ("description")
* default value ("value")
* type (optional)

Here is an example from net/nimble/host/pkg.yml:

pkg.syscfg_defs:
BLE_SM:
description: 'Security manager legacy pairing.'
value: 1
BLE_SM_SC:
description: 'Security manager secure connections (4.2).'
value: 0

A setting can only be defined once.  If a setting with the same name is
defined more than once, in any number of pkg.yml files, newt complains
and aborts the build.

(2) pkg.syscfg_vals is also an associative array keyed by setting name.
However, it only contains setting values.  This array is used to
override default setting values.

Here is a hypothetical example:

pkg.syscfg_vals:
MSYS_1_BLOCK_COUNT: 12
MSYS_1_BLOCK_SIZE: 260
CLOCK_FREQ: 100

If a package attempts to override an undefined setting, newt warns the
user and ignores the attempt.  If several packages override the same
setting, the tie is broken according to package priority.  Packages are
prioritized as follows (lowest priority first, highest last):

1. Library
2. BSP
3. App
4. Target

If two packages with the same priority attempt to override the same
setting, newt raises an error and aborts the build.  The remedy for this
problem is for a higher-priority package to override the setting as
well.

The expectation is that libraries would define sensible defaults in
their pkg.yml files, and BSPs, apps, and targets would override those
defaults.  Library packages may also override settings defined by other
library packages.

Within the syscfg.h file:
  

Re: Notify with more than 20 bytes

[Christopher Collins]

On Fri, Sep 23, 2016 at 10:02:32AM -0700, Christopher Collins wrote:
[...]
> If your application needs to send larger ATT packets, it needs to
> negotiate a greater MTU with its peer.  This is accomplished by calling
> ble_gattc_exchange_mtu()
> (http://mynewt.apache.org/develop/network/ble/ble_hs/ble_gattc/functions/ble_gattc_exchange_mtu/)

There is something else I forgot to add.  After MTU negotiation, the
connection's ATT MTU is set to the *lower* of the two peers' preferred
MTU values.  So, if the peer specifies a small preferred MTU, your
application may still be unable to send full-sized notifications.  In
the worst case, the peer could specify a preferred MTU of 23 bytes.  If
this happens, MTU negotiation will have no effect on the maximum size
ATT packets your application can send.

Thanks,
Chris

Re: Notify with more than 20 bytes

[Christopher Collins]

Hello Ha,

On Fri, Sep 23, 2016 at 11:00:32PM +0700, hathach wrote:
> Hi Everyone,
> 
> I am doing throughput testing specifically with notification characteristics
> for sending sensor data from nrf52dk to mobile. I use
> ble_gattc_notify_custom(buffer, size) without any issues, except when the
> buffer is > 20 bytes, it seems to be truncated
> https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/host/
> src/ble_att_clt.c#L74  and mobile app only receive exactly 20 bytes. It is
> not a problem at all for application to manage this (breaking into 20
> bytes/packet) or maybe I haven't used the correct API and/or miss something.

The attribute protocol (ATT) doesn't permit fragmentation.  Thus, any
ATT packet larger than a connection's ATT MTU will be truncated.  The
specified default ATT MTU is pitifully low: 23 bytes.  This allows up to
20 bytes of data in a notification command.

If your application needs to send larger ATT packets, it needs to
negotiate a greater MTU with its peer.  This is accomplished by calling
ble_gattc_exchange_mtu()
(http://mynewt.apache.org/develop/network/ble/ble_hs/ble_gattc/functions/ble_gattc_exchange_mtu/)

I believe the above is sufficient to solve your problem.  I include the
following paragraph just for completeness.

Before any MTU negotation takes place, your application may need to
adjust its preferred ATT MTU.  The preferred MTU is the number that the
application specifies during the MTU exchange.  In NimBLE, the default
preferred ATT MTU is 240, which I think is suitable for most purposes.
If you want a negotiate a smaller MTU, you can reduce the preferred
value by calling ble_att_set_preferred_mtu()
(http://mynewt.apache.org/develop/network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu/).
Currently, the maximum allowed preferred MTU is 240, but this is an
artificial limitation that will be lifted in the future.

Thanks,
Chris

Re: Switching to Master

[Christopher Collins]

Hi Kevin,

On Wed, Sep 21, 2016 at 01:47:34PM +0200, Kevin Townsend wrote:
> Switching to the 'develop' branch is relatively straight-forward using 
> one of the entries in the list here: 
> https://github.com/apache/incubator-mynewt-core/blob/master/repository.yml
> 
> There doesn't seem to be an obvious option to switch back to 'master' 
> though following the advice on the dev list since 'develop' is 
> undergoing a lot of work at the moment.
> 
> I thought '0-latest' might work, which maps to ' mynewt_0_9_0_tag' but 
> that is > 600 commits behind master:
> 
> - https://github.com/apache/incubator-mynewt-core/tree/master
> 
> - https://github.com/apache/incubator-mynewt-core/tree/mynewt_0_9_0_tag
> 
> Should a new entry be adding pointing directly to the 'master' branch or 
> am I perhaps missing something obvious here?

No, you aren't missing anything - we should have added a new pointer for
master.  Thanks for catching this!

For reference, here is the current apache-mynewt-core repository.yml
file:

repo.name: apache-mynewt-core
repo.versions:
"0.0.0": "develop"
"0.7.9": "mynewt_0_8_0_b2_tag"
"0.8.0": "mynewt_0_8_0_tag"
"0.9.0": "mynewt_0_9_0_tag"
"0-latest": "0.9.0"
"0-dev": "0.0.0"
"0.8-latest": "0.8.0"
"0.9-latest": "0.9.0"

I can't think of a new pointer name for master.  Since this is just a
temporary change, I'm thinking we should change 0-dev to point to
master.  0.0.0 would still point to develop.

Thoughts?

Thanks,
Chris

Re: Notes from HAL discussions on sterly_refactor

[Christopher Collins]

Hi Will,

On Mon, Sep 19, 2016 at 06:07:55PM -0700, will sanfilippo wrote:
> The new HAL SPI API is shown below. Highlights of the changes are:
[...]

These changes look great.  I just have a comment and a question:

> /**
>  * Initialize the SPI, given by spi_num.
>  *
>  * @param spi_num The number of the SPI to initialize
>  * @param cfg HW/MCU specific configuration,
>  *passed to the underlying implementation, providing extra
>  *configuration.
>  * @param spi_type SPI type (master or slave)
>  *
>  * @return int 0 on success, non-zero error code on failure.
>  */
> int hal_spi_init(int spi_num, void *cfg, uint8_t spi_type);

My comment here might apply to the HAL in general.  I wonder if there is
any value in including an init function in the HAL abstraction.
Initialization is hardware-specific, as evidenced by the void*
parameter, so wouldn't it be better to just have the caller invoke the
specific function that applies to the MCU?  Unless there is a need to
initialize a SPI without needing to know what MCU you are running on, I
would say the init function should be left out of the HAL, as there is
nothing being abstracted away.

> /**
>  * Sets the default value transferred by the slave. Not valid for master
>  *
>  * @param spi_num SPI interface to use
>  *
>  * @return int 0 on success, non-zero error code on failure.
>  */
> int hal_spi_slave_set_def_tx_val(int spi_num, uint16_t val);

Does this function specify the transmitted character until the next
transceive operation, or does it only apply for txrx operations with a
null rx buffer?  Put another way, if a slave executes the following
sequence of operations:

1. Initialize SPI.
2. Enable SPI.
3. Set default character to 0x99.

And then nothing else, will the slave respond to the master with 0x99
characters?

Thanks,
Chris

Re: Directory re-org conversation

[Christopher Collins]

On Fri, Sep 16, 2016 at 10:04:37AM -0700, Aditi wrote:
> Would libs/bleuart is placed in net/nimble/host/profiles or
> net/nimble/host/services? I am still not clear on services vs.
> profiles in our directory structure. 

I think it should go in net/nimble/host/services.

net/nimble/host/profiles is just for profiles.  A profile provides a
collection of services and additional system configuration.

Chris

Re: slinky example building error

[Christopher Collins]

Hi,

On Thu, Sep 15, 2016 at 03:09:34PM +0800, 王华源 wrote:
> Hi,
> 
>   When I build slinky native example  as document,  the builder throws error
> 
> Building target targets/sim_slinky
> 
> Compiling x509_crl.c
> 
> Error: x509_crl.c: In function 'mbedtls_x509_crl_parse':
> 
> x509_crl.c:508:5: error: this 'else' clause does not guard... 
> [-Werror=misleading-indentation]
[...]

You must be using gcc 6.  Most of the Mynewt developers still use gcc 5
for sim builds, so we haven't fixed the issues reported by the new
compiler.

There are a few ways to work around this until the issues get fixes:

1. Downgrade to gcc 5

This may be easy or difficult, depending on your system and package
manager.

2. Modify the mynewt sim compiler definition so that it doesn't report
the problematic warnings.

I don't have gcc 6 handy at the moment, so I don't know if there are
additional warnings that need to be disabled.  This one can be disabled
by making the following change to
repos/apache-mynewt-core/compiler/sim/compiler.yml:

 compiler.flags.base: >
--m32 -Wall -Werror -ggdb
+-m32 -Wall -Werror -ggdb -Wno-misleading-indentation

(i.e., add "-Wno-misleading-indentation" to compiler.flags.base).

Sorry for the hassle!  Let us know how it goes.

Thanks,
Chris

[AngularJS] Re: Angular 2 RC6/7: Error while running component tests

[Christopher Collins]

I'd like to also add, I only get this error if I bind to the component's 
property with brackets, like this: 
If I don't use brackets, I get no errors, but the value comes in as a 
string, and not a number like I want. 

Can someone please confirm this is happening and I'm not just going crazy?
Create a new app with: ng new test-app
Create a new component with: ng g component foo
Add an input to the component: @Input() public myInput: number;
Implement the component: 
Run tests with: ng test
Confirm test error: "Can't bind to 'myInput' since it isn't a known 
property of 'app-foo'."
Remove brackets and save: 
Confirm tests run and pass.

I'm not sure if this is an issue with Angular RC5/6/7 or with the CLI. 
Thanks for looking.

On Tuesday, September 13, 2016 at 9:26:12 AM UTC-5, Christopher Collins 
wrote:
>
> Hello. I'm having an issue running my *tests* in RC6 and 7. The app runs 
> perfectly in-browser with no errors, but when I run my tests I get, *"Can't 
> bind to 'myInput' since it isn't a known property of 'my-component'."* 
> "myInput" is defined on the component with "@Input() public myInput: 
> number;". I'm using Angular CLI webpack 8, if that makes any difference. 
> What might cause this? Is there a Karma setting somewhere that I'm missing. 
> Thanks.
>

-- 
You received this message because you are subscribed to the Google Groups 
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to angular+unsubscr...@googlegroups.com.
To post to this group, send email to angular@googlegroups.com.
Visit this group at https://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

[AngularJS] Angular 2 RC6/7: Error while running component tests

[Christopher Collins]

Hello. I'm having an issue running my *tests* in RC6 and 7. The app runs 
perfectly in-browser with no errors, but when I run my tests I get, *"Can't 
bind to 'myInput' since it isn't a known property of 'my-component'."* 
"myInput" is defined on the component with "@Input() public myInput: 
number;". I'm using Angular CLI webpack 8, if that makes any difference. 
What might cause this? Is there a Karma setting somewhere that I'm missing. 
Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to angular+unsubscr...@googlegroups.com.
To post to this group, send email to angular@googlegroups.com.
Visit this group at https://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

Re: Adding C++ header guards?

[Christopher Collins]

On Sun, Sep 11, 2016 at 04:32:07PM -0700, Sterling Hughes wrote:
> I think a temporary exception would be fine: but I’m not sure the 
> impact, perhaps somebody who understands C++ better can chime in.  Why 
> are ‘#includes’ _excluded_ from the extern “C” namespace?  Is it 
> just to avoid cluttering that namespace?  Or are there subtle/nefarious 
> effects?

The danger is that included headers could contain actual C++
declarations (e.g., overloaded functions).  If the header contents are
declared with C linkage via extern "C", compilation will fail.  This
isn't an issue in our case because there isn't any C++ code in the
repository.

Chris

> If its just to avoid namespace clutter, I think a two-part process (i.e. 
> we add header guards now, then fix ‘#includes’ ad-hoc) would be 
> good.  It would also be good if we could have checkguards not fix up the 
> files, but rather just spit out an error on non-conformant files, that 
> way we could add it to our CI suite and get notifications when we break 
> C++ style per-commit.

Re: Adding C++ header guards?

[Christopher Collins]

On Sun, Sep 11, 2016 at 12:39:27PM -0700, Christopher Collins wrote:
> Look great to me, thanks!  I just have a question - the commit message
> indicates that two files were not modified:
> 
> libs/baselibc/src/baselibc_test/unittests.h
> libs/shell/include/shell/shell_prompt.h
> 
> Why did you exclude these files?

Er... the commit message also explains why they were excluded [*].
Sorry :).

[*] "Because the hack I used looks for normal #include guards for its place
to put the C++ ones, and those files don't have any."

Re: Adding C++ header guards?

[Christopher Collins]

On Sun, Sep 11, 2016 at 08:19:58PM +0100, Tim Hutt wrote:
> I like C++ and would like to use it with MyNewt, so I've written a very
> hacky tool in Go to detect C++ header guards:
> 
> https://github.com/Ti/GuardChecker
> 
> Here is the result of running it on apache-mynewt-core:
> 
> https://github.com/Ti/incubator-mynewt-core/commit/fec88d1c8b3f36e14eef700ab37b18ef78cd2418
> 
> It's not perfect but it seems to work ok. Check the commit message and the
> GuardChecker Readme for some more details.
> 
> What do you think?

Look great to me, thanks!  I just have a question - the commit message
indicates that two files were not modified:

libs/baselibc/src/baselibc_test/unittests.h
libs/shell/include/shell/shell_prompt.h

Why did you exclude these files?

Thanks,
Chris

Re: Removing os_error_t

[Christopher Collins]

On Sun, Sep 11, 2016 at 10:42:07AM -0700, Sterling Hughes wrote:
[...]
> So — prior to 1.0, I think we should clean this up.  My proposal is to 
> go with plain old integers as error codes across the system.  0 is no 
> error, a negative value is the error code and a positive value can be 
> used when returning actual data (and must be marked in the function 
> signature/doxygen comment.)  Although, if we want to go the enum route, 
> I’m happy with that too, but I think we should clean up the code that 
> currently uses integers as return values (there is a lot of it), to move 
> to cleanly specifying where the error parameters are.

I agree with removing enum return codes, as enums have odd semantics and
don't provide any real benefit in my opinion [*].  0 for success,
positive for data, negative for error sounds like a fine convention to
me.

Chris

[*] The type of an enum is implementation defined (4).  The type of an enum
value is always int (3): 

(ISO/IEC 9899:201x, 6.7.2.2)
3 The identifiers in an enumerator list are declared as constants that
have type int and may appear wherever such are permitted. An enumerator
with = defines its enumeration constant as the value of the constant
expression. If the first enumerator has no =, the value of its
enumeration constant is 0. Each subsequent enumerator with no = defines
its enumeration constant as the value of the constant expression
obtained by adding 1 to the value of the previous enumeration constant.
(The use of enumerators with = may produce enumeration constants with
values that duplicate other values in the same enumeration.) The
enumerators of an enumeration are also known as its members.

4 Each enumerated type shall be compatible with char, a signed integer
type, or an unsigned integer type. The choice of type is
implementation-defined, but shall be capable of representing the
values of all the members of the enumeration.The enumerated type is
incomplete until immediately after the } that terminates the list of
enumerator declarations, and complete thereafter.

Re: Adding C++ header guards?

[Christopher Collins]

Only public headers (files in a "/include" directory) need the guards.
Private headers (files in a "src/" directory) are only intended to be
included by C files, and don't require them.  Not that it hurts to add
guards to the private headers as well.

Chris

On Fri, Sep 09, 2016 at 04:46:44PM -0700, Peter Snyder wrote:
> Okay, I’ll take this.
> 
> I'm including a quick list of the files I think don’t have the C++ wrappers. 
> I’d appreciate any input on if there are any directories or specific files 
> that should not have wrappers added (like for example, imported source that 
> shouldn't be altered).
> 
> Thanks,
> 
> - peter
> 

> ./repos/apache-mynewt-core/apps/blecent/src/blecent.h
> ./repos/apache-mynewt-core/apps/bleprph/src/bleprph.h
> ./repos/apache-mynewt-core/apps/bletest/src/bletest_priv.h
> ./repos/apache-mynewt-core/apps/bletiny/src/bletiny.h
> ./repos/apache-mynewt-core/drivers/uart_bitbang/include/uart_bitbang/uart_bitbang.h
> ./repos/apache-mynewt-core/drivers/uart_bitbang/include/uart_bitbang/uart_bitbang_api.h
> ./repos/apache-mynewt-core/fs/fs/include/fs/fs.h
> ./repos/apache-mynewt-core/fs/fs/include/fs/fs_if.h
> ./repos/apache-mynewt-core/fs/fs/include/fs/fsutil.h
> ./repos/apache-mynewt-core/fs/fs/src/fs_priv.h
> ./repos/apache-mynewt-core/fs/nffs/include/nffs/nffs.h
> ./repos/apache-mynewt-core/fs/nffs/include/nffs/nffs_test.h
> ./repos/apache-mynewt-core/fs/nffs/src/nffs_priv.h
> ./repos/apache-mynewt-core/fs/nffs/src/test/arch/sim/nffs_test_priv.h
> 
> ./repos/apache-mynewt-core/hw/bsp/native/include/bsp/bsp_sysid.h
> ./repos/apache-mynewt-core/hw/hal/include/hal/hal_watchdog.h
> ./repos/apache-mynewt-core/hw/mcu/native/include/mcu/hal_dac.h
> ./repos/apache-mynewt-core/hw/mcu/native/include/mcu/mcu_sim.h
> ./repos/apache-mynewt-core/hw/mcu/native/include/mcu/native_bsp.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf51xxx/include/mcu/compiler_abstraction.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf51xxx/include/mcu/cortex_m0.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf51xxx/include/mcu/nrf.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf51xxx/include/mcu/nrf51422_peripherals.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf51xxx/include/mcu/nrf51822_peripherals.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf51xxx/include/mcu/nrf51_bitfields.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf51xxx/include/mcu/nrf51_deprecated.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/include/mcu/compiler_abstraction.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/include/mcu/cortex_m4.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/include/mcu/nrf.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/include/mcu/nrf51_to_nrf52.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/include/mcu/nrf52832_peripherals.h
> ./repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/include/mcu/nrf52_bitfields.h
> ./repos/apache-mynewt-core/hw/mcu/stm/stm32f4xx/include/mcu/cortex_m4.h
> ./repos/apache-mynewt-core/hw/mcu/stm/stm32f4xx/include/mcu/stm32f4_bsp.h
> ./repos/apache-mynewt-core/libs/baselibc/include/assert.h
> ./repos/apache-mynewt-core/libs/baselibc/include/ctype.h
> ./repos/apache-mynewt-core/libs/baselibc/include/klibc/inline.h
> ./repos/apache-mynewt-core/libs/baselibc/include/stdio.h
> ./repos/apache-mynewt-core/libs/baselibc/include/stdlib.h
> ./repos/apache-mynewt-core/libs/baselibc/include/string.h
> ./repos/apache-mynewt-core/libs/baselibc/src/baselibc_test/unittests.h
> ./repos/apache-mynewt-core/libs/baselibc/src/malloc.h
> ./repos/apache-mynewt-core/libs/bleuart/include/bleuart/bleuart.h
> ./repos/apache-mynewt-core/libs/boot_serial/include/boot_serial/boot_serial.h
> ./repos/apache-mynewt-core/libs/boot_serial/src/boot_serial_priv.h
> ./repos/apache-mynewt-core/libs/bootutil/include/bootutil/bootutil_misc.h
> ./repos/apache-mynewt-core/libs/bootutil/include/bootutil/bootutil_test.h
> ./repos/apache-mynewt-core/libs/bootutil/include/bootutil/image.h
> ./repos/apache-mynewt-core/libs/bootutil/include/bootutil/loader.h
> ./repos/apache-mynewt-core/libs/bootutil/include/bootutil/sign_key.h
> ./repos/apache-mynewt-core/libs/bootutil/src/bootutil_priv.h
> ./repos/apache-mynewt-core/libs/cmsis-core/include/cmsis-core/core_caFunc.h
> ./repos/apache-mynewt-core/libs/cmsis-core/include/cmsis-core/core_caInstr.h
> ./repos/apache-mynewt-core/libs/cmsis-core/include/cmsis-core/core_cmFunc.h
> ./repos/apache-mynewt-core/libs/cmsis-core/include/cmsis-core/core_cmInstr.h
> ./repos/apache-mynewt-core/libs/console/full/include/console/console.h
> ./repos/apache-mynewt-core/libs/console/full/include/console/prompt.h
> ./repos/apache-mynewt-core/libs/console/stub/include/console/console.h
> ./repos/apache-mynewt-core/libs/console/stub/include/console/console_prompt.h
> ./repos/apache-mynewt-core/libs/crash_test/include/crash_test/crash_test.h
> ./repos/apache-mynewt-core/libs/crash_test/src/crash_test_priv.h
> ./repos/apache-mynewt-core/libs/elua/elua_base/include/elua_base/elua.h
> 

[jira] [Updated] (MYNEWT-347) BLE Host - GAP update params request should fall back to L2CAP update procedure

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-347:
---
Fix Version/s: (was: v1_0_0_rel)
   v1_0_0_beta1

> BLE Host - GAP update params request should fall back to L2CAP update 
> procedure
> ---
>
> Key: MYNEWT-347
> URL: https://issues.apache.org/jira/browse/MYNEWT-347
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Nimble
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_beta1
>
>
> Currently, the GAP update parameters procedure only sends the LE connection 
> update HCI command.  This works if either of the following is true:
> * The device is the master
> * Both peers support the connection parameter update link layer procedure
> If the device is a slave and the connection parameter update LL procedure is 
> unsupported, the GAP procedure will fail.  Rather than failing, the GAP code 
> should initiate the L2CAP update procedure.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYNEWT-347) BLE Host - GAP update params request should fall back to L2CAP update procedure

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-347.

Resolution: Fixed

> BLE Host - GAP update params request should fall back to L2CAP update 
> procedure
> ---
>
> Key: MYNEWT-347
> URL: https://issues.apache.org/jira/browse/MYNEWT-347
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Nimble
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_beta1
>
>
> Currently, the GAP update parameters procedure only sends the LE connection 
> update HCI command.  This works if either of the following is true:
> * The device is the master
> * Both peers support the connection parameter update link layer procedure
> If the device is a slave and the connection parameter update LL procedure is 
> unsupported, the GAP procedure will fail.  Rather than failing, the GAP code 
> should initiate the L2CAP update procedure.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Mynewt system initialization

[Christopher Collins]

Hello all,

This is a follow-up email regarding Mynewt system initialization.  I
took all of your feedback (very helpful, thanks!) and did some more
thinking.  As always, all comments, criticisms, and suggestions are
appreciated.

Thanks,
Chris

### Recap

Proposal:
1. Move system initialization out of apps and into BSPs and
   auto-generated C files.
2. Specify system settings in config files.

Motivations:
1. Simplify process of creating an app (no more boilerplate
   code).
2. Simplify system configuration (don't specify config within C
   code).
3. Better code organization; cputime, msys, etc. "feel" more
   like system-level modules than application-level, so put
   initialization code where it belongs.

Examples of "system modules" are:
* mbufs / msys.
* Network stacks (e.g., NimBLE host, controller, and HCI
  transport).
* newtmgr
* console
* logging
* drivers

The biggest challenge is: ensuring the developer maintains
precise control over the system configuration.  The current
Mynewt scheme gives control to the developer by pushing
configuration up to the application level where he is forced to
deal with it.

### Changes from previous proposal

* Settings go in pkg.yml files; elimination of syscfg.yml files.
* Initialization is done by generated C files; init functions specified
  in pkg.yml files.
* Removal of newt "features" (pkg.features).

### Summary

System initialization happens in two stages:
1. BSP init (bsp_init())
2. sysinit (sysinit())

(1) BSP init sets up everything that is BSP specific:
* UARTs
* Flash map
* Other hardware drivers

(2) Sysinit sets up all the libraries which aren't BSP or hardware
dependent (os, msys, network stacks, etc).  The initialization code is
implemented in the appropriate package.  Newt generates C code which
executes each package's initialization function.

### Syscfg header file generation

The system knows what to initialize and how to initialize it based on
the contents of the following header file:

/include/syscfg/syscfg.h

For example:

targets/bleprph-nrf52dk/include/syscfg/syscfg.h

This header file is generated by newt during the build process.  Newt
arranges for all packages to have access to this header file.

The syscfg.h header file consists of three sections:
* Settings
* Indication of which packages are present
* Indication of which APIs are available

Here is an abbreviated syscfg.h:

/*** Settings */

#ifndef MYNEWT_VAL_CLOCK_FREQ
#define MYNEWT_VAL_CLOCK_FREQ (100)
#endif

#ifndef MYNEWT_VAL_MSYS_1_BLOCK_COUNT
#define MYNEWT_VAL_MSYS_1_BLOCK_COUNT (15)
#endif

#ifndef MYNEWT_VAL_MSYS_1_BLOCK_SIZE
#define MYNEWT_VAL_MSYS_1_BLOCK_SIZE (260)
#endif

/*** Packages */

#ifndef MYNEWT_PKG_LIBS_NEWTMGR
#define MYNEWT_PKG_LIBS_NEWTMGR (1)
#endif

#ifndef MYNEWT_PKG_LIBS_NEWTMGR_TRANSPORT_BLE
#define MYNEWT_PKG_LIBS_NEWTMGR_TRANSPORT_BLE (1)
#endif

#ifndef MYNEWT_PKG_SYS_CONFIG
#define MYNEWT_PKG_SYS_CONFIG (1)
#endif

/*** APIs */

#ifndef MYNEWT_API_BLE_DRIVER
#define MYNEWT_API_BLE_DRIVER (1)
#endif

#ifndef MYNEWT_API_BLE_TRANSPORT
#define MYNEWT_API_BLE_TRANSPORT (1)
#endif

#ifndef MYNEWT_API_CONSOLE
#define MYNEWT_API_CONSOLE (1)
#endif

Newt generates the syscfg.h file from information read from pkg.yml
files.  This proposal adds two items to the pkg.yml structure:

1. pkg.syscfg_defs
2. pkg.syscfg_vals

Both of these items are optional.

(1) pkg.syscfg_defs is an associative array of setting definitions.  The
setting name is indicated by the element key.  A setting definition has
the following fields:
* description ("description")
* default value ("value")
* requirements (TBD)

Here is an example from net/nimble/host/pkg.yml:

pkg.syscfg_defs:
BLE_SM:
description: 'Security manager legacy pairing.'
value: 1
BLE_SM_SC:
description: 'Security manager secure connections (4.2).'
value: 0

A setting can only be defined once.  If a setting with the same name is
defined more than once, in any number of pkg.yml files, newt complains
and aborts the build.

(2) pkg.syscfg_vals is also an associative array keyed by setting name.
However, it only contains setting values.  This array is used to
override default setting values.

Here is a hypothetical example:

pkg.syscfg_vals:
MSYS_1_BLOCK_COUNT: 12
MSYS_1_BLOCK_SIZE: 260
CLOCK_FREQ: 100

If a package attempts to override an undefined setting, newt complains
and the build is aborted.  If several packages override the same
setting, the tie is broken according to package priority.  Packages are
prioritized as follows (lowest priority 

[jira] [Created] (MYNEWT-380) Only one fcb log supported

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-380:
--

 Summary: Only one fcb log supported
 Key: MYNEWT-380
 URL: https://issues.apache.org/jira/browse/MYNEWT-380
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
 Fix For: v1_0_0_beta1


sys/log/src/log_fcb.c contains a global fcb_log struct that is used for the 
reboot log.  An application may want to use several FCB logs, which is 
currently not possible.

A possible solution is to change log_fcb_handler_init() as follows:

From:
{code}
int
log_fcb_handler_init(struct log_handler *handler, struct fcb *fcb, uint8_t 
entries)
{code}

To:
{code}
int
log_fcb_handler_init(struct log_handler *handler, struct fcb_log *fcb_log, 
uint8_t entries)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Setting connection parameters

[Christopher Collins]

Hi Tim,

Thanks for the report.  I am curious why ble_gap_update_params() did not
work with the Xperia.  One thing I should mention is that the central is
not obligated to update the connection when the peripheral asks it to.
It should have responded to the request, though.

On Tue, Aug 30, 2016 at 04:10:58PM +0100, Tim Hutt wrote:
[...]
> 3. Using a 5 second timeout, then ble_gap_update_params it works as
> expected! I couldn't find in the spec where it mentions the 5 seconds, but
> I guess it is needed in some way.

The five second recommendation is in Vol. 3, Part C, Appendix A, Table
A.1:

Timer name
TGAP(conn_pause_peripheral)

Value
5s

Description
Minimum time upon connection establishment before the peripheral
starts a connection update procedure

Requirement or Recommendation
Recommended value

Thanks,
Chris

[jira] [Created] (MYNEWT-376) No error response on rx of unrecognized newtmgr ID.

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-376:
--

 Summary: No error response on rx of unrecognized newtmgr ID.
 Key: MYNEWT-376
 URL: https://issues.apache.org/jira/browse/MYNEWT-376
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins


Mynewt should send an error response when it receives a request it doesn't 
understand.  Currently it silently drops it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Mynewt system initialization

[Christopher Collins]

On Tue, Aug 30, 2016 at 12:35:31AM +, p...@wrada.com wrote:
> Would you expect that everyone that writes a new core package, would add
> their init code to sys/sysinit package and include their package in the
> dependencies for sys/sysinit?  Would that mean that if I include
> sys/sysinit as a dependency in my app (every app probably would), it
> automatically becomes dependent on all packages, or would this be special
> somehow and not be necessary.

I think the sysinit package should have access to all packages in the
build.  Newt would have to do some magic to arrange for this (perhaps a
setting in the pkg.yml file).  The sysinit package wouldn't explicitly
depend on these packages, it would just use whatever is already getting
pulled in.

> Does it make sense to have the sysinit.yml file include the "init method
> name² for the package and have newt build that sysintit.c file special for
> your target?  This has the advantage that we are not coupling these
> projects together or using tons of ifdefs which make the code hard to read
> (its hard to teach my idea about defines that newt creates). It raises the
> issue of order though since we can¹t enforce an order if its generated
> like this. We would also have to make these a fixed prototype to make it
> easy (I think it would be easy to make the int foo(void)).

That is not a bad idea at all.  It does bother me that sysinit needs
code to initialize every core package, and this seems like a good
solution to that problem.

You are right about the ordering issue.  One option is for each system
package cto have a numeric "stage" setting.  The sysinit code would
initialize every package in stage 1, before those in stage 2, and so on.
Within a stage, packages would be initialized in alphabetical order (or
whatever).

> Would non-core packages put their init code in sys/sysinit?  Or is this
> just for os-core stuff?

I think if non-core packages can leverage the sysinit feature, then they
should.  I was thinking it would just be core packages because sysinit
would need special code for each package.  However, you init function
idea might be a way to solve this issue and allow other packages to use
it.

> My preference is to put some thought into the yml file format for future.
> We¹ve got tons of packages and its may be a pain to make a drastic change
> later.  We don¹t need to add the features now, just make sure the yml file
> has the hierarchy to support the things we are thinking about now.

Thanks,
Chris

Re: Mynewt system initialization

[Christopher Collins]

On Mon, Aug 29, 2016 at 04:53:12PM -0700, marko kiiskila wrote:
> Hi,
> 
> for bootloader I’d like to have different set of devices than the app.
> What did you have in mind for that? Different bsp_init() routines?
> Or would bsp_init() have conditional parts depending on syscfg.h says?

I know you already know the following, but I wanted to summarize how
Mynewt currently handles this for other readers.

Currently, each BSP in apache-mynewt-core is intended to be used with
both the boot loader and with "real" apps.  When a BSP setting needs to
have a different value for the boot loader, this is indicated via the
"bootloader" feature.  Here is an example from the nrf52dk BSP's pkg.yml
file:

pkg.linkerscript: "nrf52dk.ld"
pkg.linkerscript.bootloader.OVERWRITE: "boot-nrf52dk.ld"

I hadn't considered it, but it should be possible to do the same thing
for settings in syscfg.yml files.  That said, I think it might better to
have two different BSPs.  My feeling is that the BSP should specify
which peripherals get initialized, and this should not be dependent on
which app you are building.  

Another option is to disable peripherals in the boot target's syscfg.yml
file, since the target's configuration overrides the BSP's. I don't
think it's possible to do this in the app's file, because the app
doesn't know which BSP it is being built for.  I don't think this is a
very good solution, because one of the primary goals of this feature is
to move system configuration out of the way so that the app developer
doesn't need to worry about it (at first).

Thanks,
Chris

Re: newt build error

[Christopher Collins]

On Mon, Aug 29, 2016 at 10:32:25AM -0600, Cody Smith wrote:
> Hey Everybody,
> 
> I'm trying to build the ble tiny example in Ubuntu 16.04 using the Newt
> 0.8.0.  I've done a newt upgrade, and still get this same error.  The error
> on a newt build is:
> 
> Building target targets/bleFuzzTiny_tgt
> Compiling cmd.c
> Error: cmd.c: In function 'cmd_passkey':
> cmd.c:1523:27: error: storage size of 'pk' isn't known
>  struct passkey_action pk;
>^
> cmd.c:1523:27: error: unused variable 'pk' [-Werror=unused-variable]
> cc1: all warnings being treated as errors
> 
> exit status 1
> 
> 
> I'm using gcc version gcc version 5.4.0 20160609 (Ubuntu
> 5.4.0-6ubuntu1~16.04.2).

Hi Cody,

I am able to build bletiny from 0.8.0 and 0.9.0, so I think you might
have a partially-upgraded apache-mynewt-core repo.  This might happen if
you have made some local modifications to the repos/mynewt-apache-core
directory prior to performing the "newt upgrade".  Does this sound like
a possibility?  You can see if this is the case by entering the
repos/mynewt-apache-core directory and then running:

git status

Thanks,
Chris

Re: [jira] [Resolved] (MYNEWT-231) newt when processing the pkt.cflags stuff doesn't like a space between -I and the include path. It seems to omit the -I

[Christopher Collins]

On Sun, Aug 28, 2016 at 11:04:51AM -0700, Sterling Hughes wrote:
> As a resolution, can we quote these values and have this behavior obeyed?  

I'm afraid not.  If the two tokens are quoted, they are interpreted as a
single yaml string (good).  The viper library then splits the string
into separate tokens (bad).  Double-quoting the cflag doesn't work
either; in fact it breaks the build process.  When I build the following
target:

### Package: targets/test-sim
pkg.name: "targets/test-sim"
pkg.type: "target"
pkg.description:
pkg.author:
pkg.homepage:

pkg.cflags:
- "'-I /tmp'"

The two tokens still get split on the command line as follows:

2016/08/28 11:42:51 [DEBUG] gcc -c -o 
/home/ccollins/repos/mynewt/core/bin/targets/test-sim/app/fs/nffs/nffs_gc.o 
nffs_gc.c '-I DAPP_NAME="test" -DARCH_sim -DBSP_NAME="native" -DFEATURE_FCB 
-DFEATURE_FS -DFEATURE_NFFS -DFEATURE_TEST -DMN_LINUX -O0 -Wall -Werror -ggdb 
-m32 /tmp' -I/home/ccollins/repos/mynewt/core/apps/

That is, each inner quote "sticks" to its adjacent token.

I don't see any way around this, short of modifying Viper.

Specifying an include path as a target cflag seems like an unusual thing
to do.  Is there a likely scenario where someone would do this?

Chris

[jira] [Resolved] (MYNEWT-231) newt when processing the pkt.cflags stuff doesn't like a space between -I and the include path. It seems to omit the -I

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-231.

Resolution: Won't Fix

Unfortunately, this is caused by the underlying Viper library - it splits 
values on whitespace by calling strings.Fields(v):

{code}
func ToStringSliceE(i interface{}) ([]string, error) {
jww.DEBUG.Println("ToStringSliceE called on type:", reflect.TypeOf(i))

var a []string

switch v := i.(type) {
case []interface{}:
for _, u := range v {
a = append(a, ToString(u))
}
return a, nil
case []string:
return v, nil
case string:
return strings.Fields(v), nil
case interface{}:
str, err := ToStringE(v)
if err != nil {
return a, fmt.Errorf("Unable to Cast %#v to []string", i)
}
return []string{str}, nil
default:
return a, fmt.Errorf("Unable to Cast %#v to []string", i)
}
}
{code}

> newt when processing the pkt.cflags stuff doesn't like a space between -I and 
> the include path.  It seems to omit the -I 
> -
>
> Key: MYNEWT-231
> URL: https://issues.apache.org/jira/browse/MYNEWT-231
> Project: Mynewt
>  Issue Type: Improvement
>    Reporter: Paul Dietrich
>Assignee: Christopher Collins
> Fix For: v1_0_0_beta1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-308) Need helper functions in newt to allow you to create new packages

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-308.
--
Resolution: Duplicate

> Need helper functions in newt to allow you to create new packages
> -
>
> Key: MYNEWT-308
> URL: https://issues.apache.org/jira/browse/MYNEWT-308
> Project: Mynewt
>  Issue Type: New Feature
>Reporter: Sterling Hughes
>    Assignee: Christopher Collins
> Fix For: v1_0_0_beta1
>
>
> Need a set of helper functions that makes it easy to create new packages in 
> your local repository, without having to manually copy them.
> A couple of templates should be bundled with newt: 
> - library
> - app
> - bsp
> And you should be able to use a command like: 
> $ newt pkg new --type lib libs/my_new_lib
> And have it automatically create a new library.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Setting connection parameters

[Christopher Collins]

Hi Tim,

On Wed, Aug 24, 2016 at 11:04:15PM +0100, Tim Hutt wrote:
> Hi,
> 
> With the bleprph example, whenever a central connects it seems to use a
> small connection interval (like 50ms). I'd like a longer one (around
> 500ms).

[...]

To use different connection parameters, one of the two peers needs to
perform a connection update procedure.  A central may read the
peripheral's preferred connection parameters and initiate a connection
update with those values, but I don't think this is very common.

As the slave, you can update the connection by calling
ble_gap_update_params()
(http://mynewt.apache.org/develop/network/ble/ble_hs/ble_gap/functions/ble_gap_update_params/)
after the connection is established.  Note: the NimBLE host API has
changed quite a bit lately, so if you are using 0.9.0 (instead of the
master branch), the API reference may be inaccurate.

The spec recommends that a peripheral allow at least five seconds after
connection establishment before updating the connection, but this is not
a requirement.  Probably the easiest place to call
ble_gap_update_params() is within the GAP event callback itself (i.e.,
as soon as the stack notifies you taht the connection has been
established).

Please pipe up if you run into any issues :).

Thanks,
Chris

[jira] [Commented] (MYNEWT-261) stats module does not allow multiple instances of the same section

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15435715#comment-15435715
 ] 

Christopher Collins commented on MYNEWT-261:


Paul, could you please clarify what you mean by "the stats module does not copy 
the name"?

For what it's worth, here is how I would create three instances of a stats 
section:
{code}
/* Define the stats section struct. */
STATS_SECT_START(my_stats)
STATS_SECT_ENTRY(conn_create)
STATS_SECT_ENTRY(conn_delete)
STATS_SECT_ENTRY(reset)
STATS_SECT_END

/* Define three instances of "my_stats". */
STATS_SECT_DECL(my_stats) px_1;
STATS_SECT_DECL(my_stats) px_2;
STATS_SECT_DECL(my_stats) px_3;
{code}

> stats module does not allow multiple instances of the same section
> --
>
> Key: MYNEWT-261
> URL: https://issues.apache.org/jira/browse/MYNEWT-261
> Project: Mynewt
>  Issue Type: Improvement
>Reporter: Paul Dietrich
>Assignee: Christopher Collins
> Fix For: v1_0_0_beta1
>
>
> Suppose I make a driver for peripheral X.  My driver supports up to 3 
> peripherals of type X.  I want each one to have a unique name.
> px_1
> px_2
> px_3
> Right now it takes a bit of fussing to do this since the stats modules does 
> not copy the name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYNEWT-161) NFFS - Inefficient restoring of large files

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-161.

Resolution: Fixed

Yes, this was fixed by Peter in commit f9ef5686269fb626a042bbd2195e4db7d500ddf5.

> NFFS - Inefficient restoring of large files
> ---
>
> Key: MYNEWT-161
> URL: https://issues.apache.org/jira/browse/MYNEWT-161
> Project: Mynewt
>  Issue Type: Bug
>  Components: NFFS
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The inefficiency was introduced in the fix for MYNEWT-160.  This ticket is 
> for replacing that fix with something more efficient.
> Details to follow...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYNEWT-360) "the input device is not a TTY" when newt isn't run in terminal

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15433990#comment-15433990
 ] 

Christopher Collins commented on MYNEWT-360:


Thanks, Tim.  Could you try using the updated newt script that I posted to 
MYNEWT-361?  I have a hunch that will fix this issue as well.

The updated script only allocates a tty for interactive commands which execute 
gdb (debug and run).  I don't think you would ever run these commands from an 
IDE, so that might be sufficient.

Out of curiosity, which IDE are you running newt from?

> "the input device is not a TTY" when newt isn't run in terminal
> ---
>
> Key: MYNEWT-360
> URL: https://issues.apache.org/jira/browse/MYNEWT-360
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Affects Versions: v0_9_0
> Environment: Ubuntu 14.10 using the Docker version of newt
>Reporter: Tim
>Assignee: Todd Mitton
>
> Basically, if I run newt (the Docker wrapper script) in an IDE rather than a 
> terminal, it prints this:
> newt build bleprph -DLOG_LEVEL=LOG_LEVEL_INFO
> the input device is not a TTY
> I believe this is some crzy Docker issue, probably this one:
> https://github.com/docker/docker/issues/8755



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

gdb scripts

[Christopher Collins]

Hello all,

I think we need a good location for gdb command files (containing
macros).

I propose:
@apache-mynewt-core/compiler/gdbmacros/

Thoughts?

Thanks,
Chris

[jira] [Commented] (MYNEWT-361) Consecutive commands not run in terminal

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15433675#comment-15433675
 ] 

Christopher Collins commented on MYNEWT-361:


Thanks, Tim.  I do see the same problematic behavior when using docker (in the 
below excerpt, I am using a script called "dnewt" rather than "newt"):

{noformat}
admin@bleh:~/ccollins/repos/mynewt/core$ dnewt target create nrf52_boot
dnewt target set nrf52_boot app=@apache-mynewt-core/apps/boot
dnewt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
dnewt target set nrf52_boot build_profile=optimized
Target targets/nrf52_boot successfully created
admin@bleh:~/ccollins/repos/mynewt/core$ dnewt target show nrf52_boot
targets/nrf52_boot
{noformat}

I verified that the dnewt script only gets executed once by inserting an 'echo' 
command before the docker command. 

The newt script (dnewt in this case) creates an interactive terminal in the 
docker environment and pipes stdin/stdout/stderr to/from the host.  My guess is 
that the subsequent pasted lines get swallowed by the docker environment, 
rather than residing in the host's tty buffer.  I don't have any ideas for 
fixing this, but let's definitely keep this bug open.

This doesn't really solve your problem, but it might be helpful to know that 
you can issue multiple "target set" commands in a single newt invocation.  For 
example:

{noformat}
admin@bleh:~/ccollins/repos/mynewt/core$ dnewt target set nrf52_boot 
app=apps/boot   \
>
> bsp=hw/bsp/nrf52dk  \
>
> build_profile=optimized
Target targets/nrf52_boot successfully set target.app to apps/boot
Target targets/nrf52_boot successfully set target.bsp to hw/bsp/nrf52dk
Target targets/nrf52_boot successfully set target.build_profile to optimized
{noformat}

> Consecutive commands not run in terminal
> 
>
> Key: MYNEWT-361
> URL: https://issues.apache.org/jira/browse/MYNEWT-361
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Affects Versions: v0_9_0
> Environment: Ubuntu 14.10 using the Docker version of newt
>Reporter: Tim
>Assignee: Christopher Collins
>Priority: Minor
> Fix For: v1_0_0_beta1
>
>
> Basically, paste a few newt commands into a terminal, like this:
> newt target create nrf52_boot
> newt target set nrf52_boot app=@apache-mynewt-core/apps/boot
> newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> newt target set nrf52_boot build_profile=optimized
> My expected behaviour is that each one executes after the previous one has 
> finished. What actually happens is that  only the first commands execute. The 
> others don't do anything (not even an error).
> You can actually see this easier like this:
> newt target show
> newt target show
> vs
> newt target show && newt target show
> If I paste this it works as expected, so I'm not sure what newt does 
> differently (does it fork and run in the background or something weird?)
> sleep 1
> ls



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYNEWT-361) Consecutive commands not run in terminal

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15433631#comment-15433631
 ] 

Christopher Collins commented on MYNEWT-361:


I don't see this issue when using newt natively (not dockerized) on OS X 
10.11.5.  The below excerpt looks a bit odd because the bash prompt gets 
printed while the clipboard contents are being pasted:

{noformat}
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newt target create nrf52_boot
Target targets/nrf52_boot successfully created
newt target set nrf52_boot app=@apache-mynewt-core/apps/boot
newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
newt target set nrf52_boot 
build_profile=optimized[ccollins@ccollins-mac:~/repos/mynewt/core]$ newt target 
set nrf52_boot app=@apache-mynewt-core/apps/boot
Target targets/nrf52_boot successfully set target.app to 
@apache-mynewt-core/apps/boot
newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
newt target set nrf52_boot 
build_profile=optimized[ccollins@ccollins-mac:~/repos/mynewt/core]$ newt target 
set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
Target targets/nrf52_boot successfully set target.bsp to 
@apache-mynewt-core/hw/bsp/nrf52dk
newt target set nrf52_boot 
build_profile=optimized[ccollins@ccollins-mac:~/repos/mynewt/core]$ newt target 
set nrf52_boot build_profile=optimized
Target targets/nrf52_boot successfully set target.build_profile to optimized
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newt target show nrf52_boot
targets/nrf52_boot
app=@apache-mynewt-core/apps/boot
bsp=@apache-mynewt-core/hw/bsp/nrf52dk
build_profile=optimized
{noformat}

I'll see if I get the incorrect behavior in Ubuntu + docker.

> Consecutive commands not run in terminal
> 
>
> Key: MYNEWT-361
> URL: https://issues.apache.org/jira/browse/MYNEWT-361
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Affects Versions: v0_9_0
> Environment: Ubuntu 14.10 using the Docker version of newt
>Reporter: Tim
>    Assignee: Christopher Collins
>Priority: Minor
> Fix For: v1_0_0_beta1
>
>
> Basically, paste a few newt commands into a terminal, like this:
> newt target create nrf52_boot
> newt target set nrf52_boot app=@apache-mynewt-core/apps/boot
> newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> newt target set nrf52_boot build_profile=optimized
> My expected behaviour is that each one executes after the previous one has 
> finished. What actually happens is that  only the first commands execute. The 
> others don't do anything (not even an error).
> You can actually see this easier like this:
> newt target show
> newt target show
> vs
> newt target show && newt target show
> If I paste this it works as expected, so I'm not sure what newt does 
> differently (does it fork and run in the background or something weird?)
> sleep 1
> ls



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-294) BLE Host - Detect invalid service and characteristic descriptors

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-294.
--
Resolution: Fixed

> BLE Host - Detect invalid service and characteristic descriptors
> 
>
> Key: MYNEWT-294
> URL: https://issues.apache.org/jira/browse/MYNEWT-294
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-345) BLE Host - Reduce size of event buffers

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-345.
--
Resolution: Fixed

For combined-host-controller, the event buffer size has been reduced to 70 
(from 260).

> BLE Host - Reduce size of event buffers
> ---
>
> Key: MYNEWT-345
> URL: https://issues.apache.org/jira/browse/MYNEWT-345
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
>
> Currently, the size of each HCI event buffer is 260 bytes.  This is much 
> larger than necessary.
> The task is:
> 1. Determine the size of the largest event the controller will send.
> 2. Reduce the size of the HCI event buffers to the result from step 1.
> 3. (optional) Increase the default number of HCI event buffers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-348) BLE Host - Function to register mandatory services

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-348.
--
Resolution: Fixed

> BLE Host - Function to register mandatory services
> --
>
> Key: MYNEWT-348
> URL: https://issues.apache.org/jira/browse/MYNEWT-348
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
>
> Currently the app needs to register the mandatory services (GAP and GATT) 
> manually.  There should be a function which does this automatically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-350) BLE Host - Function to calculate required GATT server resources

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-350.
--
Resolution: Fixed

> BLE Host - Function to calculate required GATT server resources
> ---
>
> Key: MYNEWT-350
> URL: https://issues.apache.org/jira/browse/MYNEWT-350
> Project: Mynewt
>  Issue Type: New Feature
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
>
> Currently the developer has to guess how many attributes, services, etc. to 
> configure the host with.  Better would be if there were a function that took 
> an array of gatt service definitions and did the math itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-93) Host HCI implementation

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-93.
-
Resolution: Fixed

> Host HCI implementation
> ---
>
> Key: MYNEWT-93
> URL: https://issues.apache.org/jira/browse/MYNEWT-93
> Project: Mynewt
>  Issue Type: New Feature
>  Components: Nimble
>Affects Versions: v0_8_0_beta1
>Reporter: William San Filippo
>    Assignee: Christopher Collins
>  Labels: HCI, Host
> Fix For: v0_10_0
>
>
> In order to do a host only nimble stack we will need to implement the 
> (physical) HCI portion of the BLE specification.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)