Re: FCC Pre-scan

[Sterling Hughes]

Hi Jitesh,


On 9 Jun 2017, at 7:27, Jitesh Shah wrote:

> Great!
> So then ble_ll_reset() followed by ble_phy_disable() should take care of
> most cases, right?
>
> As far as giving back control to the nimBLE stack is concerned - that
> probably won't be necessary. FCC is a pretty controlled environment, so you
> could get away with manually resetting your device after every test.
>
> If all goes well, would you guys be interested in patches/mechanisms that
> help people with the FCC test?
>

That would be great!

Sterling

Re: segger jlink

[Sterling Hughes]

Well, I’m on mynewt.slack.com - if you care to be a guinea pig! :-)

Invite link here: 
https://join.slack.com/mynewt/shared_invite/MTkwMTg1ODM1NTg5LTE0OTYxNzQ4NzQtZTU1YmNhYjhkMg


Sterling

On 30 May 2017, at 13:22, Pierre Kircher wrote:


i dont mind using slack ..

a quick chat is just way faster to communicate and has a better flow 
then a mailing list


thats why i asked in the first place

pierre

On 30 May 2017, at 21:19, Sterling Hughes 
<sterling.hughes.pub...@gmail.com> wrote:


Hi Jacob,

I agree.  Some of the Mynewt core devs have an IRC culture, but most 
use less open, more ..friendly.. communications tools like Slack.


I’m looking up to see if there is a Slack->IRC gateway, which might 
make it easier.  Alternatively, what do folks think of just pointing 
people to Slack —> if it’s better attended by developers, is it 
too much of a hurdle even these days?


Sterling

On 30 May 2017, at 12:27, Jacob Rosenthal wrote:

The mailing list has been gracious to help me fix a bunch of stuff 
upstream

and taken my changes, and Ive really enjoyed the tooling on mynewt.

However, no offense to the mynewt core, but I would push back on the 
idea

you have a functioning IRC.

Ive been idling there for well over 6 months and have tried asking
questions there. Any questions there go unanswered, or are told to 
be taken

here.

Further in all that time the room has been absolutely silent because 
the
core team has literally no public discussion there. It would be nice 
to
hear that kind of core discussion that really doesnt happen here 
either...





On Tue, May 30, 2017 at 12:07 PM, aditi hilbert <ad...@runtime.io> 
wrote:


at exchange - and we would love it if you could contribute back to 
the
documentation (https://github.com/apache/incubator-mynewt-site, 
develop

branch) :)

Re: segger jlink

[Sterling Hughes]

Hi Jacob,

I agree.  Some of the Mynewt core devs have an IRC culture, but most use 
less open, more ..friendly.. communications tools like Slack.


I’m looking up to see if there is a Slack->IRC gateway, which might 
make it easier.  Alternatively, what do folks think of just pointing 
people to Slack —> if it’s better attended by developers, is it too 
much of a hurdle even these days?


Sterling

On 30 May 2017, at 12:27, Jacob Rosenthal wrote:

The mailing list has been gracious to help me fix a bunch of stuff 
upstream

and taken my changes, and Ive really enjoyed the tooling on mynewt.

However, no offense to the mynewt core, but I would push back on the 
idea

you have a functioning IRC.

Ive been idling there for well over 6 months and have tried asking
questions there. Any questions there go unanswered, or are told to be 
taken

here.

Further in all that time the room has been absolutely silent because 
the
core team has literally no public discussion there. It would be nice 
to
hear that kind of core discussion that really doesnt happen here 
either...





On Tue, May 30, 2017 at 12:07 PM, aditi hilbert  
wrote:


at exchange - and we would love it if you could contribute back to 
the
documentation (https://github.com/apache/incubator-mynewt-site, 
develop

branch) :)

Re: [VOTE] Graduation of podling Apache Mynewt to Top Level Project

[Sterling Hughes]

+1

On 26 May 2017, at 12:17, aditi hilbert wrote:


+1

This thread will be open until 6 PM PDT on May 30, 2017 (extra time 
because of Memorial Day).


thanks,
aditi



On May 25, 2017, at 5:55 PM, aditi hilbert <ad...@runtime.io> wrote:

Hi all,

We feel confident that we pass all the requirements to graduate.  
Below is the proposed Graduation Resolution (based on the standard 
template). A separate thread of DISCUSS is also open for this.


The full text of the proposed resolution is as follows:


The incubating Apache Mynewt community believes it is time to 
graduate to TLP.


Apache Mynewt entered incubation in October of 2015.  Since then, 
we've overcome technical challenges and built Apache's first 
Operating System for IoT devices, and made 6 releases.  Our most 
recent releases include NimBLE, OIC1.1 support, MCUbootloader. We are 
a very helpful and engaged community, ready to answer all questions 
and feedback directed to us via the user list.  We've added several 
committers from different organizations, and are actively pursuing 
others. While we continue working on maturity, all projects are 
ongoing processes, and we believe we no longer need the incubator to 
continue.


To inform the discussion, here is some basic project information:

Project status:
 http://incubator.apache.org/projects/Mynewt.html

Project website:
 http://Mynewt.incubator.apache.org/

Project documentation:
https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Project

Maturity assessment:
https://cwiki.apache.org/confluence/display/MYNEWT/Maturity+model

DRAFT of the board resolution is at the bottom of this email

Proposed PMC size: 20 members

Total number of committers: 20 members

Various PMC/Committer affiliations (* indicated chair)
  Runtime (6)
  Google (1)
  Imagination Technologies (1)
  Codecoup (4)
  Adafruit (1)

4,565 commits on develop
280 closed PR”s on GitHub
39 contributors across all branches
92 forks on Github

dev list averaged ~200 msgs/month in the last one year

647 issues created
465 issues resolved/closed

--
Resolution:

Establish the Apache Mynewt Project

WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software, for distribution at no charge to the
public, related to a data management platform that provides
real-time, consistent access to data-intensive applications
throughout widely distributed cloud architectures.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the "Apache Mynewt Project",
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache Mynewt Project be and hereby is
responsible for the creation and maintenance of software
related to an embedded OS optimized for networking and built for 
remote management of constrained devices that are incapable of 
running either Linux or Android.


RESOLVED, that the office of "Vice President, Apache Mynewt" be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache Mynewt Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Mynewt Project; and be it further

RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache Mynewt Project:
*Justin Mclean” <jmcl...@apache.org>
*P. Taylor Goetz” <ptgo...@apache.org>,
*Greg Stein <gst...@apache.org>,
*Jim Jagielski <j...@apache.org>,
*Sterling Hughes <sterl...@apache.org>,
*Marko Kiiskila <ma...@apache.org>,
*will sanfilippo <w...@apache.org>,
Christopher Collins <ccoll...@apache.org>,
Vipul Rahane <vipulrah...@apache.org>,
Fabio Utzig <ut...@apache.org>,
Andrzej Kaczmarek <a...@apache.org>,
Michał Narajowski <na...@apache.org>,
Szymon Janc <j...@apache.org>,
Łukasz Rymanowski <ry...@apache.org>,
Neel Natu <n...@apache.org>,
Peter Snyder <pete...@apache.org>,
Paul Dietrich <paulfdietr...@apache.org,
Julian Ingram <jul...@apache.org>,
Kevin Townsend <kt...@apache.org>,
Aditi Hilbert <ad...@apache.org>

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Justin Mcclean
be appointed to the office of Vice President, Apache Mynewt, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further

RESOLVED, that the initial Apache Mynewt PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased par

Re: Question about MyNewt FCC Certification

[Sterling Hughes]

Hi Lm,

At runtime we can offer commercial help with certification for Apache Mynewt - 
don't hesitate to reach out if you'd like some help!

Generally what I'd say is that it's up to you to decide whether or not you've 
made significant enough changes to the software on the device such that it 
requires recertification for FCC or Bluetooth SIG.  I would familiarize myself 
with the part 15 regulations, which do have a system operation (how long on 
channel, max transmit time, etc.) and make that judgement call for yourself.  

Sterling 

> On May 8, 2017, at 11:05 AM, Lm Chew  wrote:
> 
> Hi,
> 
> 
> I have some question regarding FCC Certification of device using MyNewt.
> 
> 
> Previously, We have have certified our device with Nordic FCC Certification.
> 
> 
> But now we like to migrate to MyNewt, but according to Nordic their FCC 
> certification does not cover others SDK, BLE stack, etc... So we must use 
> their SDK & Softdevice for the certification to be valid.
> 
> 
> Does MyMewt have it own FCC certification similar to those that are provided 
> by Nordic?
> 
> 
> Personally i am not very familiar with how FCC works.
> 
> Previously, i thought FCC only care radio about freq and power. (mhz and mw).
> 
> 
> Best Regards,
> 
> Chew

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

[Sterling Hughes]

Agree- but there should be some way of easily knowing whether called by boot 
loader or actual system.

Sterling

> On Apr 10, 2017, at 6:53 PM, will sanfilippo <wi...@runtime.io> wrote:
> 
> Thinking about this more… (which is almost never a good thing with me):
> 
> Cortex-M MCU manufacturers produce a file called system_.c (where xxx is 
> the name of the mcu). There is a function in that file called SystemInit. 
> Generally, this is something that should be called as early as possible and 
> is called in the startup code. What I am now considering doing is adding our 
> own version of “SystemInit” as I do not think it proper to modify the 
> system_xxx.c module unless absolutely necessary.
> 
> To be more concise:
> 
> * SystemInit() will still be called and will remain exactly the way it is now.
> * Add a function in hal_system.c (which is in hw/mcu) called 
> hal_system_init().
> * This function will be called by the startup code after SystemInit is called.
> * The configuration variable for DCDCEN will live in the MCU (default to 0) 
> and will be overridden by any BSP that can support it.
> 
> NOTE: I will comment on this in the hal_system_init() function, but this 
> function will be called by both the bootloader and the app. If there is a 
> case where doing something twice is undesirable that will have to be dealt 
> with by anyone adding code to hal_system_init().
> 
> Comments?
> 
>> On Apr 7, 2017, at 4:50 PM, Sterling Hughes 
>> <sterling.hughes.pub...@gmail.com> wrote:
>> 
>> Hi,
>> 
>> Couple of thoughts:
>> 
>> - I think this function/syscfg belongs in the MCU definition, as a 
>> configuration item that can be controlled by the BSP.
>> 
>> - I think it should be called as early as possible, so probably 
>> hal_bsp_init().
>> 
>> - It’s a bid odd that hal_bsp_init() is the same for bootloader and running 
>> image, we should probably have an option to make this different.  I’d lean 
>> to having more functionality in the image, because it’s upgradable.
>> 
>> Sterling
>> 
>>> On 7 Apr 2017, at 16:32, will sanfilippo wrote:
>>> 
>>> Hello:
>>> 
>>> I want to add some code that enables the DC/DC regulator for the nordic 
>>> chips. Enabling this regulator reduces power consumption (considerably). 
>>> For example, using the LDO when running from flash (cache enabled) is 
>>> typically 7.4mA; using the DC/DC regulator it goes to 3.7 mA.
>>> 
>>> It would be best to turn this on as soon as possible but it should only be 
>>> enabled if there is some external circuitry attached to some of the pins 
>>> (see the product specifications for more details). For all the BSP’s 
>>> currently in the repo, the DC/DC regulator can (and should) be enabled. 
>>> GIven that there is external circuitry involved I was going to create a 
>>> syscfg variable that would either exist in the BSP or be overridden by the 
>>> BSP. What I am having a bit of trouble figuring out is where should the 
>>> code to enable the DC/DC regulator go?
>>> 
>>> We have a choice of putting it in an existing place or doing something new. 
>>> It seems to me that if we choose an exisiting place it would go in either 
>>> hal_bsp_init() or hal_system_start().
>>> 
>>> Some comments about the existing functions:
>>> 
>>> hal_system_start():
>>> * Code would only need to be modified in one place (in hw/mcu).
>>> * This function is called after the bootloader does some work, so more 
>>> power savings could be realized earlier on.
>>> * If you build an image with no bootloader I do not think this is called.
>>> * It might be a bit of an odd place to put this code (enabled the DC/DC 
>>> regulator).
>>> 
>>> hal_bsp_init():
>>> * This is called early on by the bootloader. It is also called by the 
>>> application which is a bit confusing to me. I am not super familiar with 
>>> the bootloader but unless this function exists in some place I do not see 
>>> or we override bsp syscfg variables in the bootloader app, hal_bsp_init() 
>>> is going to do things twice. Is this true or am I missing something?
>>> * We would have to modify hal_bsp_init() in all the bsps.
>>> 
>>> Honestly, I am not too concerned about having to modify all the bsps that 
>>> use the nordic chip if the community thinks this code belongs in 
>>> hal_bsp_init().
>>> 
>>> Any comments/suggestions?
>>> 
>>> Thanks!
>>> 
>>> PS If we decide that this code should exist in hw/mcu what I would do is to 
>>> create a syscfg variable in hw/mcu/nordic (or hw/mcu/nordic/nrf52xxx and 
>>> hw/mcu/nordic/nrf51xxx) called MCU_DCDC_ENABLE (or some such). By default, 
>>> this will be 0. All the bsp syscfg.yml files will override this setting.
> 

Re: Use of os_error_t and OS_OK

[Sterling Hughes]

I don’t think we ever came to agreement, and things are a bit of a 
mishmash.  Ben brings up a good point.


Mynewt wide, in my view:

* os_error is a relic, and sys/defs codes should be used.

* All functions should return “int” and not “os_error_t” or a 
specific error type.


* 0 and -1 are SYS_EOK and SYS_EUNKNOWN (new value) respectively, and 
can be safely returned as numbers not defines.


* For other errors, the SYS_* equivalents should be returned.

Thoughts?

Sterling

On 10 Apr 2017, at 16:38, will sanfilippo wrote:


Not sure if anyone answered this. This is just my opinion of course:

* The OS functions should use return type os_error_t.
* Those functions should return OS_OK or some other OS error.
* Checks against functions with type os_error_t should be against 
OS_OK and not 0.


The bubbling up of errors, well, not sure. If some function not in the 
OS calls an os function which returns os_error_t does not need to use 
a return type of os_error_t; that can be int.



On Apr 9, 2017, at 7:55 PM, Ben Harper  
wrote:


While mucking about in the source I found a few places where the use 
of
OS_OK was either returned and checked against a hardcoded zero, or 
the
other way around, and some function signatures that give os_error_t 
or int
and return the other. The documentation has similar disconnects in 
portions
as to what the return type is, and some functions seem to bubble up 
the
response code from underlying system calls and the type changes as it 
is
returned.  I'd like to work through fixing these, but I'm not able to 
find
a single source of truth as to which they should be. Is there 
currently any
set guidance on this? Or would it be fine if I just made my best 
guesses

and brought it together as a PR against the github repository?

Thanks for any help you can give on the matter.
- Ben Harper

Re: mynewt, build on ubuntu

[Sterling Hughes]

I believe just making this -1 should also fix the problem for now (and 
we should update the code.). But I’ll let Chris chime in.  I’d 
change it to -1 for now.


Best,

Sterling

On 8 Apr 2017, at 12:58, Sterling Hughes wrote:

We just noticed this the other day, we have not tested on a 32-bit 
ubuntu vm, just the 64-bit vms, as all our stuff is 64-bit here.  
It’s a bug.


Can you try building newt with a 64-bit GOARCH? I think it’s 
GOARCH=amd64.


If you use a 64-bit ubuntu vm, that should work too.

sterling

On 8 Apr 2017, at 11:06, F Campos wrote:


Hi,
when building the mynewt on ubuntu I have an error on go builder:

*syscfg/syscfg.go:965: constant 4294967295 overflows int*

Seems that the SYSCFG_INTERRUPT_PRIO_MAX is too big for the variable 
"int"




*Linux Version:*
lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 14.04.4 LTS
Release: 14.04
Codename: trusty


*Go version:*
go version
go version go1.7 linux/386


Filipe

Re: mynewt, build on ubuntu

[Sterling Hughes]

We just noticed this the other day, we have not tested on a 32-bit 
ubuntu vm, just the 64-bit vms, as all our stuff is 64-bit here.  It’s 
a bug.


Can you try building newt with a 64-bit GOARCH? I think it’s 
GOARCH=amd64.


If you use a 64-bit ubuntu vm, that should work too.

sterling

On 8 Apr 2017, at 11:06, F Campos wrote:


Hi,
when building the mynewt on ubuntu I have an error on go builder:

*syscfg/syscfg.go:965: constant 4294967295 overflows int*

Seems that the SYSCFG_INTERRUPT_PRIO_MAX is too big for the variable 
"int"




*Linux Version:*
lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 14.04.4 LTS
Release: 14.04
Codename: trusty


*Go version:*
go version
go version go1.7 linux/386


Filipe

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

[Sterling Hughes]

Hi,

Couple of thoughts:

- I think this function/syscfg belongs in the MCU definition, as a 
configuration item that can be controlled by the BSP.


- I think it should be called as early as possible, so probably 
hal_bsp_init().


- It’s a bid odd that hal_bsp_init() is the same for bootloader and 
running image, we should probably have an option to make this different. 
 I’d lean to having more functionality in the image, because it’s 
upgradable.


Sterling

On 7 Apr 2017, at 16:32, will sanfilippo wrote:


Hello:

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


It would be best to turn this on as soon as possible but it should 
only be enabled if there is some external circuitry attached to some 
of the pins (see the product specifications for more details). For all 
the BSP’s currently in the repo, the DC/DC regulator can (and 
should) be enabled. GIven that there is external circuitry involved I 
was going to create a syscfg variable that would either exist in the 
BSP or be overridden by the BSP. What I am having a bit of trouble 
figuring out is where should the code to enable the DC/DC regulator 
go?


We have a choice of putting it in an existing place or doing something 
new. It seems to me that if we choose an exisiting place it would go 
in either hal_bsp_init() or hal_system_start().


Some comments about the existing functions:

hal_system_start():
* Code would only need to be modified in one place (in hw/mcu).
* This function is called after the bootloader does some work, so more 
power savings could be realized earlier on.
* If you build an image with no bootloader I do not think this is 
called.
* It might be a bit of an odd place to put this code (enabled the 
DC/DC regulator).


hal_bsp_init():
* This is called early on by the bootloader. It is also called by the 
application which is a bit confusing to me. I am not super familiar 
with the bootloader but unless this function exists in some place I do 
not see or we override bsp syscfg variables in the bootloader app, 
hal_bsp_init() is going to do things twice. Is this true or am I 
missing something?

* We would have to modify hal_bsp_init() in all the bsps.

Honestly, I am not too concerned about having to modify all the bsps 
that use the nordic chip if the community thinks this code belongs in 
hal_bsp_init().


Any comments/suggestions?

Thanks!

PS If we decide that this code should exist in hw/mcu what I would do 
is to create a syscfg variable in hw/mcu/nordic (or 
hw/mcu/nordic/nrf52xxx and hw/mcu/nordic/nrf51xxx) called 
MCU_DCDC_ENABLE (or some such). By default, this will be 0. All the 
bsp syscfg.yml files will override this setting.

Re: [apache/incubator-mynewt-core] PIC32 port (#218)

[Sterling Hughes]

Hi Julian,

On 31 Mar 2017, at 1:54, Julian Ingram wrote:


Hi Marko,

The Microchip license:

/*-
 *
 * Copyright (c) 2014, Microchip Technology Inc. and its subsidiaries 
("Microchip")

 * All rights reserved.
 * This software is developed by Microchip Technology Inc. and its
 * subsidiaries ("Microchip").
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions 
are

 * met:
 *
 * 1.  Redistributions of source code must retain the above 
copyright
 * notice, this list of conditions and the following 
disclaimer.

 * 2.  Redistributions in binary form must reproduce the above
 * copyright notice, this list of conditions and the following
 * disclaimer in the documentation and/or other materials 
provided

 * with the distribution.
 * 3.  Microchip's name may not be used to endorse or promote 
products

 * derived from this software without specific prior written
 * permission.
 *
 * THIS SOFTWARE IS PROVIDED BY MICROCHIP "AS IS" AND ANY EXPRESS OR 
IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES 
OF

 * MERCHANTABILITY AND FITNESS FOR PURPOSE ARE DISCLAIMED. IN NO EVENT
 * SHALL MICROCHIP BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
SPECIAL,

 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA OR 
PROFITS;
 * OR BUSINESS INTERRUPTION) HOWSOEVER CAUSED AND ON ANY THEORY OF 
LIABILITY,
 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE OR
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN 
IF

 * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 *-*/



This is BSD, this is perfectly OK.

The only other thing is the Microchip SDK is quite large (several GB), 
this being the case it might be worth making it a separate package. We 
would likely be dooming our users to having 2 copies of the SDK on 
their drives as the SDK is installed with the compiler when you 
download it so it might be worth picking out just the bits we need.




+1.  I think we should take what’s relevant to implement our HAL and 
include it in repo, and then ideally distribute the rest of the SDK as 
an external package.  If imgtech has a GitHub account they could host 
on, that would be ideal - otherwise we could also host as Runtime.


Best,

Sterling

Re: newt debug .img or elf?

[Sterling Hughes]

When running on a physical device you need the image version to load, for 
development we just use 0.0.0

Sterling 

> On Mar 29, 2017, at 7:45 AM, Kevin Townsend  wrote:
> 
> Was the build process recently updated to output .elf instead of .img?
> 
> I'm on 1.0.0 for everything (tools and core repo).
> 
> On OS X with GCC 5.4.1 (the latest release from ARM) I get:
> 
> *$ newt run bleuart*
> Compiling bin/targets/bleuart/generated/src/bleuart-sysinit-app.c
> Archiving bleuart-sysinit-app.a
> Linking 
> /Users/ktown/Dropbox/microBuilder/Code/nRF52/Mynewt/Adafruit_Mynewt/bin/targets/bleuart/app/apps/bleuart/bleuart.elf
> Loading app image into slot 1
> Error: Cannot find file 
> /Users/ktown/Dropbox/microBuilder/Code/nRF52/Mynewt/Adafruit_Mynewt/bin/targets/bleuart/app/apps/bleuart/bleuart.img
> 
> *$ ls bin/targets/bleuart/app/apps/bleuart/**
> *apps/   apps_bleuart.a.cmd  bleuart.elf.bin* bleuart.elf.lst 
> manifest.json
> apps_bleuart.a  bleuart.elf*bleuart.elf.cmd bleuart.elf.map
> 
> *$ arm-none-eabi-gcc --version**
> *arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 
> (release) [ARM/embedded-5-branch revision 240496]
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 

Re: Docker latest is still on newt version 1.0.0-b2

[Sterling Hughes]

There shouldn’t be an incompatible changes between b2 and rc1 — 
we’re actually looking at updating the newt in docker to b2 right now. 
 The release just passed incubator vote this weekend :)


On 20 Mar 2017, at 12:48, Simon Ratner wrote:


Hi devs,

Just did `docker pull mynewt/newt:latest` and looks like newt is still 
at
1.0.0-b2. Any plans to switch that over to rc1? Are there changes 
since b2

that may be incompatible with the rc1 core tree?

Cheers,
simon

Re: STM32F3 Discovery blinky tutorial error

[Sterling Hughes]

Hi Pradeep,

On 20 Mar 2017, at 6:07, Fabio Utzig wrote:


On Mon, Mar 20, 2017, at 09:09 AM, Pradeep Sanjeewa wrote:

Hi Fabio Utzig,

I thought MIPS port is already implemented.
Imagination Technologies ci40 board is already ported to mynewt which 
has

a
MIPS mcu.
Isn't it?

Correct me if I'm wrong.


Yes, there current supported MIPS CPU is a 24KEc family AFAIK, while 
the
PIC32 is a M4K. While being both MIPS there are the arch differences 
and

also being different manufacturers means different HAL. Using an ARM
analogy, it would be like getting the STM32F4 port and trying to run 
on

NRF51xx.



This is not to discourage you - we’d love someone else working on the 
PIC32 port as well.  Just a pointer that you might want to ping Julian 
Ingram, and see if you can share efforts with him on the port.


Cheers,

Sterling

Re: What is the different between drivers and hal module?

[Sterling Hughes]

Belongs in drivers IMO.  Cool!  Having a LCD driver would be awesome, 
and I’d love to get a GFX library into (or compatible with) Mynewt as 
well.


On 16 Mar 2017, at 6:47, Fabio Utzig wrote:

I believe the agreed on convention is that the "hal" directory 
contains
SOC drivers that are available on every supported MCU model. 
Everything

else should go to "drivers" (which would be the case for your LCD
driver).

On Thu, Mar 16, 2017, at 10:42 AM, Louie Lu wrote:

Hi everyone,

I'm now trying to make STM32F429 LCD work, the early stage video can 
saw

at:
https://www.youtube.com/watch?v=TIhjllDWWTI

How should I choose this code to put under drivers or hw/hal, is 
there

any
rules or convention to follow?

Thanks,
Louie.

Re: Newtmgr over BLE

[Sterling Hughes]

Hi Jacob,

Chris has been working on getting the Mynewt stack working in a cross 
platform way.  You can see some of his progress here:


* 
https://github.com/ccollins476ad/incubator-mynewt-core/tree/nativehost/apps/blehostd/src


* 
https://github.com/ccollins476ad/incubator-mynewt-newt/tree/nmxact/newtmgr


The idea is to use Mynewt’s sim architecture to run in a *nix process, 
and then speak HCI to whatever controller is running on the device.  
Newtmgr forks mynewt, and then communicates over a unix domain socket 
using JSON, and then drives the bluetooth stack.  I actually pinged 
Sandeep about this, because it should now work portably across Linux and 
Mac with the same Bluetooth host, no wacky kernel stuff necessary.


The caveat on Mac is that you need a controller (NRF* dongle for 
example), on Linux you can either run against a Mynewt controller or use 
HCI itself.


I think Chris is a week or two off on getting this ready - and I think 
it’s still TBD as whether this belongs in core, or as a separate 
project.  My vote would be to start with core, and then as it grows, 
potentially move it out of core.  But it is very nice to have the Mynewt 
stack running as a linux process — and fairly easy to map into other 
languages, because the interface is all JSON.


Best,

Sterling

On 7 Mar 2017, at 14:47, Jacob Rosenthal wrote:

Whats the internal thinking on this? Is it being discussed elsewhere? 
Is
the aforementioned rewrite going on, or delayed so it make sense for 
me to

try to get work on the xpc calls?

On Wed, Jan 25, 2017 at 1:07 PM, Jacob Rosenthal 


wrote:

The gatt dependency actually uses the xpc's reverse engineered by 
Sandeep

for noble github.com/sandeepmistry/noble (which I have some code on)
which has three separate xpc bindings for mavericks

yosemite

 and legacy


Now that the native apis are fairly stable and cover most of what the 
xpcs
have access to, I think even sandeep doesnt love having to redo the 
xpcs on
new os releases..But it takes very little to piggyback on the work 
hes
already done and modernize gatt's xpc handling if thats the only 
issue...






On Wed, Jan 25, 2017 at 12:10 PM, Jacob Rosenthal 

wrote:


ook at this app ...

Re: Unhandled interrupt (3) occurred when porting mynewt to other board

[Sterling Hughes]

Hi Louie,

Excellent!  We’d love the port when you’re done.

That usually means a crash of some type has occurred?  Can you attach a 
debugger, you should be able to see a stack trace (similarly - if you 
can get the console attached, it should *fingers-crossed* dump to 
console.)


Alternatively, mynewt can generate crash dumps which you can trigger and 
pull back, it’s been awhile since I looked at this, but hopefully 
somebody else on the list can give you instructions on generating cores 
on the STM32F* series.


Sterling

On 5 Mar 2017, at 18:38, Louie Lu wrote:


Hi everyone,

I'm now porting mynewt to STM32F429, and this board has the same MCU 
and

CPU with the board STM32F07 which mynewt have already supported.

I have now using blinky and slinky to verify the correctness of 
porting,

but encounter the problem that serial output "Unhandled interrupt (3)"
often, when MyNewt calling "os_time_delay" the second time, and 
sometime in

"log_reboot_pkg_init".

I'm not sure where do I doing wrong, do anyone has some clue or 
suggest

that I can do now?

Thanks,
Louie.

Changes to newt - and Fun with Jerryscript

[Sterling Hughes]

Howdy,

I thought I’d play around with getting Jerryscript up and running with 
Mynewt.


Generally, it was a painless endeavor, however, I needed to make a few 
changes to newt:


- If the src/ext directory of a SDK package doesn’t exist, ignore it 
when recursively processing includes.


- When processing includes, take the contents of “src_dirs” and also 
include them in the recursively include processing.


The changes I made to newt are here:

https://github.com/apache/incubator-mynewt-newt/compare/develop...sterlinghughes:develop?expand=1

However, I also ran into something else that has bothered us before.  
Specifically, I needed to do the following to the jerryscript source:


https://github.com/jerryscript-project/jerryscript/compare/master...sterlinghughes:master

Note the changes:

- Adding a pkg.yml and repository.yml — this worked surprisingly well! 
 Not much magick to get this up and running.  Although, given 
namespacing, I do wonder if we shouldn’t have newt look for these 
files in the base of the directory, but also search a directory 
“.newt” or “newt” in the base directory as well.


- And the awfulness: changes to jcontext/jcontext.c and jerry.c

Essentially, jcontext.c is a file that just declares global variables.  
Because this file doesn’t have any functions that are explicitly used, 
it gets dropped from the link.  By declaring a function that is empty, 
yet called in jerry.c things magically work.


I believe this is the same problem we saw with using linker sections in 
init before, and has to do with the fact that we compile packages into 
archive files instead of linking all the generated objects at the end of 
the build.  We had discussed in the past:


- Linking all generated objects together

- Leaving the archive files so we don’t lose things like newt size, 
which rely on them being generated to summarize size information


Thoughts?

Sterling

Re: ADC on Arduino Primo

[Sterling Hughes]

:-)

Definitely the battery service.  Unfortunately we can’t accept the 
nrf51-adc-driver, yet.  The Nordic SDK drivers it relies on are not 
(yet) BSD licensed.  I believe that Nordic was looking into this.  
We’d be happy to merge it into the runtime repository where we’re 
keeping the non-BSD nordic stuff:


https://github.com/runtimeinc/mynewt_nordic

The hope is to merge the repo into core once Nordic relicenses their 
SDK.


Sterling

On 28 Feb 2017, at 20:03, Jacob Rosenthal wrote:


This arrived today with b3be6f034169efaa53511b9da0905c4bba014608

and I updated both my nrf51 version of davids adc driver and my 
battery

service. I think its pretty clean and 'newty' Again, any code review
welcome, and if you think any of it fits in core I can PR

https://github.com/jacobrosenthal/mynewt-nrf51-adc-driver
https://github.com/jacobrosenthal/mynewt-nimble-services/
tree/master/services/battery

Thanks all!



On Mon, Feb 20, 2017 at 10:19 PM, Sterling Hughes <
sterling.hughes.pub...@gmail.com> wrote:


Hi Jacob,

This is awesome.

On 20 Feb 2017, at 14:35, Jacob Rosenthal wrote:

Thanks again David for your example. Ive taken liberally from there 
and put

together what seems like a working nrf51 driver. Any input accepted.
https://github.com/jacobrosenthal/mynewt-nrf51-adc-driver

and used it in a ble battery service, again any input happily 
accepted.

https://github.com/jacobrosenthal/mynewt-nimble-services/
tree/master/services/battery

Mynewt folks,

In the spirit of the driver model, It seems like I should be be able 
to

use
the os_dev_lookup function so both the adc driver and the battery 
service

can use the pkg.init functions so I dont have to do:

adc = adc_nrf51_driver_init();
rc = ble_svc_battery_init(adc);

But instead can pass the adc name "adc0" via mynewt variable, 
however

os_dev_lookup isnt in the header. Any objection to exposing that?


No problem with me, I have found this to be something that I have 
wanted
in a number of cases.  I’ve gotten around it by exposing and 
referencing a

global variable, but the function should work.

I think I was worried about locking constraints and exposing them 
when I
originally made it private.  We should put an admonition in the 
comments

that we don’t expect this to be locked, so caveat emptor.

I’d like to get this in prior to 1.0-rel if folks are OK with it.  
It is a

low-risk change to expose an existing function in a header file.

Sterling

Re: newt size improvements

[Sterling Hughes]

We do!

Sterling 

Sent from my iPhone

> On Feb 28, 2017, at 12:21 AM, Michał Narajowski 
>  wrote:
> 
> Hi Simon,
> 
> could you give us more info about your setup, so we can reproduce the
> problem? I don't think Mynewt supports Windows.
> 
> Michał
> 
> 2017-02-27 21:12 GMT+01:00 Szymon Janc :
> 
>> Hi Simon,
>> 
>>> On 27 February 2017 at 19:04, Simon Ratner  wrote:
>>> Clean was the first thing I tried too, didn't help. I am building from
>> the
>>> command line, but on Windows; perhaps it has something to do with path
>>> parsing in the map file?
>> 
>> Hmm I think we tested this only on Linux and Mac... will check it tomorrow
>> in the office.
>> 
>> --
>> pozdrawiam
>> Szymon K. Janc
>> 

Re: Having trouble, where to turn?

[Sterling Hughes]

This was thumb typing: I was going to say "with James pace, happy to help."  
But Aditi beat me to it: you are in good hands! ;-)

Sent from my iPhone

> On Feb 24, 2017, at 7:40 PM, Sterling Hughes 
> <sterling.hughes.pub...@gmail.com> wrote:
> 
> Hi tharon,
> 
> I work for runtime, 
> 
> Sent from my iPhone
> 
>> On Feb 24, 2017, at 7:15 PM, Tharon Hall <th...@cloud2gnd.com> wrote:
>> 
>> Hello,
>> 
>> 
>> 
>>  I am not a fan at all of mailing lists. Too much stuff in my inbox. My
>> boss asked me to evaluate mynewt, but I have hit brick walls. My newt build
>> crashed when I tried the Docker approach, and go install failed when I
>> tried a brand new 32-bit Ubuntu VM. Where can I turn for assistance? James
>> Pace originally reached out to me via LinkedIn, which is how I first heard
>> about mynewt.
>> 
>> 
>> 
>> Regards,
>> 
>> 
>> 
>> Tharon Hall
>> 
>> Senior Engineer
>> 
>> Cloud2GND Consulting
>> 
>> Louisville, KY

Re: ADC on Arduino Primo

[Sterling Hughes]

Hi Jacob,

This is awesome.

On 20 Feb 2017, at 14:35, Jacob Rosenthal wrote:

Thanks again David for your example. Ive taken liberally from there 
and put

together what seems like a working nrf51 driver. Any input accepted.
https://github.com/jacobrosenthal/mynewt-nrf51-adc-driver

and used it in a ble battery service, again any input happily 
accepted.

https://github.com/jacobrosenthal/mynewt-nimble-services/tree/master/services/battery

Mynewt folks,

In the spirit of the driver model, It seems like I should be be able 
to use
the os_dev_lookup function so both the adc driver and the battery 
service

can use the pkg.init functions so I dont have to do:

adc = adc_nrf51_driver_init();
rc = ble_svc_battery_init(adc);

But instead can pass the adc name "adc0" via mynewt variable, however
os_dev_lookup isnt in the header. Any objection to exposing that?



No problem with me, I have found this to be something that I have wanted 
in a number of cases.  I’ve gotten around it by exposing and 
referencing a global variable, but the function should work.


I think I was worried about locking constraints and exposing them when I 
originally made it private.  We should put an admonition in the comments 
that we don’t expect this to be locked, so caveat emptor.


I’d like to get this in prior to 1.0-rel if folks are OK with it.  It 
is a low-risk change to expose an existing function in a header file.


Sterling

Re: Script for merging PRs to Mynewt

[Sterling Hughes]

Bem Feito - Obrigado!

On 20 Feb 2017, at 13:43, Fabio Utzig wrote:

> Hi Sterling,
>
> Updated with some improvements:
>
> 1) Gets info from github API (original branch, message), requiring only
> the PR number as parameter
> 2) Checks out target local branch
> 3) Concats original message to log
> 4) Extra error checkings
>
> https://gist.github.com/utzig/e582bb2d4cc0128bb01ba5f4b7866711
>
> On Mon, Feb 20, 2017, at 01:22 PM, Sterling Hughes wrote:
>> Hi,
>>
>> For others who are merging PRs from GH, I wanted to share what I was
>> doing:
>>
>> #1 - I have setup the following remotes
>>
>> [~/dev/mynewt/core]$ git remote -v
>> github  https://github.com/apache/incubator-mynewt-core (fetch)
>> github  https://github.com/apache/incubator-mynewt-core (push)
>> origin  g...@github.com:sterlinghughes/incubator-mynewt-core.git (fetch)
>> origin  g...@github.com:sterlinghughes/incubator-mynewt-core.git (push)
>> upstream
>> https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core.git
>> (fetch)
>> upstream
>> https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core.git
>> (push)
>>
>> This contains my working clone (origin), the GitHub mirror (github) and
>> the ASF maintained git repo (upstream.)
>>
>> #2 - I work off origin for my commits and PRs
>>
>> #3 - To merge other people’s PRs, I have the following script:
>>
>> [~/dev/mynewt/core]$ more ~/dev/scripts/merge-pr
>> #!/bin/bash
>>
>> git fetch github pull/$1/head:$2
>> git merge --no-ff -m "This closes #$1" $2
>> git branch -D $2
>> git push upstream develop
>>
>>
>> Which is called like so:
>>
>> [~/dev/mynewt/core]$ merge-pr 178 harden-fs-checks
>>
>> And goes ahead and fetches the remote pull request, and pushes it to
>> upstream develop.  If you want to avoid automatic pushes, comment out
>> the git push upstream develop.
>>
>> Sterling

Script for merging PRs to Mynewt

[Sterling Hughes]

Hi,

For others who are merging PRs from GH, I wanted to share what I was 
doing:


#1 - I have setup the following remotes

[~/dev/mynewt/core]$ git remote -v
github  https://github.com/apache/incubator-mynewt-core (fetch)
github  https://github.com/apache/incubator-mynewt-core (push)
origin  g...@github.com:sterlinghughes/incubator-mynewt-core.git (fetch)
origin  g...@github.com:sterlinghughes/incubator-mynewt-core.git (push)
upstream	https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core.git 
(fetch)
upstream	https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core.git 
(push)


This contains my working clone (origin), the GitHub mirror (github) and 
the ASF maintained git repo (upstream.)


#2 - I work off origin for my commits and PRs

#3 - To merge other people’s PRs, I have the following script:

[~/dev/mynewt/core]$ more ~/dev/scripts/merge-pr
#!/bin/bash

git fetch github pull/$1/head:$2
git merge --no-ff -m "This closes #$1" $2
git branch -D $2
git push upstream develop


Which is called like so:

[~/dev/mynewt/core]$ merge-pr 178 harden-fs-checks

And goes ahead and fetches the remote pull request, and pushes it to 
upstream develop.  If you want to avoid automatic pushes, comment out 
the git push upstream develop.


Sterling

Re: [DISCUSS] [VOTE] Release Policy for Apache Mynewt

[Sterling Hughes]

Hi,

1. We might want to explicitly define the meaning of "releases that 
are still supported" (mentioned under Release Schedule); for 
instance, is it only the current major release, or one or two prior 
releases as well? The section on Backwards Compatibility talks about 
active and deprecated features at a more granular level, but not the 
definition of supported releases.




This may be different with each major release. For example, 1.1 may be 
supported but 1.2 might not (say there’s a horrible bug). I will add 
language about supported releases and when a release may not be 
supported.




I don’t think this should be arbitrary.  We need to have a consistent 
policy here, that addresses bug fixes and security fixes.  If there is a 
horrible bug, and it’s a supported release, we should issue a patch.


I think, at least for the next few releases, we want people to be 
following the release train pretty closely — so we shouldn’t 
maintain support for prior releases, except for security fixes, which 
should go 2 releases back.  Once we hit our first LTS release, we should 
review this policy.


Thoughts?

Sterling

serial library and termios

[Sterling Hughes]

Hey,

I’m looking at adding “serial” support to mynewt as a side 
project.


As I would typically see this architected, it would look like:

—
console | serial | pty
—
tty
—
uart

Where the tty support is below the console and serial port, and handles 
things like flow control and terminal ready.


Currently the architecture has tty in console_tty.c and flow control 
handling is left to the UART hal (RTS/CTS handshaking.).


I think the UART HAL should handle RTS/CTS handshaking, but I’m 
wondering if we shouldn’t move to an architecture where we have a 
package, sys/tty which maintains the ring buffer, along with terminal 
settings (DTR/DCD).


The other alternative is to just re-implement that directly in a 
serial_* library, which seems fine to me as well.  Our console doesn’t 
exactly need to run on top of complex TTYs.


Thoughts?

Sterling

Re: Can't build blinky app on macOS Sierra

[Sterling Hughes]

Yup, unfortunately nothing for that.

Mac makes you code sign gdb when running sim.  If you run on physical 
hardware, you don’t need to codesign the binary.


Sterling

On 9 Feb 2017, at 20:50, Denis Magda wrote:


Hi Marko,


cd $GOPATH/src/newt/mynewt.apache.org/newt
git checkout mynewt_1_0_0_b2_rc1_tag
cd newt
go build; go install


This did the trick, thanks!

However, I managed to run the demo only under the root user (sudo newt 
run my_blinky_sim). The other option was to codesign the gdb.


Otherwise, I got the exception below. Please update “Run the 
Project” section of the getting started guide putting a note 
regarding this possible issue.



Deniss-MBP:test dmagda$ newt run my_blinky_sim
Loading app image into slot 1
[/Users/dmagda/dev/test/test/repos/apache-mynewt-core/hw/bsp/native/native_debug.sh 
/Users/dmagda/dev/test/test/repos/apache-mynewt-core/hw/bsp/native 
/Users/dmagda/dev/test/test/bin/targets/my_blinky_sim/app/apps/blinky/blinky]
Debugging 
/Users/dmagda/dev/test/test/bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf

GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin16.3.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/Users/dmagda/dev/test/test/bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf...Reading 
symbols from 
/Users/dmagda/dev/test/test/bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf.dSYM/Contents/Resources/DWARF/blinky.elf...done.

done.
(gdb) r
Starting program: 
/Users/dmagda/dev/test/test/bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf
Unable to find Mach task port for process-id 35941: (os/kern) failure 
(0x5).

 (please check gdb is codesigned - see taskgated(8))
(gdb)

—
Denis


On Feb 9, 2017, at 6:58 PM, marko kiiskila  wrote:

Hi Denis,

I think Chris meant output of ‘newt -ldebug build my_blinky_sim’

What looks confusing is the the contents of build_log.rtf.
It looks as if the file in question was getting processed twice:
First with gcc-6, and then with clang. And it’s the second 
invocation that’s

causing this error.

Obviously, only the first step should take place. So there’s 
possibly

something funky going on with newt. But I don’t know what could
cause this kind of error. Can you double-check the go version
you’re using?

Also, could you try with the latest beta2 (close to being released)?

cd $GOPATH/src/newt/mynewt.apache.org/newt
git checkout mynewt_1_0_0_b2_rc1_tag
cd newt
go build; go install

And then go through the project creation part again.



On Feb 9, 2017, at 5:40 PM, Denis Magda  wrote:

Hi Chris,

Please find requested data attached here:
https://drive.google.com/open?id=0B0qn42TRMz5EV1JobzBqM1loa3c 



As for “-ldebug” it has no effect for me. Tried to add it to 
many parameters from compiler.yml with no success.
However, “-v” command generated verbose output at the time the 
compilation of the assembly file failed.


—
Denis


On Feb 9, 2017, at 8:48 AM, Christopher Collins 
 wrote:


Hi Denis,

On Wed, Feb 08, 2017 at 09:39:10PM -0800, Denis Magda wrote:

Hello Mynewt community,

I tried to play with your product strictly following the getting 
started guide [1] but can’t compile the default blinky app


Deniss-MBP:test dmagda$ newt build my_blinky_sim
Building target targets/my_blinky_sim
Assembling os_arch_stack_frame.s
Error: os_arch_stack_frame.s:34:17: error: unexpected token in 
directive

 .globl CNAME(os_arch_frame_init)
 ^
os_arch_stack_frame.s:39:26: error: unexpected token in argument 
list

CNAME(os_arch_frame_init):
  ^
os_arch_stack_frame.s:84:19: error: unexpected token in memory 
operand

 callCNAME(sigsetjmp)/* sigsetjmp(sf->sf_jb, 0) */
   ^
os_arch_stack_frame.s:98:19: error: unexpected token in memory 
operand
 callCNAME(os_arch_task_start) /* os_arch_task_start(sf, rc) 
*/


Hmm, that's odd.  I don't have any theories, but I'll look into it.
Could you please post the following:

* Contents of compiler/sim/compiler.yml
* Output of "gcc-6 -v" (or whatever your gcc binary is called)

Another option that could be helpful is to try building with the
"-ldebug" command line switch.  This will enable a lot of debug 
output,

including the actual command used to assemble that .s file.

Thanks,

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

[Sterling Hughes]

+1 from me

On 8 Feb 2017, at 13:22, Szymon Janc wrote:


Hi Chris,

On 8 February 2017 at 19:58, Christopher Collins  
wrote:

On Wed, Feb 08, 2017 at 08:49:26AM -0800, Christopher Collins wrote:

I don't have any hardware available at the moment, but I will try
running this on a board in a little bit to see if I have the same 
issue.
This worked for me when I tried it a week or two ago, so yeah, 
plenty of

time for a bug to creep in :).


Just to follow up - I ran blesplit as a split image on the nrf52dk, 
and

didn't see any issues.


Yeap, it builds just fine when I added loader

+1 from me

--
pozdrawiam
Szymon K. Janc

Re: [SensorAPI] Few Questions wrt Sensors

[Sterling Hughes]

Hi Kevin,

On 3 Feb 2017, at 23:43, Kevin Townsend wrote:


Hi Vipul,


On 04/02/17 01:08, Vipul Rahane wrote:

Hello All,

I will be taking over SensorAPI stuff from Sterling.

Kevin:
TSL2561 Driver and LSM303 Driver that you have implemented are pretty 
good and I used both of them. I saw the values coming in using the 
SensorAPI. I would also like to understand about sensors from you or 
anybody else that is more experienced on these as I am kind of new to 
it, I have some experience but not a lot to get a generic 
understanding.
Happy to help where I can on my side. I'm currently on vacation, but 
can look into this more seriously when I'm back next week.


Don’t take too much time away from the beach, it can wait. :-).



* Zero-g level offset (TyOff) is the standard deviation of the actual 
output signal of a sensor from the ideal output signal. Should we be 
thinking of calibration for sensors in the SensorAPI ? I think in 
this case it comes with factory calibrated values which can be used 
by a developer. But that will change once put on a PCB, hence the 
concern.
For orientation you will ALWAYS needs to calibrate the sensors to get 
meaningful data (especially the mag, but also the gyro for the 
zero-offset level), and this will always have to be done in the final 
enclosure and environment. So yes, we should have functions to store 
and apply calibration coefficients for the accel/mag/gyro data types 
(plus perhaps some other sensors types, but definately those three). I 
think these should be stored in config memory somewhere, but we need 
helper functions to assign and apply them and just default to '0' 
values.


++1.  I think having well-defined tables to store this calibration, and 
helper functions to write and inspect it are incredibly important.  You 
don’t want everybody doing their own cal tables.  We may not be able 
to fully model every sensor, even within a type, but I think we can at 
least provide the framework for storing & updating calibration data 
(e.g. write-protect, overrideable sections, read and write formats over 
console.)


* Operating mode of Sensors. Low Power mode Vs Normal Mode for 
Accelerometer and Sleep Mode Vs Single Conversion Mode Vs Continuous 
Conversion Mode. Modes should also be a part of our SensorAPI I 
believe.
I think having built in power mode control at the API level is 
extremely value (and often neglected), but I think you want to keep 
things manageable as well so this might be pushed off to a second 
version? I do think we should keep power mode in mind with any API 
level decisions though. Sterling has some thoughts on this a while 
back and made an initial proposal that I found very sensible.


We should probably take this to a separate thread, when we get to it.  I 
remember thinking that most of what was there in the driver framework 
could be leveraged, but it would be good discuss all the various 
scenarios (e.g. interrupt driven, polled) and ensure it ties together.  
I think a lot of the logic here you want at the driver level, and not in 
the sensor API, the sensor API just needs to ensure that operates in 
such a way that it allows the driver control (which it does currently.)



*  Should the Filter mode selection also be part of the SensorAPI ?
I think this should be a separate API, but also a key part of any 
system using sensor data. The key thing is to support compatible types 
between the sensor and filter APIs. float32 would be my lowest common 
denominator, especially since the Cortex M4F has excellent float32 
performance (13 cycle divide, 3 cycle multiply off the top of my head 
... which is also as good or better than fixed point), although 
int32_t is nice as a fallback. Float32 will be more painful on an M0, 
but I think most orientation systems will probably be implement on an 
M4F which has a lot more processing power per MHz for this kind of 
work.


Agreed.



So far it looks like the SensorAPI does a great job apart from the 
above stuff.
I liked what is there so far. There are some gaps to fill in 
(DSP/Filtering, making composite sensor types like 'orientation' based 
on lower level raw sensor data, etc.), but it's very nice so far and 
moving things in a good, sustainable direction in my opinion!




+1 on all suggestions - esp. DSP/Filtering.

Sterling

Re: [jira] [Created] (MYNEWT-576) Update apps that use newtmgr framework to explicitly set the event queue with mgmt

[Sterling Hughes]

These should default to the default event queue, no?

> On Jan 27, 2017, at 6:27 PM, Wanda Chiu (JIRA) <j...@apache.org> wrote:
> 
> Wanda Chiu created MYNEWT-576:
> -
> 
> Summary: Update apps that use newtmgr framework to explicitly set 
> the event queue with mgmt 
> Key: MYNEWT-576
> URL: https://issues.apache.org/jira/browse/MYNEWT-576
> Project: Mynewt
>  Issue Type: Bug
>  Components: Misc
>Affects Versions: v1_0_0_beta1
>Reporter: Wanda Chiu
>Assignee: Sterling Hughes
>Priority: Trivial
> Fix For: v1_0_0_rel
> 
> 
> The tutorial to enable Newt Manager in Any App indicates that the app must 
> call the mgmt_evq_set to specify the event queue that mgmt uses to receive 
> newtmgr request events. We need to update the apps that use the newtmgr 
> framework to make this call. 
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

Re: newNewt

[Sterling Hughes]

Hi Neil,

Sounds like a fun project!

I’ll let Marko or the Linaro folks chime in on the K64F, however, I 
wanted to point to the excellent article the code coup guys wrote on 
running Mynewt with Eclipse:


https://www.codecoup.pl/blog/hacking-mynewt-in-eclipse/

Sterling

On 25 Jan 2017, at 12:36, Neilh wrote:


Hi

 I'm liking the myNewt direction and thanks for the explanations, wiki 
and

videos.

I've got a Nxp/Freescale Kinetis custom board with a MK26
(flash1M/ram200k 2*otg) KinetisK  that is similar to MK64F on 
FRDM-MK64F


I have a FRDM-MK64F board and also an olimex-H407 (same processor as 
olimex-E407 but no Ethernet).


I have the newt tools brought into an Ubuntu 16.04 and run the 
sim_blinkey


I was thinking of getting started with trying to bring up the 
FRDM-K64F,

thought that is marked as untested so far.   It does have the USB/SDA
loader.
myproj\repos\apache-mynewt-core\hw\bsp\frdm-k64f\src  seems to have 
the

basics.

Alternatively, I could familiarize myself work through the Olimex-E407

My  environment so far has been IDE Freescale Kinetis Design
Studio/Eclipse building nuttx OS, and with integration to Multilink 
JTAG

for blowing the flash.

There was a new feature request for an Eclipse plugin for myNewt, but 
it was marked as dup, and I haven't seen any other mention of Eclipse 
IDE so

far.

Any recommendation on getting started with FRDM-K64F?   or should I
start with Olimex

thanks


--
Neil Hancock

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

[Sterling Hughes]

On 23 Jan 2017, at 23:41, Greg Stein wrote:


commit 1 of 50 ??

This says to me: push more often. How can the mynewt community review 
your

work, if you never push it?



:-) as pointed out, it’s bringing the sensors_branch up to date: Vipul 
has started working on it, and I brought it up to develop so he 
wouldn’t have to learn a new code base, and all the changes in develop 
simultaneously.   I’ve been working on a long running branch, as I 
don’t want this to make rel, but rather after-rel.


That said, I’d like to use this opportunity to ask for remedial git 
lessons. :-)   I have found that when I merge from develop->my_branch, I 
often see merge conflicts in files I haven’t even touched.  I go 
through, like a good git monkey and manually resolve the conflicts, but 
it makes me feel like I’m doing something wrong.  As an example, this 
time I had a ton of merge conflicts in OIC and CBOR: neither of which 
I’d touched on my branch.


When I merge, I often do either:

$ git checkout 
$ git fetch origin develop
$ git merge

Or

$ git checkout 
$ git pull origin develop

Then resolve conflicts.

Is this right?  What should I do when I see a whole bunch of merge 
conflicts in files I haven’t touched?


Sterling

Docker container

[Sterling Hughes]

Hey,

I’ve been noticing a bunch of issues cropping up recently with our 
Docker container, that seem to center around unusable speed of 
compilation.  I’m wondering if there is a way to speed this up?


If we can’t speed up docker-container based compilation: I think we 
need to de-emphasize it, and remove it as the first and recommended 
installation option for our toolchain.  Perhaps provide a very big 
warning about compilation speed and put the instructions on a Wiki page 
and point to them from docs, but don’t include it in official docs?


I’d be interested in other opinions, especially those of Windows 
users.  Are their any newt-Docker-Windows-devotees out there? :-)


Sterling

Re: State of 1.0.0 beta/rc, develop branch

[Sterling Hughes]

Hi Simon,

IMO we’re probably going to roll b2 off develop.  There have been a 
fair number of stability improvements.  While its a fairly large scope 
of change between betas, its probably the right decision.  Prior to b2, 
either this week or next, we should create a 1.0 branch that b2 is 
tagged off of.  From that point on, we should only be merging bug fixes 
into that branch.


I don’t know how others feel, but my goal is to have b2 out end of 
January, and then roll a final 1.0 mid/by end of February.


Best,

Sterling

On 10 Jan 2017, at 14:42, Simon Ratner wrote:


Hi devs,

Just wanted to ask for a quick summary of where the code is going. I 
see

that 1.0.0-b1 was tagged at Nov 29th; is that basically frozen for the
1.0.0 release in terms of compatibility, or will the code currently on
develop make it into subsequent 1.0.0 beta/rc releases?

If not, is it targeted for 1.1 or similar future release?

Cheers
simon

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

[Sterling Hughes]

Hi Jiacheng,

You need to update your newt tool along with the new develop.

Best,

Sterling

On 10 Jan 2017, at 16:46, WangJiacheng wrote:


Hi, Will,

I need more help, I have an error message when compile the target.

I’m currently working on the release branch, so upgrade to dev 
branch by:
1. change file project.yml from "vers: 0-latest” to "vers: 
0-dev”

2. upgrade to dev branch “newt upgrade”

Then compile the target by “newt build nrf52_boot”, an error 
message as:


Building target targets/nrf52_boot
Compiling boot.c
Archiving boot.a
Compiling bootutil_misc.c
Compiling image_ec.c
Compiling image_ec256.c
Compiling image_rsa.c
Compiling image_validate.c
Compiling loader.c
Archiving bootutil.a
Error: In file included from aes.c:29:0:
/Users/jiachengwang/dev/myproj/repos/apache-mynewt-core/crypto/mbedtls/include/mbedtls/config.h:2522:10: 
error: #include expects "FILENAME" or 

 #include MBEDTLS_USER_CONFIG_FILE
  ^

it seems the config file "mbedtls/config_mynewt.h” define in 
“crypto/mbedtls/pkg.yml” is missed.


Thanks,

Jiacheng





在 2017年1月10日，11:06，WangJiacheng 
 写道：


Thanks, Will.

There is an Internet connection issue to GitHub.com currently, I’ll 
update the code later.


Best Regards,

Jiacheng


在 2017年1月10日，10:10，will sanfilippo  
写道：


Hello:

This issue should now be fixed in the latest development branch. 
Note that this is not working on the nrf51 platforms but since you 
were using nrf52 it should work.


Let me know if you see any issues with it.


On Jan 8, 2017, at 6:20 PM, WangJiacheng  
wrote:


Hi, Will,

Thanks a lot for your reply.

Yes，the hardwear processor clock frequency of nRF52 (Cortex M4F) 
is 64 MHz and can not be changed.


The reason of changing CLOCK_FREQ is that I want re-use the 
internal timing of mynewt already there with more accurate timing, 
by calling function "os_cputime_get32()”.  I’m trying to 
implement a (soft) IC card reader by nRF52 with mynewt OS and 
nimble stack running.


I am also considering to use an independent timer (NRF_TIMER3 or  
NRF_TIMER4) at the cost of about 0.1mA current. I already use 
NRF_TIMER2 to provide a 4 MHz clock signal output from GPIO of 
nRF52. By reading the source code of apache-mynewt-core, my 
understanding is that NRF_TIMER0 and NRF_TIMER1 is already used by 
mynewt OS and nimble stack, is my understanding correct?


Thanks,

Jiacheng

在 2017年1月9日，01:10，will sanfilippo  
写道：


Those should be the only two parameters you need to configure. 
Must be a bug in the controller :-)


I think it is worthwhile to point out that CLOCK_FREQ only changes 
the units of os cputime; it does not affect the speed at which the 
processor runs. At least, I could not see any other uses of 
CLOCK_FREQ. So, these settings only affect the nimble stack and 
the controller specifically (internal controller timing).


I am curious why you wanted to change this variable; what were you 
trying to achieve?


Thanks for pointing this out; I will take a look to see why it is 
not working.


On Jan 7, 2017, at 10:48 PM, WangJiacheng 
 wrote:


Hi,

The default CPU time frequency of Mynewt OS and Nimble stack is 1 
MHz, I try to change the CPU time frequency to be 2 MHz, I 
modified the related 2 config files:

configure file “hw/bsp/nrf52dk/syscfg.yml” as
CLOCK_FREQ:
   description: 'TBD'
   value:  200
configure file “kernel/os/syscfg.yml” as
OS_CPUTIME_FREQ:
   description: 'Frequency of os cputime'
   value: 200

The app “bleperiph" is running and the CPU time frequency is 2 
MHz, also the BLE “nimble-bleprph” peripheral  can be scanned 
by LightBlue of iOS APP, and show 1 service is there. However, 
when I try to connect it ,an error massage “Connection Alert: 
Timeout interrogating the peripheral”


When change back above 2 syscfg parameters to 100, it can be 
connected.


And app “bletiny” is the same.

Is there any  missed config setting in my test? How to change the 
CPU time frequency to 2 Mhz and Nimble device can be connected?


Thanks,

Jiacheng

Re: macOS Sierra Support

[Sterling Hughes]

don’t do brew update/brew upgrade (or maybe use homebrew. :-)

On 10 Jan 2017, at 9:53, David G. Simmons wrote:


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

...
DSimmons-Pro:apache-mynewt-core dsimmons$ gdb --version
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin15.5.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
DSimmons-Pro:apache-mynewt-core dsimmons$


MacOS Sierra v10.12.2 (16C67)

dg
On Jan 10, 2017, at 12:45 PM, Sterling Hughes <sterl...@apache.org> 
wrote:


Hi,

On the latest develop with the latest macOS Sierra and homebrew, If I 
have a target:


targets/slim_slinky
   app=apps/slinky
   bsp=hw/bsp/native
   build_profile=debug

(used to be optimized :-)

And I try and build:

$ newt run slim_slinky
Error: In file included from 
/usr/local/Cellar/gcc5/5.4.0/lib/gcc/5/gcc/x86_64-apple-darwin15.0.0/5.4.0/include-fixed/syslimits.h:7:0,
from 
/usr/local/Cellar/gcc5/5.4.0/lib/gcc/5/gcc/x86_64-apple-darwin15.0.0/5.4.0/include-fixed/limits.h:34,

from encoding/tinycbor/include/tinycbor/cbor.h:29,
from mgmt/newtmgr/include/newtmgr/newtmgr.h:23,
from apps/slinky/src/main.c:37:
/usr/local/Cellar/gcc5/5.4.0/lib/gcc/5/gcc/x86_64-apple-darwin15.0.0/5.4.0/include-fixed/limits.h:168:61: 
error: no include path in which to search for limits.h


I get beyond this by compiling out gcc-5, and instead using the 
native Mac LLVM compiler (fixes in dev to make the system work with 
that).  However, the next issue is gdb:


$ newt run slim_slinky

[/Users/sterling/dev/mynewt/core/hw/bsp/native/native_debug.sh 
/Users/sterling/dev/mynewt/core/hw/bsp/native 
/Users/sterling/dev/mynewt/core/bin/targets/slim_slinky/app/apps/slinky/slinky]
Debugging 
/Users/sterling/dev/mynewt/core/bin/targets/slim_slinky/app/apps/slinky/slinky.elf


Reading symbols from 
/Users/sterling/dev/mynewt/core/bin/targets/slim_slinky/app/apps/slinky/slinky.elf...done.

(gdb) c
The program is not being run.
(gdb) r
Starting program: 
/Users/sterling/dev/mynewt/core/bin/targets/slim_slinky/app/apps/slinky/slinky.elf

During startup program terminated with signal ?, Unknown signal.
(gdb)

If I switch to using llvm debugger, I can debug the system.  Which is 
fine, but I do generally prefer gdb due to familiarity.  Still, for 
those searching for a quick solution, lldb is fine.


Has anyone had success making these work on the latest macOS sierra.  
My toolchain information:


$ gdb --version
GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin15.6.0".
$ gcc-5 --version
gcc-5 (Homebrew gcc5 5.4.0) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There 
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


Attached is a patch that made things work with llvm.

Sterling


--
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.

macOS Sierra Support

[Sterling Hughes]

Hi,

On the latest develop with the latest macOS Sierra and homebrew, If I 
have a target:


targets/slim_slinky
app=apps/slinky
bsp=hw/bsp/native
build_profile=debug

(used to be optimized :-)

And I try and build:

$ newt run slim_slinky
Error: In file included from 
/usr/local/Cellar/gcc5/5.4.0/lib/gcc/5/gcc/x86_64-apple-darwin15.0.0/5.4.0/include-fixed/syslimits.h:7:0,
 from 
/usr/local/Cellar/gcc5/5.4.0/lib/gcc/5/gcc/x86_64-apple-darwin15.0.0/5.4.0/include-fixed/limits.h:34,

 from encoding/tinycbor/include/tinycbor/cbor.h:29,
 from mgmt/newtmgr/include/newtmgr/newtmgr.h:23,
 from apps/slinky/src/main.c:37:
/usr/local/Cellar/gcc5/5.4.0/lib/gcc/5/gcc/x86_64-apple-darwin15.0.0/5.4.0/include-fixed/limits.h:168:61: 
error: no include path in which to search for limits.h


I get beyond this by compiling out gcc-5, and instead using the native 
Mac LLVM compiler (fixes in dev to make the system work with that).  
However, the next issue is gdb:


$ newt run slim_slinky

[/Users/sterling/dev/mynewt/core/hw/bsp/native/native_debug.sh 
/Users/sterling/dev/mynewt/core/hw/bsp/native 
/Users/sterling/dev/mynewt/core/bin/targets/slim_slinky/app/apps/slinky/slinky]
Debugging 
/Users/sterling/dev/mynewt/core/bin/targets/slim_slinky/app/apps/slinky/slinky.elf


Reading symbols from 
/Users/sterling/dev/mynewt/core/bin/targets/slim_slinky/app/apps/slinky/slinky.elf...done.

(gdb) c
The program is not being run.
(gdb) r
Starting program: 
/Users/sterling/dev/mynewt/core/bin/targets/slim_slinky/app/apps/slinky/slinky.elf

During startup program terminated with signal ?, Unknown signal.
(gdb)

If I switch to using llvm debugger, I can debug the system.  Which is 
fine, but I do generally prefer gdb due to familiarity.  Still, for 
those searching for a quick solution, lldb is fine.


Has anyone had success making these work on the latest macOS sierra.  My 
toolchain information:


$ gdb --version
GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin15.6.0".
$ gcc-5 --version
gcc-5 (Homebrew gcc5 5.4.0) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


Attached is a patch that made things work with llvm.

Sterlingdiff --git a/compiler/sim/compiler.yml b/compiler/sim/compiler.yml
index 1fddf4b..057b523 100644
--- a/compiler/sim/compiler.yml
+++ b/compiler/sim/compiler.yml
@@ -41,8 +41,8 @@ compiler.flags.base.LINUX: >
 compiler.ld.flags.LINUX: -lutil
 
 # OS X.
-compiler.path.cc.DARWIN.OVERWRITE: "/usr/local/bin/gcc-5"
-compiler.path.as.DARWIN.OVERWRITE: "/usr/local/bin/gcc-5"
+#compiler.path.cc.DARWIN.OVERWRITE: "/usr/local/bin/gcc-5"
+#compiler.path.as.DARWIN.OVERWRITE: "/usr/local/bin/gcc-5"
 compiler.path.objdump.DARWIN.OVERWRITE: "gobjdump"
 compiler.path.objcopy.DARWIN.OVERWRITE: "gobjcopy"
 compiler.flags.base.DARWIN: >
diff --git a/hw/bsp/native/native_debug.sh b/hw/bsp/native/native_debug.sh
index f412408..cd69811 100755
--- a/hw/bsp/native/native_debug.sh
+++ b/hw/bsp/native/native_debug.sh
@@ -40,4 +40,5 @@ FILE_NAME=$BIN_BASENAME.elf
 
 echo "Debugging" $FILE_NAME
 
-gdb -x $GDB_SCRIPT_PATH $FILE_NAME
+#gdb -x $GDB_SCRIPT_PATH $FILE_NAME
+lldb $FILE_NAME

Re: Compile and build time, any way to speed up?

[Sterling Hughes]

This is awesome, timing on the new build (after a clean):

Target successfully built: targets/nrf52

real0m6.327s
user0m26.972s
sys 0m9.276s
$ newt target show nrf52
targets/nrf52
app=apps/slinky
bsp=hw/bsp/nrf52dk
build_profile=debug

6 seconds for a full build.  Not bad!

Sterling

On 5 Jan 2017, at 11:57, Christopher Collins wrote:


On Thu, Jan 05, 2017 at 09:00:11AM -0500, Cris Frusina wrote:

Hi David,

Sounds like a pain!

So I got an Ubuntu VM running on the Windows machine and installed 
the myNewt natively. I didn't really see much of a speed bump (needs 
a bit further testing). I'll try a different computer later today. 
Worst case I'll find a Mac to try it on.


Just an note - I ended up adding multithreaded build support to newt
yesterday.  In the develop branch, you can enable it with the
"-j " command line option, e.g.,

newt -j 5 build my_blinky_sim

A word of warning, though: don't upgrade your newt to develop if you
are using Mynewt 1.0-b1 and aren't prepared to upgrade that as well.
Since the 1.0-b1 release, some backwards-compatible changes were made 
to

the newt tool.

Thanks,
Chris

Re: Sensor API Helper Functions

[Sterling Hughes]

Hi Kevin,

On 23 Dec 2016, at 15:26, Kevin Townsend wrote:

I'm probably getting ahead of myself diving into this before the 
sensor API is nailed down, but if we wanted to add some generic helper 
functions that make use of the sensor API, what would be a good 
location or what to organize them as a package? It isn't always easy 
to organize things like this by sensor type since there is a lot of 
overlap.




Well, certainly ahead of me.  I’m just looking at this stuff now, 
sorry about that.


Comments inline, as I think some of it belongs in the sensor interface, 
some is probably better a separate package.


I can think of two helper packages we might want to add as a core test 
case, that are useful for testing and getting actionable, useful 
output from the sensor API:


ORIENTATION

Using only an accelerometer you can get rough roll/pitch values: 
https://github.com/microbuilder/LPC11U_LPC13U_CodeBase/blob/development/src/drivers/sensors/accelerometers/accelerometers.c#L81


If you add a magnetometer you can get rough roll/pitch/heading values: 
https://github.com/microbuilder/LPC11U_LPC13U_CodeBase/blob/development/src/drivers/sensors/sensorfusion.c#L78


If you add a gyroscope, you can do proper 9DOF sensor fusion using a 
variety of algorithms and get better quality roll/pitch heading 
(madgwick, mahoney, etc.).


All of this will require at a minimum magnetometer calibration to 
compensate for hard and soft iron errors, and probably gyroscope 
calibration to remove the zero drift error. Accel calibration helps, 
but isn't as critical as the mag and gyro.


All of the above can probably be fit into a package based on sensor 
'orientation', which might be a natural organizational unit?




I think this belongs in the core sensor package itself, or as a 
sub-directory of hw/sensor (i.e. hw/sensor/orientation).  Orientation is 
a very common transformation and having a unified API for it makes sense 
to me, unless you think that the various factors that go into 
orientation (e.g. accuracy) vary greatly based upon the type of sensor 
that you’re looking at, and therefore the algorithms themselves will 
vary greatly.



FILTERS

A second very important helper unit is something that implements basic 
DSP algorithms to filter raw sensor data. This is critical in my 
opinion, but often neglected in open source systems.


This should contain things like a simple moving average filter, a 
basic FIR and IIR filter (that can take coefficients from 
Octave/Matlab), and a other very common but useful filters that will 
help remove noise from less expensive sensors like the lsm303dlhc.


For example, see:

 * *iir.c* here:
   
https://github.com/microbuilder/LPC11U_LPC13U_CodeBase/tree/development/src/drivers/filters/iir
 * Simple and weighted moving average filters here:
   
https://github.com/microbuilder/LPC11U_LPC13U_CodeBase/tree/development/src/drivers/filters/ma

The iir.c example above has some notes on calculating the coefficients 
for a 2 pole butterworth filter, or determining the coefficients 
internally. It's a limited example, but I think the right direction to 
move things:


 * Octave Butterworth Example:
   
https://github.com/microbuilder/LPC11U_LPC13U_CodeBase/blob/development/src/drivers/filters/iir/iir.c#L57
 * Calculating Butterworth Directly:
   
https://github.com/microbuilder/LPC11U_LPC13U_CodeBase/blob/development/src/drivers/filters/iir/iir.c#L269



To me, this is a separate package in core, but very useful.. Also, being 
able to apply simulated data through a filter and get reliable results 
(and standard scripts to graph those results.)


My biggest question comes in: what are the standard types that we allow 
to be passed to these filters?  Is it just floats, or do we allow you 
to, for example, pass accelerometer directly.



BONUS POINTS: PEDOMETER

A third package that could be implemented that would be a useful 
example for BLE is taking accelerometer data and turning it into a 
pedometer, which can be done with some reasonably straight forward 
code. I have some code I can recycle for this, but it isn't publicly 
available on Github.


I think this is interesting for BLE and I can help here, but the two 
above are more critical.




Yeah, I think this is useful.  I’m not sure this belongs in the core, 
but perhaps a package that uses Mynewt?  I could be convinced otherwise, 
if folks think it should be OS level.



Kevin

PS: Some of the code above is quite old and I'm not terribly proud of 
it and would do things differently today and I've reimplemented these 
elsewhere differently, but I think the examples are at least valid as 
an illustration or where things need to move to be useful in the real 
world.


:-)

Very useful.

Sterling

Re: [SensorAPI] Default Sensor Config

[Sterling Hughes]

It’s an interesting thought, as you point out there are kinda two 
things at work here.


1- A driver needs to be “config’ed” by default, and where the 
driver init is called is not the right place to do that.


2- The driver doesn’t have any user specific data to call, there 
should be a reasonable/sane default, and I don’t think requiring the 
user to call:


driver->config(NULL);

Is particularly good API design.  I think we should probably dictate 
that config() can be called as many times as possible, and have a 
“config” phase of the sensor API, i.e. when the task gets started, 
or a new sensor gets registered, the sensor API calls config(NULL) to 
set default parameters, and then users can call config(data), if they 
want to reconfigure defaults.


On 29 Dec 2016, at 2:29, Kevin Townsend wrote:

One issues I saw working on some sensor drivers (based on the 
simulated accel as a starting point) is that no 'default' config 
settings are currently being set, and it seems possible that a sensor 
might be initialised without calling the config function explicitly.


The config system is great (highly flexible and easy to understand), 
but would it be better to have a default config setting that is set 
when the sensor is initialized, or should running the config function 
at least once be considered mandatory and the assumption made that it 
is always being called? In that case, should we return an error if 
something like a read function is called but the sensor hasn't been 
configured yet to put it into a known state (and probably wake the 
sensor up since many devices will default to booting into power down 
mode)?

Re: newt build error

[Sterling Hughes]

Hi Alan,

The new PDK now works.  @wes3 added some commits to support the BSP.

Sterling

On 23 Dec 2016, at 12:00, Alan Graves wrote:


Hi dev,

For my environment I'm running Ubuntu 16.x in a VMWare environment 
under Windows 7. I also have Go 1.6 installed and working.
The problem is that I've been trying to do a native Linux install of 
newt and I get a strange Go? error, which unfortunately prevents some 
executables from being build:


agraves@agravesLNXPV3997:~/dev/go/src/mynewt.apache.org/newt/newt$ go 
get

# mynewt.apache.org/newt/newt/syscfg
syscfg/syscfg.go:923: constant 4294967295 overflows int
agraves@agravesLNXPV3997:~/dev/go/src/mynewt.apache.org/newt/newt$
agraves@agravesLNXPV3997:~/dev/go/src/mynewt.apache.org/newt/newt$ cd 
$GOPATH

agraves@agravesLNXPV3997:~/dev/go$ ls
bin  pkg  src
agraves@agravesLNXPV3997:~/dev/go$ cd bin
agraves@agravesLNXPV3997:~/dev/go/bin$ ls
aggcodecgen  eg  gorename  h2i   mc   
stress
basic  colcmpfiximports  gotextheapview  newtmgr  
stringer

benchcmp   cover godex   gotypehello newtvm   tip
bundle crypt goimports   goyacchook  present  
toolstash

callgraph  digraph   gomvpkg guru  html2article  ssadump
agraves@agravesLNXPV3997:~/dev/go/bin$

Unfortunately, Go is Greek to me, although it might be interesting to 
figure out, I was hoping to simply test drive things on a nRF52832 
Preview DK. On an aside do you know if anyone has tried using the 
newly released BLE 5 nRF52840 Preview DK?


Any help getting my setup going would be appreciated.

Thanks,
ALan

Re: Schedule task with strict fixed timing and variable workload

[Sterling Hughes]

+1 for PWM support, but as a driver, not HAL.

https://issues.apache.org/jira/browse/MYNEWT-525

Sterling

On 28 Dec 2016, at 10:11, David G. Simmons wrote:


+1 on PWM.

dg
On Dec 26, 2016, at 2:14 PM, will sanfilippo  
wrote:


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


--
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.

Re: Schedule task with strict fixed timing and variable workload

[Sterling Hughes]

+1 - I agree with this thread.

https://issues.apache.org/jira/browse/MYNEWT-522

On 26 Dec 2016, at 10:26, Kevin Townsend wrote:


Hi Will,

Thanks for the feedback.

1) Unless you are the highest priority task, other tasks can run 
which could cause delays, and thus you are not waking up at the 
desired time.
Yeah, everything is based on the assumption that priority is resolved 
by design, and that the scheduling constraints are realistic and well 
understood in the system.
2) Using os_time_delay() and os_callout_reset() gives you a 1 os time 
tick resolution, so if your ticks are 10 msecs, you will be off by up 
to 9 msecs. A 1 msec ticker gets you off by up to 1 msec.


Using a task to post another task is a bit heavyweight; I would use a 
timer or a callout to do this. A timer would solve your “tick 
resolution” issue but would not solve the problem of a task wake up 
getting delayed.
A timer would be a valid solution as well, yes. I haven't looked 
seriously at the timer HAL yet, but I'll have a look right now and 
give it a try just to familiarize myself with it.


I saw earlier today that there wasn't PWM support and wanted to see if 
that was something that could be easily added to the timer HAL since 
it's a common requirement that should probably be included (motor 
control, dimming control, etc.). Different issue though!
It would not be hard to add an API to os_callout.c that could be used 
for this. Something like “os_callout_reset_at” or 
“os_callout_reset_tick” which you could pass in a specified os 
tick. Not sure what the API should do if you missed the os tick 
(return -1 and not post the task)? This would be simple code to use; 
just add the sample rate to the last time and call the new 
os_calllout API.
Personally, I think this would make a lot of sense and solve what is 
bound to be a common problem, and perhaps you can have a flag to 
define the behaviour when you miss the delay. Either you return an 
error code, OR you fire the task as soon as you can (though ideally 
still with a flag of some sort to know you're late), but having the 
option between the two should solve some problems.


K.

Re: newt build error

[Sterling Hughes]

Hi Alan,

What go version are you using?  Also, what branch is the mynewt source 
that you’re trying to compile?


For me:

$ pwd
/Users/sterling/dev/go/src/mynewt.apache.org/newt/newt
$ git status
On branch develop

$ go version
go version go1.7.4 darwin/amd64
$

We’ve dropped support in mynewt for the PDK, you need the full DK in 
order to get it up and running.  We have not yet supported the nRF52840 
PDK, but the plan is for me to do it over the holidays, so early Jan we 
should have something working.  There are a couple of errata that need 
to be copied over from the nordic DK, it doesn’t look like a huge job.


Best,

Sterling

ps: These are my parameters — but I’m doing development, don’t 
worry if they differ from yours — I’ll try and reproduce with your 
setup.


On 23 Dec 2016, at 12:00, Alan Graves wrote:


Hi dev,

For my environment I'm running Ubuntu 16.x in a VMWare environment 
under Windows 7. I also have Go 1.6 installed and working.
The problem is that I've been trying to do a native Linux install of 
newt and I get a strange Go? error, which unfortunately prevents some 
executables from being build:


agraves@agravesLNXPV3997:~/dev/go/src/mynewt.apache.org/newt/newt$ go 
get

# mynewt.apache.org/newt/newt/syscfg
syscfg/syscfg.go:923: constant 4294967295 overflows int
agraves@agravesLNXPV3997:~/dev/go/src/mynewt.apache.org/newt/newt$
agraves@agravesLNXPV3997:~/dev/go/src/mynewt.apache.org/newt/newt$ cd 
$GOPATH

agraves@agravesLNXPV3997:~/dev/go$ ls
bin  pkg  src
agraves@agravesLNXPV3997:~/dev/go$ cd bin
agraves@agravesLNXPV3997:~/dev/go/bin$ ls
aggcodecgen  eg  gorename  h2i   mc   
stress
basic  colcmpfiximports  gotextheapview  newtmgr  
stringer

benchcmp   cover godex   gotypehello newtvm   tip
bundle crypt goimports   goyacchook  present  
toolstash

callgraph  digraph   gomvpkg guru  html2article  ssadump
agraves@agravesLNXPV3997:~/dev/go/bin$

Unfortunately, Go is Greek to me, although it might be interesting to 
figure out, I was hoping to simply test drive things on a nRF52832 
Preview DK. On an aside do you know if anyone has tried using the 
newly released BLE 5 nRF52840 Preview DK?


Any help getting my setup going would be appreciated.

Thanks,
ALan

Re: how to use include path in myNewt

[Sterling Hughes]

Hi Then,

It may be useful to look at how we bundle chip vendor SDKs when looking 
at incorporating this project.


If there are an additional set of options that would help make this easy 
to work with newt, don’t hesitate to suggest them.  We want to make 
this easy.


Here is a pkg.yml file which specifies how to build the Nordic SDK:

https://github.com/runtimeinc/mynewt_nordic/blob/master/hw/mcu/nordic_sdk/pkg.yml

You can notice a few things:

pkg.type: sdk

Tells newt that this is an external SDK package.  When newt sees that, 
it looks in the src/ext directory of the package, and has a few rules:


1- Recurse all sub-directories of ext, and add them directly to the 
include path (allowing the include path to resolve.)


2- Recursively build all sub-directories of ext.

As you can see in the pkg.yml there are then additional rules you can 
apply to the complication, like which directories to build (if you 
don’t want to build all of ext/*, use pkg.src_dirs), and what types of 
files to ignore (ign_files) and what type of directory names to ignore 
(ign_dirs).


Hope this helps.  Again, if there are additional things you need to make 
this easier, let us know.  We can look at making newt work better for 
your scenario.


Best,

Sterling


On 21 Dec 2016, at 21:37, then yon wrote:


Dear Support,

Can i know how to use include path in myNewt?

Currently i having an existing project that i wish to port into myNewt 
platform; it will be a big hassle without include path feature.


Thank you.

Regards,

Then Yoong Ze

Re: WIP: sensor API

[Sterling Hughes]

I will correct this, thanks.  I frequently forget that shell commands 
are not const.  I was too lazy to make them a linker section and const 
them, which I really should have done.


Sterling

On 17 Dec 2016, at 2:52, Kevin Townsend wrote:

Hmm, this must be a GCC issue on Linux ... I forgot to make this 
change and it ran find on OS X and I think Sterling uses OS X as well 
which is probably why he didn't see this. Thanks for mentionning it on 
the dev list, though! Even if it runs (???) it seems to be a mistake 
to have const, yes.


Also ... I did a pull to get `sensors_branch' manually.  My output is 
different than yours, though ... did you make any local changes?


   ?
   1749:Commands:
   1749: echo ?prompt ticks tasks mempools
   1751: datesensor
   tasks
   2163:Tasks:
   2163:task pri tid  runtime  cswstksz stkuse   lcheck
 ncheck flg
   2167:idle 255   0 2167 177916384 3500   
   0   0
   2169:uartpoll   0   10 178116384 3660   
   0   0
   2173:  socket   2   20  108 4096 3980   
   0   0
   2175:  sysevq  10   30   27 8192 5480   
   0   0

   sensor
   2641:Possible commands for sensor are:
   2642:  list
   sensor list
   2869:sensor dev = accel, type = 1
   sensor
   3379:Possible commands for sensor are:
   3380:  list
   sensor read
   3717:Three arguments required for read: device name, sensor type 
and

   number of samples, only 0 provided.
   sensor read accel 1 1
   5230:x = 0, y = 0, z = 0
   5230:x = 0, y = 0, z = 0
   5231:x = 0, y = 0, z = 0
   5232:x = 0, y = 0, z = 0
   5234:x = 0, y = 0, z = 0
   5235:x = 0, y = 0, z = 0
   5236:x = 0, y = 0, z = 0
   5236:x = 0, y = 0, z = 0
   5237:x = 0, y = 0, z = 0
   5239:x = 0, y = 0, z = 0

K.


On 17/12/16 10:08, hathach wrote:

Hi,

I am testing out the new sensor API. Just want to say that 'const' 
need to be dropped since we did modify the cmd variable


https://github.com/apache/incubator-mynewt-core/blob/sensors_branch/hw/sensor/src/sensor_shell.c#L38

I got into "Segmentation Fault" when running it with simulation 
(native pc).



On 13/12/2016 12:51, Sterling Hughes wrote:

Hi,

I’ve added initial support for a sensors API to mynewt in a branch 
off develop called “sensors_branch.”  You can find a full diff 
here, or pull the source code directly:


https://github.com/apache/incubator-mynewt-core/compare/develop...sensors_branch

I’ll caveat that this API needs work, and further implementation 
with real sensors, however, I thought I’d send it to the list for:


- early comments

- if other people are playing with sensors and want to join the 
cause on the branch, I think now is a decent time.


I have a couple of adafruit sensors locally, and so I plan on adding 
support for the tsl2561 and lis3dh next.  Although, if someone wants 
to beat me to it - by all means.


The interface is defined in this file:

https://github.com/apache/incubator-mynewt-core/compare/develop...sensors_branch#diff-ec052d973c26072d9ac2e198f16e764a

An example implementation of a sensor driver can be found here:

https://github.com/apache/incubator-mynewt-core/compare/develop...sensors_branch#diff-1c17a623363565318dfefdb8891c0376

And calling the API for basic shell functionality (usage), can be 
found here:


https://github.com/apache/incubator-mynewt-core/compare/develop...sensors_branch#diff-d90d3b58f5055894b546a7eff86ba20c

Again, I’ll caveat that this is a WIP, so feedback is welcome 
(don’t be shy!), and patches / co-development is even more so! 
This is a holiday project for me, so I plan on having something pull 
worthy in early January, although no promises.


Cheers,

Sterling

WIP: sensor API

[Sterling Hughes]

Hi,

I’ve added initial support for a sensors API to mynewt in a branch off 
develop called “sensors_branch.”  You can find a full diff here, or 
pull the source code directly:


https://github.com/apache/incubator-mynewt-core/compare/develop...sensors_branch

I’ll caveat that this API needs work, and further implementation with 
real sensors, however, I thought I’d send it to the list for:


- early comments

- if other people are playing with sensors and want to join the cause on 
the branch, I think now is a decent time.


I have a couple of adafruit sensors locally, and so I plan on adding 
support for the tsl2561 and lis3dh next.  Although, if someone wants to 
beat me to it - by all means.


The interface is defined in this file:

https://github.com/apache/incubator-mynewt-core/compare/develop...sensors_branch#diff-ec052d973c26072d9ac2e198f16e764a

An example implementation of a sensor driver can be found here:

https://github.com/apache/incubator-mynewt-core/compare/develop...sensors_branch#diff-1c17a623363565318dfefdb8891c0376

And calling the API for basic shell functionality (usage), can be found 
here:


https://github.com/apache/incubator-mynewt-core/compare/develop...sensors_branch#diff-d90d3b58f5055894b546a7eff86ba20c

Again, I’ll caveat that this is a WIP, so feedback is welcome (don’t 
be shy!), and patches / co-development is even more so!  This is a 
holiday project for me, so I plan on having something pull worthy in 
early January, although no promises.


Cheers,

Sterling

Re: System init and OS eventq ensure

[Sterling Hughes]

Hi,



On Dec 11, 2016, at 10:55 AM, Christopher Collins 
 wrote:


On Sun, Dec 11, 2016 at 10:11:44AM -0800, will sanfilippo wrote:
Personally, I keep wanting to try and have the OS start up right 
away.


I wonder if this could solve the problem that Sterling raised (no
default event queue during sysinit).  The control flow in main() 
might

look like this:

1. Start OS
2. Create and designate default event queue.
3. sysinit()

I think it would be nice if we could avoid adding another 
initialization

stage.



+1


There are definitely “issues” with this:
a) We do not want to waste idle task stack.
b) When tasks are started they would start running right away. This
might cause issues where a task does something to a piece of memory
that another task initializes, but since that other task has not
initialized it yet…

b) can be avoided by locking the scheduler until initializations are 
finished.


a) is problematic :-) I think someone brought this up before, but I
wonder if it is worth the effort to do something “a bit crazy” 
like
the following: the idle task uses “the heap” during 
intialization.

Once initializations are over (or at some point that we determine),
the idle task stack is made smaller and the “top” of the heap is 
set
to the end of the idle task stack. For example, idle task stack is 
at

0x20008000 and is of size 1K bytes; the bottom of the heap is at
0x20007000; the top of the heap is at 0x20007C00 (in my 
nomenclature,
heap allocations start from the bottom). At some point, the top of 
the

heap is moved to 0x20007F80.

Yeah, maybe a bit crazy… :-)


I don't think that's too crazy.  It would be great if we could just
malloc() a temporary stack, and then free it when initialization
completes.  I guess the worry is that this will cause heap
fragmentation?



I’m not crazy about malloc()’ing this space.  Especially since 
system init (where we’d use this memory) is where people malloc() 
their memory pools, and so you have 1K of space that could potentially 
affect memory exhaustion.  Maybe its an awful idea… but why not let 
people specify the startup task stack, and we can guarantee that this 
task gets deleted before the rest of the tasks/system runs.  That way, 
you can just choose one of your task’s stacks that is sufficiently 
large, and use that for startup stack.


Sterling

yield() and os_eventq_run()

[Sterling Hughes]

Hi,

As a part of developing the sensor interface, I want to register a 
“listener” on the event queue:


listener.sl_sensor_type = type;
listener.sl_func = sensor_shell_read_listener;
listener.sl_arg = 

rc = sensor_register_listener(sensor, );
if (rc != 0) {
goto err;
}

And then I want to essentially “wait” until I’ve read ’n’ 
entries, and block in my task:



/* Block until we've read 'n' samples. */
while (ctx.num_entries < nsamples) {
os_eventq_run(sensor_mgr_evq_get());
os_time_delay(1);
}

The sensor_shell_read_listener() function updates “num_entries”, and 
when I’ve read the desired number of samples, the loop finishes.


Just calling os_time_delay() or os_eventq_run() in and of themselves is 
not sufficient:


- os_eventq_run() will let the current task’s events (default event 
queue in this case) run, but won’t process other tasks events (e.g. 
shell is run out of a separate task in this case.)


- os_time_delay() lets the other tasks run.

q: Should we add a os_eventq_yield(evq, time) function that does both of 
these tasks?  I think it might be clearer that this is the intention in 
that case.


Sterling

Re: System init and OS eventq ensure

[Sterling Hughes]

How do you assign an event queue if you are relying on the default event queue 
being there?  

Can you point me to an example of where this is done? 

Sterling 

> On Dec 10, 2016, at 12:08 PM, Christopher Collins <ccoll...@apache.org> wrote:
> 
> The way other packages handle this is they enqueue the startup event
> when their event queue is assigned.  This happens automatically when you
> call os_eventq_designate(); the last parameter is the event to enqueue
> immediately.
> 
> Chris
> 
>> On Sat, Dec 10, 2016 at 11:30:27AM -0800, Sterling Hughes wrote:
>> Hi,
>> 
>> I’m looking at using the default eventq (or allowing for it), in a 
>> library I’m working on.  In order to do that, I have a function:
>> 
>> static struct os_eventq *
>> sensor_mgr_evq_get(void)
>> {
>> os_eventq_ensure(_mgr.mgr_eventq, NULL);
>> 
>> return (sensor_mgr.mgr_eventq);
>> }
>> 
>> And this function gets called within my package’s sysinit, as I want 
>> to schedule a callout to run this function immediately on bootup:
>> 
>> /**
>>  * Initialize sensor polling callout and set it to fire on boot.
>>  */
>> os_callout_init(_mgr.mgr_wakeup_callout, 
>> sensor_mgr_evq_get(),
>> sensor_mgr_wakeup_event, NULL);
>> os_callout_reset(_mgr.mgr_wakeup_callout, 0);
>> 
>> The problem is that the default event queue is not setup until after 
>> sysinit executes, as task setup is later on.
>> 
>> What is the right way to do this?  For now, I can move the 
>> initialization from sysinit and to the main() function at task level, 
>> however, I don’t think this is how we want to manage initialization 
>> over time.  We probably need some way for a package to have a system 
>> initialization stage that runs after the OS has started, and the default 
>> event queue has been set.
>> 
>> Cheers,
>> 
>> Sterling

GDB + SIM broken with macOS sierra

[Sterling Hughes]

I’m wondering if anyone else has seen this / worked around it?

I can run SIM directly from command line, or under LLDB, but GBD seems 
to be broken?


Sterling

Re: Subscription Request and Question.

[Sterling Hughes]

+1

I think even a PSK example would be helpful.

On the NRF52, I think it would be practical to run DTLS over the 
transport, even if a bit heavyweight.  It would be great to have an 
example of that.




Speaking of this, I was wondering if folks had experience with embedded 
TLS libraries.  Right now we bundle with mbedtls, which supports TLS, 
and, as far as I can tell, DTLS as well.


I’ve noticed there is tinydtls out there, has anyone compared the two?

Sterling

Re: Subscription Request and Question.

[Sterling Hughes]

On 3 Dec 2016, at 6:38, Kevin Townsend wrote:


On 03/12/16 11:54, Tim Hutt wrote:
Android and iOS don't allow you to specify the keys used by BLE's 
native
encryption, but there is nothing stopping you using BLE as an 
insecure
transport and implementing your own encryption on top of it (well 
apart
from time, skill, and flash & RAM constraints). If you did that you 
would

be able to use whatever keys you wanted because you implemented it.

This seems like something that would be nice to have as a proof of 
concept demo in the core repo. I'm always interested in security, but 
it's far enough outside my own core area of competence (HW design, RF 
and sensors) that I know trying to roll my own code would do more harm 
than good and give a false sense of security. If there are people on 
the dev list with up to date experience in the field, I suspect a 
decent number of end users would benefit from a basic starting point 
to encrypt BLE communication across a simple service and 
characteristic set. The nRF52 isn't 'fast' in terms of clock speed but 
it's still a reasonably capable chip with on board AES and single 
precision HW floating point acceleration, and there is a decent amount 
of flash and SRAM available.


+1

I think even a PSK example would be helpful.

On the NRF52, I think it would be practical to run DTLS over the 
transport, even if a bit heavyweight.  It would be great to have an 
example of that.


Sterling

Re: HEX DEBUG output in newtmgr

[Sterling Hughes]

captured here: https://issues.apache.org/jira/browse/MYNEWT-497

i don’t see a reason to print both hex and decimal, although if 
someone cares, retaining it as an option seems fine.  i agree that 
default should be hex.


On 30 Nov 2016, at 8:52, Kevin Townsend wrote:


Hi Christopher,

The latest version has improved debug output with the combined HEX and 
DEC which I don't remember in earlier versions, so thanks for that. 
We've been using the -t trace option but it's good to point out to 
anyone who stumbles across this thread anyway.


I don't find the DEC very useful in the [DEBUG] output lines within 
'Data:' which is what I was referring to in the original email, but 
the TX packet dump is a nice approach where you list both HEX and 
ASCII. My brain is just hard-wired to HEX and I find myself converting 
the verbose DEC values on top (which are very useful for the labels) 
into the HEX payload below to match things up. 100% HEX might be more 
natural for a lot of people.


Between -lDEBUG and -t we were able to get everything we needed and 
there are higher priority things to cleanup, and I'm happy to have 
what is there today, but I'd say just dropping DEC altogether probably 
isn't going to cause any problems ... but perhaps other users will 
disagree???



On 30/11/16 17:42, Christopher Collins wrote:
I accidently wrapped the newtmgr output with short lines.  Here is 
the

unadalterated output:

[ccollins@ccollins-mac:~/releases/1.0.0-b1/rc2]$ newtmgr -ldebug -c 
ttys010 echo abc123
2016/11/30 08:25:57 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 
Len:10 Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]}
2016/11/30 08:25:57 [DEBUG] Serializing request &{Op:2 Flags:0 Len:10 
Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]} into 
buffer [2 0 0 10 0 0 0 0 161 97 100 102 97 98 99 49 50 51]

2016/11/30 08:25:57 [DEBUG] Tx packet dump:
  02 00 00 0a 00 00 00 00  a1 61 64 66 61 62 63 31  
|.adfabc1|

0010  32 33 |23|

2016/11/30 08:25:57 [DEBUG] Writing [6 9] to data channel
2016/11/30 08:25:57 [DEBUG] Writing [65 66 81 67 65 65 65 75 65 65 65 
65 65 75 70 104 90 71 90 104 89 109 77 120 77 106 79 53 57 65 61 61] 
to data channel

2016/11/30 08:25:57 [DEBUG] Writing [10] to data channel
^C
[ccollins@ccollins-mac:~/releases/1.0.0-b1/rc2]$ newtmgr -t -ldebug 
-c ttys010 echo abc123
2016/11/30 08:26:13 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 
Len:10 Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]}
2016/11/30 08:26:13 [DEBUG] Serializing request &{Op:2 Flags:0 Len:10 
Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]} into 
buffer [2 0 0 10 0 0 0 0 161 97 100 102 97 98 99 49 50 51]

2016/11/30 08:26:13 [DEBUG] Tx packet dump:
  02 00 00 0a 00 00 00 00  a1 61 64 66 61 62 63 31  
|.adfabc1|

0010  32 33 |23|

2016/11/30 08:26:13 [INFO] Outgoing:
  06 09 |..|

2016/11/30 08:26:13 [DEBUG] Writing [6 9] to data channel
2016/11/30 08:26:13 [INFO] Outgoing:
  41 42 51 43 41 41 41 4b  41 41 41 41 41 4b 46 68  
|ABQCAAAKAKFh|
0010  5a 47 5a 68 59 6d 4d 78  4d 6a 4f 35 39 41 3d 3d  
|ZGZhYmMxMjO59A==|


2016/11/30 08:26:13 [DEBUG] Writing [65 66 81 67 65 65 65 75 65 65 65 
65 65 75 70 104 90 71 90 104 89 109 77 120 77 106 79 53 57 65 61 61] 
to data channel

2016/11/30 08:26:13 [INFO] Outgoing:
  0a|.|

2016/11/30 08:26:13 [DEBUG] Writing [10] to data channel
^C

Thanks,
Chris

On Wed, Nov 30, 2016 at 08:40:39AM -0800, Christopher Collins wrote:

Hi Kevin,

On Wed, Nov 30, 2016 at 01:37:38PM +0100, Kevin Townsend wrote:
We're currently working on a mobile version of newtmgr, and the 
DEBUG
output is very useful to sanity check commands and responses, but 
the
output in DEC is kind of a pain when most SW engineering on 
embedded
devices is done in HEX. Is there an option I'm missing to output 
HEX

instead of DEC, or is this something worth considering changing
internally in the tool to default to HEX which feels like a far 
more

natural choice from my PoV?

The newtmgr debug output is pretty much a mess at the moment.  That
said, it does do a hex dump of incoming and outgoing packets when 
you
specify the "-ldebug" flag.  If you are only seeing decimal output, 
then

is it possible you are using an old version of newtmgr?

The reason I say the debug output is a mess is that it prints both a
decimal and a hex dump.  For example:

 [ccollins@ccollins-mac:~/releases/1.0.0-b1/rc2]$ newtmgr 
-ldebug -c

 ttys010 echo abc123
 2016/11/30 08:25:57 [DEBUG] Writing newtmgr request &{Op:2 
Flags:0
 Len:10 Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 
51]}
 2016/11/30 08:25:57 [DEBUG] Serializing request &{Op:2 Flags:0 
Len:10
 Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]} 
into 

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

[Sterling Hughes]

+1 binding

On 30 Nov 2016, at 5:39, David G. Simmons wrote:


+1

On Nov 29, 2016, at 9:30 PM, Christopher Collins 
 wrote:


[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...


--
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.

Re: Initial FAT support

[Sterling Hughes]

I agree — the license seems perfectly acceptable for ASF releases, but 
it is non-standard.  It’s like somebody modified a BSD license to be a 
MIT license.


+/*/
 +/  FatFs - Generic FAT file system module  R0.12b 
/

 
+/-/
 +/
 +/ Copyright (C) 2016, ChaN, all right reserved.
 +/
 +/ FatFs module is an open source software. Redistribution and use of 
FatFs in
 +/ source and binary forms, with or without modification, are 
permitted provided

 +/ that the following condition is met:
 +
 +/ 1. Redistributions of source code must retain the above copyright 
notice,

 +/this condition and the following disclaimer.
 +/
 +/ This software is provided by the copyright holder and contributors 
"AS IS"

 +/ and any warranties related to this software are DISCLAIMED.
 +/ The copyright owner or contributors be NOT LIABLE for any damages 
caused

 +/ by use of this software.
 
+/*/


On 17 Nov 2016, at 14:38, Niclas Hedhman wrote:


AFAIK, there is no 1-clause BSD... So, can you point to the license?
Downloading http://www.elm-chan.org/fsw/ff/ff12b.zip doesn't seem to
contain license information, and files are instead full of "(C) ChaN, 
2015"


On Fri, Nov 18, 2016 at 5:27 AM, Fabio Utzig  wrote:


Hello,

I just opened a new PR adding FAT support:

https://github.com/apache/incubator-mynewt-core/pull/121

This implements: https://issues.apache.org/jira/browse/MYNEWT-318

I've used Elm-Chan's FATFS (kind of de-facto in the embedded world):
http://www.elm-chan.org/fsw/ff/00index_e.html

This is basically 1-clause BSD compatible licensed so should be no
problem to add to repo but correct me if I'm wrong!

For now the implementation is limited to using hal_flash 
infrastructure.
Since no sane person would ever format a microcontroller flash using 
FAT

(I hope!), I see two options moving forward:

1) Write a MMC driver to access SD-Cards. I think this would rely 
only

on having a hal_spi driver.
2) Add support for USB and USB disks. This is much harder but will 
have

to be done eventually anyway.

So, what's the suggestion?

Fabio Utzig



--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Sensor Drivers and File Location

[Sterling Hughes]

I should also mention, another option that we could do is have drivers 
for the individual sensors (just have them expose native APIs as 
drivers, e.g. bmp2085_read_val()), but also map into a generic sensor 
API, that we locate in hw/sensors, as an example.


I’m not sure to what extent people using these sensors want raw access 
to them (i.e. this sensor has special features I care about), versus 
just treating them as a generic sensor.  If we think it will be common 
to have special features per-sensor, i’d say it makes sense to have:


hw/sensors — generic sensor API

and then

hw/drivers/sensors/

contain individual sensor drivers organized by manufacturer, that create 
their own device APIs, but also can register with the sensor API in 
hw/sensors.


Sterling

On 10 Nov 2016, at 15:42, Sterling Hughes wrote:


Hi Kevin,

I have some thoughts, but I’m not sure they all directly address 
your concerns :-)


More details on directory re-org and drivers below, but I wanted to 
mention upfront: I really think its worth thinking through the sensor 
api you mention in your PS, and then doing the directory org after 
that.  Because I would imagine that these drivers fit directly into 
that API, which I think is crucially important.  It would be really 
good to understand whether that API was sufficient for 99% of use 
cases as well, because if so, we would just want to have the 
implementations map into that API.


Additionally, I wanted to mention, that a worthy goal here would be to 
make these sensors discoverable, in a way that can be mapped into OIC. 
 One of the nice things about OIC is that it supports standardized 
resource discovery, and I think it would be awesome, especially for 
Maker applications, if you could connect to a device with a phone, and 
automatically get a list of sensors available, and interact with them. 
 If we make sure that the sensor APIs are introspectable, this should 
be easy to do.


I also want to point out how we’ve done certain drivers, like the 
ADC driver.  Essentially, we have a top-level package, “adc”, 
which contains the interface for all ADC drivers, and then we have the 
individual implementation of the driver itself.  The following source 
files point to this:


* high-level ADC API: hw/drivers/adc/include/adc/adc.h
	- note: 2 interfaces defined here.  The driver implementation 
interface: adc_driver_funcs, and the user interface calls.


* implementation of ADC for NRF52: 
hw/drivers/adc/adc_nrf52/src/adc_nrf52.c
	- note: only exported call is int nrf52_adc_dev_init(struct os_dev *, 
void *), which is passed as a function pointer to os_dev_create() in 
hal_bsp.c, when the adc device is created.


So the idea is that there is an API for the driver, and then 
sub-packages to that driver that can implement that API.  You have 
flexibility in the sub-packages, so you could do something like:


hw/drivers/sensors/src/sensors.c (*) main sensors driver
hw/drivers/sensors/pressure/bosch/bm32/src/bm32.c (*) bm32 
implementation.


Users would then create the device, with the bm32 sensor:

os_dev_create(“my_sensor”, bm32_init_func);

But can then open and use the device with the generic sensor API, 
without knowing the underlying implementation.


sensor = (struct sensor *) os_dev_open(“my_sensor”)
sensor_read(sensor, );

I assume you read most of this, but I just wanted to point this out.

As an aside: I certainly think we should use pkg.keywords extensively 
in the drivers directory, and make it easy to search for drivers.  We 
should also make sure that “newt pkg search”: a) works, and b) 
provides useful information about each of the drivers when there are 
matches.  There is going to be no _perfect_ way to organize this for 
ease of discovery, but I think newt can help a lot.


On 10 Nov 2016, at 1:59, Kevin Townsend wrote:

There are no sensor drivers in the system at present, but now that 
the HAL rework is complete I wanted to port a few drivers over to 
Mynewt just to properly test the HW and HAL out. Existing sensor 
drivers is one of the key factors to draw people into any embedded 
RTOS/system, so I think it's important to get this right to pull 
people into the Mynewt ecosystem.




+1 - I totally agree!

I'm curious what kind of organization would make the most sense 
moving forward, though. Assuming some drivers are included in the 
core mynewt repo instead of being in independent libraries, what 
would be an ideal root location to place them in the file structure?


- hw/drivers/sensors ?



Do we think that 90% of sensors will have a unified interface.  I.e. 
sensors have discoverable channels, and those channels have value 
types.


sensor_discover(sensor, _chan_types);

assert(sensor_chan_types[0]->type == SENSOR_ACCEL_X);

sensor_read(sensor, 0, _x);

And you can have unified interface to configure these (e.g. 
sensor_config()), that might take an opaque blob, but is pretty 
standard.


If so, I think you have a driver of type: sensor, that defi

Re: Sensor Drivers and File Location

[Sterling Hughes]

Hi Kevin,

I have some thoughts, but I’m not sure they all directly address your 
concerns :-)


More details on directory re-org and drivers below, but I wanted to 
mention upfront: I really think its worth thinking through the sensor 
api you mention in your PS, and then doing the directory org after that. 
 Because I would imagine that these drivers fit directly into that API, 
which I think is crucially important.  It would be really good to 
understand whether that API was sufficient for 99% of use cases as well, 
because if so, we would just want to have the implementations map into 
that API.


Additionally, I wanted to mention, that a worthy goal here would be to 
make these sensors discoverable, in a way that can be mapped into OIC.  
One of the nice things about OIC is that it supports standardized 
resource discovery, and I think it would be awesome, especially for 
Maker applications, if you could connect to a device with a phone, and 
automatically get a list of sensors available, and interact with them.  
If we make sure that the sensor APIs are introspectable, this should be 
easy to do.


I also want to point out how we’ve done certain drivers, like the ADC 
driver.  Essentially, we have a top-level package, “adc”, which 
contains the interface for all ADC drivers, and then we have the 
individual implementation of the driver itself.  The following source 
files point to this:


* high-level ADC API: hw/drivers/adc/include/adc/adc.h
	- note: 2 interfaces defined here.  The driver implementation 
interface: adc_driver_funcs, and the user interface calls.


* implementation of ADC for NRF52: 
hw/drivers/adc/adc_nrf52/src/adc_nrf52.c
	- note: only exported call is int nrf52_adc_dev_init(struct os_dev *, 
void *), which is passed as a function pointer to os_dev_create() in 
hal_bsp.c, when the adc device is created.


So the idea is that there is an API for the driver, and then 
sub-packages to that driver that can implement that API.  You have 
flexibility in the sub-packages, so you could do something like:


hw/drivers/sensors/src/sensors.c (*) main sensors driver
hw/drivers/sensors/pressure/bosch/bm32/src/bm32.c (*) bm32 
implementation.


Users would then create the device, with the bm32 sensor:

os_dev_create(“my_sensor”, bm32_init_func);

But can then open and use the device with the generic sensor API, 
without knowing the underlying implementation.


sensor = (struct sensor *) os_dev_open(“my_sensor”)
sensor_read(sensor, );

I assume you read most of this, but I just wanted to point this out.

As an aside: I certainly think we should use pkg.keywords extensively in 
the drivers directory, and make it easy to search for drivers.  We 
should also make sure that “newt pkg search”: a) works, and b) 
provides useful information about each of the drivers when there are 
matches.  There is going to be no _perfect_ way to organize this for 
ease of discovery, but I think newt can help a lot.


On 10 Nov 2016, at 1:59, Kevin Townsend wrote:

There are no sensor drivers in the system at present, but now that the 
HAL rework is complete I wanted to port a few drivers over to Mynewt 
just to properly test the HW and HAL out. Existing sensor drivers is 
one of the key factors to draw people into any embedded RTOS/system, 
so I think it's important to get this right to pull people into the 
Mynewt ecosystem.




+1 - I totally agree!

I'm curious what kind of organization would make the most sense moving 
forward, though. Assuming some drivers are included in the core mynewt 
repo instead of being in independent libraries, what would be an ideal 
root location to place them in the file structure?


- hw/drivers/sensors ?



Do we think that 90% of sensors will have a unified interface.  I.e. 
sensors have discoverable channels, and those channels have value types.


sensor_discover(sensor, _chan_types);

assert(sensor_chan_types[0]->type == SENSOR_ACCEL_X);

sensor_read(sensor, 0, _x);

And you can have unified interface to configure these (e.g. 
sensor_config()), that might take an opaque blob, but is pretty 
standard.


If so, I think you have a driver of type: sensor, that defines the 
sensor API, and then you have subdirectories from there, which implement 
the sensor API.


The problem is that hw/drivers already has things like adc and uart 
implementations or nimble which is quite a different concept, though 
it's not entirely inappropriate all the same.




Yeah.  we’re going to have to be very disciplined about how we 
organize this directory and break drivers into groups..  Irregardless of 
where we put sensor, I think this is the case.


And inside sensors (or wherever) you'll have another problem: should 
you have a single flat list of all drivers by device name, or do you 
want to organize them by type/manufacturer/etc.:


 * hw/drivers/sensors/bmp085/*
 * hw/drivers/sensors/bmp280/*
 * hw/drivers/sensors/tsl2651/*
 * hw/drivers/sensors/lsm303dlhc/*
 * hw/drivers/sensors/bno055/*

Or 

Re: [incubator-mynewt-blinky] Git Push Summary

[Sterling Hughes]

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.)


Sterling

On 10 Nov 2016, at 3:36, ccoll...@apache.org wrote:


Repository: incubator-mynewt-blinky
Updated Branches:
  refs/heads/1_0_0_b1_dev [created] ea4b8b8ba

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

[Sterling Hughes]

Hi,

On 7 Nov 2016, at 19:04, Christopher Collins wrote:


On Mon, Nov 07, 2016 at 09:45:48AM -0800, marko kiiskila wrote:
On Nov 7, 2016, at 8:43 AM, Christopher Collins 
 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 

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 :).



I’m fine with either.  I’ve also always adhered to what Marko 
described (separate popular OS project had this as CODING STANDARD), but 
I’m fine changing my habits.


+1 for keeping it consistent: either way.

Sterling

Re: newt and newtmgr versions

[Sterling Hughes]

Hi Kevin,

On 7 Nov 2016, at 9:02, Kevin Townsend wrote:

I'm just migrating over to develop for mynewt-core and the newt tools 
repos, and noticed the following after updating the command line tools 
from develop:


- 'newt version' -> returns 0.9.0 in develop, this should probably be 
0.10.0 to verify that you are using something different than the 
master branch?


+1

- 'newtmgr version' -> doesn't exist. It might be useful to add this 
as a sanity check of sorts when working with multiple branches and 
versions?




+1

It's easy enough to send a pull request for these, but I wanted to 
check if these two items are perhaps intentional and maybe the 0.10.0 
version update only happens at release?




We don’t really have a policy here, which is why the newt version 
hasn’t been updated.  I think once we roll a release, we should always 
update newt to the subsequent version, so that people can differentiate. 
 We might want to have some indicator that it is built off a 
non-released version as well (maybe a build date?)


Sterling

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

[Sterling Hughes]

On 4 Nov 2016, at 16:34, Christopher Collins wrote:

> 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"
>

+1

Let’s get this added to the CODING_STANDARDS

:)

sterling

Re: [DISCUSS] Proposed changes to mynewt website

[Sterling Hughes]

Got it - about the tech docs release. How about the website changes? I 
was proposing we merge that into master for beta.




+1 from me, they look great.

Sterling

Re: [DISCUSS] Proposed changes to mynewt website

[Sterling Hughes]

Hi Aditi,

On 4 Nov 2016, at 12:50, aditi hilbert wrote:


Hi all,

Documentation update is going to be a big part of the Apache Mynewt 
1.0 release since it is featuring several additions and enhancements. 
I would like to propose some changes to the landing page and 
additional links on the project’s website to better cover the the 
salient features of Apache Mynewt OS.


The proposed changes are in the landingFormat branch of the repo:
https://github.com/apache/incubator-mynewt-site/tree/landingFormat

You may checkout this branch and run ‘mkdocs serve’ to view the 
changes.




I’ve done so — the new website looks great.  This is awesome!


The main changes proposed are:
* Focus on the main strengths of the OS in landing page, present them 
in a clean, comprehensive way
* Links under these feature blurbs to additional pages for a deeper 
dive (e.g. to NimBLE highlights or Newt Tool docs)
* Moving the list of supported boards to the bottom so it’s easier 
to keep adding to the list (there will be several added over the 
course of the beta releases leading up to 1.0)
* Link in the nav bar to the “Talks” page highlighting 
presentations around Mynewt OS - looking forward to some contributions 
from the community!


Please provide feedback on the content as well as any other 
enhancements that you would like to see.




I think the “Contributing” section of the community page should be 
moved to our Wiki (and we should have a .md file in the 
incubator-mynewt-newt and incubator-mynewt-core directories that points 
to this as well.)


In general, I think we should find a way to link to the Wiki more 
prominently, and put a bit of effort into updating the Wiki over the 
next month or two.


Also, is it possible to link directly to “file a bug” and feature 
that?  I think we want to make it as easy as possible for users to file 
issues against mynewt.  I think right now it also requires a JIRA 
account, is there a way to work with INFRA to allow for users to 
directly file a bug?


Also note that the Technical Documentation pages are being updated in 
the “develop” branch. A 1.0 beta-1 documentation release branch 
will be created and tagged to go along with the upcoming 1.0 beta-1 
release in the next few days. The tagged documentation will show up as 
a new option in the pull-down menu inside “Documentation”.




I think it makes sense to just do 1.0 and not include the beta here.  We 
won’t want to keep a copy of the documentation for beta around, and 
we’ll likely be actively updating documentation for 1.0 during the 
beta period.


Cheers,

Sterling

Bundling Atmel support

[Sterling Hughes]

Hi,

I’ve noticed on our site we refer to the Arduino Zero, Zero Pro and M0 
Pro as supported platforms, when in fact: Mynewt does not support these 
platforms out of the box — you need to get support for them from 
Runtime externally:


https://github.com/runtimeinc/mynewt_arduino_zero

We’re, of course, happy to contribute Arduino Zero support back to the 
project, however, we haven’t been able to bundle it with Mynewt, 
because of the Atmel Software Framework license, which specifically 
states:


 * 4. This software may only be redistributed and used in connection 
with an

 *Atmel microcontroller product.

I have contacted Atmel about this license, and they have confirmed (in 
email) that Mynewt redistributing these files is not in violation of 
their license.  As these files are used for hardware support on the 
Atmel platform.  However, this license does not work within the context 
of ASF approved licenses.


I’m wondering: can we get an exception from ASF legal?  What would the 
process of doing that be - I imagine we just contact legal@.  I’d 
prefer to have Atmel support in the core, so we can just maintain it 
there, instead of having to synchronize support packages from Runtime.


Sterling

Re: C++ support added to newt

[Sterling Hughes]

In the case of compiling with newlib, _exit was not being resolved 
from libc_stubs.c in the BSP.  I believe this has to do with link 
stage, and adding -specs=nosys.specs does the right thing: but I have 
not tested this.


In general, we should probably look to trim down libc_stubs.c.  With 
this new compiler option, I can completely eliminate this file on the 
NRF52DK BSP.  Ironically, _exit is the only libc stub we actually 
override with anything useful :-)  But I’d be interested in folks 
thoughts here, perhaps we want to keep libc_stubs around for when we 
support other compilers.




I have tested that _exit gets properly resolved, and removed 
libc_stubs.c from all of the BSPs.  They now get libc stubs from GCC, 
and _exit is defined in a new file, hal_common.c to call system_reset().


Sterling

C++ support added to newt

[Sterling Hughes]

Hi,

I’ve added C++ support to Newt in the “develop” branch.

In order to use C++ with newt, the compiler definition files have a new 
entry which is:


compiler.path.cpp: arm-none-eabi-g++ -x c++

And newt will search every package for files that end with *.cpp, *.cxx, 
and *.cc.  I decided not to compile *.C, because I think the case 
insensitivity is a good enough reason not to :-)


In order to use the vast majority of C++ standard libraries, you must 
compile your project without using baselibc, which is not compatible 
with C++.  This will increase code size on your project.  By default, 
we’ve included baselibc as a dependency in most of the BSPs, as it is 
significantly smaller than newlib.  Removing this dependency will remove 
baselibc, and allow you to natively use the C++ standard libraries.


Note: I’ve added a directive to the linker:

compiler.ld.flags: -static -specs=nosys.specs -lgcc -Wl,--gc-sections

-specs=nosys.specs automatically generates weak symbols for the standard 
libc stubs (i.e. _close, _exit, etc.)


In the case of compiling with newlib, _exit was not being resolved from 
libc_stubs.c in the BSP.  I believe this has to do with link stage, and 
adding -specs=nosys.specs does the right thing: but I have not tested 
this.


In general, we should probably look to trim down libc_stubs.c.  With 
this new compiler option, I can completely eliminate this file on the 
NRF52DK BSP.  Ironically, _exit is the only libc stub we actually 
override with anything useful :-)  But I’d be interested in folks 
thoughts here, perhaps we want to keep libc_stubs around for when we 
support other compilers.


sterling

Re: i2c hal API issues and possible modifications

[Sterling Hughes]

I also think the calls to read() and write() should be modified to take 
a flag, which tells whether or not to generate a STOP.


Linux’s I2C APIs take a linked list of commands to pass to the device 
that encompass an I2C “transaction.”  The last element of that 
generates the STOP.


This seems like a nice programming model, but probably too heavyweight 
for a HAL, and if we add a driver interface, we can always layer this on 
top of the HAL interface.


Sterling

On 18 Oct 2016, at 18:08, marko kiiskila wrote:


I would be ok having the extra flag instead of calls to begin/end.

On Oct 18, 2016, at 2:58 PM, Kevin Townsend  
wrote:


I agree designing HALs that play well across vendors is difficult 
since the peripherals have all kinds of limitations and edge cases, 
sometimes even in device families from the same silicon vendor. :(


STOP is the main thing you need full control over though, yes (based 
on my own experience anyway). You can have repeated starts, but some 
sensors will expect: START - READ - STOP - START - WRITE - STOP ... 
and some will expect: START - READ - START - WRITE - STOP, and they 
often won't work as expected using the wrong pattern.


The two gotchas I consistently come across are needing control over 
when the STOP bit is inserted (i.e. having that in the right place in 
the drivers), and more rarely on sensors that use clock stretching 
making sure that the master handles that properly. There are several 
'I2C' peripheral blocks out there that don't handle clock stretching 
properly, though this isn't an API level issue, rather it's a HW 
problem (unless you are bit-banging I2C of course).


K.


On 18/10/16 23:50, will sanfilippo wrote:
Well, I do agree that this new API I am proposing is not as clean as 
the old API; just dont know what else to do. I guess this is part of 
the problem trying to make generic HALs.


At least you will be able to control when the STOP occurs which is 
the most important thing I think.



On Oct 18, 2016, at 1:24 PM, Kevin Townsend  
wrote:


Hi Will,

Having control over when the STOP happens is important since 
different devices will behave differently, especially if you are 
performing a series of events like read/write/read or something 
similar. Some devices expect the STOP to happen in different places 
in a command sequence.


My vote would be a less attractive AP where the stop is a flag. 
Since we apparently aren't using _begin to set the START we may as 
well drop the STOP being handled in _end, but I'm obviously curious 
what other people think here.


Sending multiple STARTS is perfectly valid BTW: 
http://www.i2c-bus.org/repeated-start-condition/


K.

On 18/10/16 21:58, will sanfilippo wrote:

Hello:

I am new to i2c so please bear with me. Hopefully this makes sense 
to the i2c experts out there.


In adding i2c to the nordic platforms I ran across an issue that I 
am not sure how to solve. Well, I know one way to solve it but it 
would require changes to the API. Here is the issue:


In order to get the nordic HW to generate a NACK bit (well, the 
opposite of an ACK) on the 9th bit after a read, you need to do 
something special to the HW prior to reading the last received 
character. When you do this, the HW will generate the correct 9th 
bit and will also put a STOP condition on the line. While it is 
possible to get the HW to generate a STOP independently, I dont 
see how I can get it to generate the correct 9th bit unless you 
know it is the last character you want to read.


Another issue that is bothersome is the nordic SDK itself: when 
you are done with the read it automatically generates the STOP. 
That is fine in and of itself; the SDK could be modified, but the 
issue is that dang 9th bit.


Our API has the following functions:
hal_i2c_master_begin(): Not exactly sure what this does on all 
platforms but currently is a NOOP on the nordic platforms.

hal_i2c_master_write(): generates a start but no stop.
hal_i2c_master_read(): generates a start but no stop.
hal_i2c_master_end(): generates a stop

At first glance, this seems to be a fine API and is easy to see a 
“transaction”: a begin, writes and/or reads chained together, 
and an end. Unfortunately, I could not see how to do this on the 
nordic platforms.


One way to do this would be to get rid of begin/end and have a 
flag in the read/write API. The flag would be “generate stop”. 
This way users can chain reads/writes together and end them with a 
STOP whenever they want. The only con to this is that it is not so 
easy to look at the code to see that transactions have a stop.


Given that I dont have alot of experience wth many i2c devices, I 
dont know if having the ability to skip START and/or address when 
the read/write APIs are called is useful. So far in my limited 
experience the start/address condition between the read/writes is 
not an issue.


So to summarize, here is what I suggest:
* Remove the begin/end API.
* 

Re: SystemView with Mynewt

[Sterling Hughes]

I’ve added a tracking ticket for this to Mynewt Jira 
(https://issues.apache.org/jira/browse/MYNEWT-430).  I think it would be 
great.


Sterling

On 6 Oct 2016, at 9:02, Kevin Townsend wrote:

Has anyone tried to get Segger's SystemView working with Mynewt? 
https://www.segger.com/systemview.html


I suspect most nRF52 devs are using a JLink, and live task tracking 
would be a nice compliment to the stats modules.


I've been meaning to try it out, I just wanted to see if any attempts 
had already been made at wiring the RTOS up to the SystemView API 
already.

Re: Initial impressions.

[Sterling Hughes]

PS: https://issues.apache.org/jira/browse/MYNEWT-424

On 6 Oct 2016, at 13:33, Sterling Hughes wrote:


Glen thanks for the feedback, much appreciated!

I think MCU specific macros make sense to me.  Personally, I’m OK 
going to a schematic and looking up physical pin->port pin mapping, 
depending on silk screen, but the fact that the arduino zero BSP 
starts from 32 for PORTB pins, and you can only find that by reading 
source, is not great.


I’m thinking this is hw/mcu//mcu/mcu.h, and there is a 
convention, i.e. for MCUs that have ports, MCU_PORTA(pin) returns that 
pin.  We should do this for all supported BSPs prior to release.


We’ve also talked about having a Wiki page in the past for all 
supported Mynewt BSPs where people can annotate board pictures, 
instructions, notes, etc.  I really think prior to 1.0 this would be a 
good thing to get going.  There are a lot of blinky tutorials for 
supported platforms, but I think a wiki page will allow people to 
share tips & tricks as well, targeted at specific development boards.


https://cwiki.apache.org/confluence/display/MYNEWT/Board+Support+Packages

It would be great if folks were willing to help out here as well :-)  
So if people are playing with the boards and willing to donate some 
instructions to help this bootstrap - it would be awesome. :-)


Sterling

On 6 Oct 2016, at 9:20, marko kiiskila wrote:


I agree as well. Magic number is a bit too much magic.

MCU specific macros would be my preference.

E.g.
#define PORTA(pin) (pin)
#define PORTB(pin) (16 + pin)

On Oct 5, 2016, at 5:09 PM, David G. Simmons <santa...@mac.com> 
wrote:


Hi Glen,

Thanks for all this feedback. I'm just about to start digging in to 
the documentation in a serious way, and this is very helpful! I will 
add that I had a similar frustration with the pin numbering when I 
was working on a demo a while back and it's something that should 
definitely be at least well documented, if not fixed in the code.


Best regards,
dg

On Oct 5, 2016, at 4:45 PM, Glen Darling <glendarl...@us.ibm.com> 
wrote:


Hello mynewt community,

I am new to mynewt , and at this point I have just managed to get 
mynewt running on an Arduino M0 Pro, with an attached pushbutton on 
one GPIO and an LED with resistor attached on another GPIO pin. My 
first test program just monitors the button and turns the LED on 
whenever the switch is closed. And that all works fine. I also have 
another supported board that I will be introducing to mynewt soon.


My first impressions are very positive. I think I understand what 
you are trying to create with this platform and it's great. Thanks 
for building this!


I'd like to also add that I think the mynewt documentation is 
really excellent in general and I feel I have very quickly been 
able to absorb a good introduction to the platform and get my hands 
dirty. Thank you!


At this point I'd like to make a couple of suggestions based on my 
initial experience.


I found it very difficult to determine the appropriate integer to 
pass to the code to identify a particular GPIO pin on my hardware. 
I Googled for it without success. Eventually I went to the source 
code and found this file in my project 
"repos/mynewt_arduino_zero/hw/mcu/atmel/samd21xx/src/hal_gpio.c". 
That file has a comment that attempts to clarify the numeric 
mapping, but I was unable to follow what it was saying. Eventually 
after hours of hunting I gave up and resorted to trial and error 
and I was able to identify the integers to pass for a handful of 
the GPIO pins. I found this experience to be pretty frustrating.


I think I understand that this comment buried deep in the code is 
where I was expected to get the information I needed. However, it 
was difficult to find, and when found I did not think it did a very 
good job of conveying the information that any developer will 
require to use mynewt on this board to access GPIO pins. I'd like 
to identify this as a weakness in both usability and documentation 
for mynewt that I hope the community will consider addressing.


To be more specific about what I think is missing, I believe any 
developer coming to the mynewt platform with a supported board will 
want to know what pin number to use in the code for a particular 
physical pin on the board. I think only the MCU pins are known in 
mynewt (never the board pins -- okay) and one must consult the 
schematic to find the board pin corresponding to the desired MCU 
pin (okay). However, it's not really the MCU pins that mynewt knows 
about. Mynewt only knows about raw integers that are mapped in some 
ad-hoc way on each board, such that a new mynewt developer will 
need to search the code to discover and then comprehend that 
mapping before they can target a specific MCU pin.


In my opinion, it would be much more helpful if:
1. the mynewt MCU support code could expose symbolic names for MCU 
pins (e.g., for Cortex M0: PA0, PB0, ...) that could be used in 

Re: Initial impressions.

[Sterling Hughes]

Glen thanks for the feedback, much appreciated!

I think MCU specific macros make sense to me.  Personally, I’m OK 
going to a schematic and looking up physical pin->port pin mapping, 
depending on silk screen, but the fact that the arduino zero BSP starts 
from 32 for PORTB pins, and you can only find that by reading source, is 
not great.


I’m thinking this is hw/mcu//mcu/mcu.h, and there is a 
convention, i.e. for MCUs that have ports, MCU_PORTA(pin) returns that 
pin.  We should do this for all supported BSPs prior to release.


We’ve also talked about having a Wiki page in the past for all 
supported Mynewt BSPs where people can annotate board pictures, 
instructions, notes, etc.  I really think prior to 1.0 this would be a 
good thing to get going.  There are a lot of blinky tutorials for 
supported platforms, but I think a wiki page will allow people to share 
tips & tricks as well, targeted at specific development boards.


https://cwiki.apache.org/confluence/display/MYNEWT/Board+Support+Packages

It would be great if folks were willing to help out here as well :-)  So 
if people are playing with the boards and willing to donate some 
instructions to help this bootstrap - it would be awesome. :-)


Sterling

On 6 Oct 2016, at 9:20, marko kiiskila wrote:


I agree as well. Magic number is a bit too much magic.

MCU specific macros would be my preference.

E.g.
#define PORTA(pin) (pin)
#define PORTB(pin) (16 + pin)

On Oct 5, 2016, at 5:09 PM, David G. Simmons  
wrote:


Hi Glen,

Thanks for all this feedback. I'm just about to start digging in to 
the documentation in a serious way, and this is very helpful! I will 
add that I had a similar frustration with the pin numbering when I 
was working on a demo a while back and it's something that should 
definitely be at least well documented, if not fixed in the code.


Best regards,
dg

On Oct 5, 2016, at 4:45 PM, Glen Darling  
wrote:


Hello mynewt community,

I am new to mynewt , and at this point I have just managed to get 
mynewt running on an Arduino M0 Pro, with an attached pushbutton on 
one GPIO and an LED with resistor attached on another GPIO pin. My 
first test program just monitors the button and turns the LED on 
whenever the switch is closed. And that all works fine. I also have 
another supported board that I will be introducing to mynewt soon.


My first impressions are very positive. I think I understand what 
you are trying to create with this platform and it's great. Thanks 
for building this!


I'd like to also add that I think the mynewt documentation is really 
excellent in general and I feel I have very quickly been able to 
absorb a good introduction to the platform and get my hands dirty. 
Thank you!


At this point I'd like to make a couple of suggestions based on my 
initial experience.


I found it very difficult to determine the appropriate integer to 
pass to the code to identify a particular GPIO pin on my hardware. I 
Googled for it without success. Eventually I went to the source code 
and found this file in my project 
"repos/mynewt_arduino_zero/hw/mcu/atmel/samd21xx/src/hal_gpio.c". 
That file has a comment that attempts to clarify the numeric 
mapping, but I was unable to follow what it was saying. Eventually 
after hours of hunting I gave up and resorted to trial and error and 
I was able to identify the integers to pass for a handful of the 
GPIO pins. I found this experience to be pretty frustrating.


I think I understand that this comment buried deep in the code is 
where I was expected to get the information I needed. However, it 
was difficult to find, and when found I did not think it did a very 
good job of conveying the information that any developer will 
require to use mynewt on this board to access GPIO pins. I'd like to 
identify this as a weakness in both usability and documentation for 
mynewt that I hope the community will consider addressing.


To be more specific about what I think is missing, I believe any 
developer coming to the mynewt platform with a supported board will 
want to know what pin number to use in the code for a particular 
physical pin on the board. I think only the MCU pins are known in 
mynewt (never the board pins -- okay) and one must consult the 
schematic to find the board pin corresponding to the desired MCU pin 
(okay). However, it's not really the MCU pins that mynewt knows 
about. Mynewt only knows about raw integers that are mapped in some 
ad-hoc way on each board, such that a new mynewt developer will need 
to search the code to discover and then comprehend that mapping 
before they can target a specific MCU pin.


In my opinion, it would be much more helpful if:
1. the mynewt MCU support code could expose symbolic names for MCU 
pins (e.g., for Cortex M0: PA0, PB0, ...) that could be used in the 
code so developers would not need to dig through mynewt board 
support code to discover and comprehend those numeric mappings, 

Re: Improve Unit Tests and Test Suite Output

[Sterling Hughes]

Hi,

I don’t think we planned on providing a mock’ing framework in V1 of 
Mynewt.  The approach to mocking has been to implement the lower layers 
on sim, and then special case things where it only makes sense for a 
particular regression or unit test.  While you won’t get the control 
you have with mocking (i.e. guaranteed set of responses to external 
function calls), it does allow for a fair number of regression tests to 
run simulated — and should catch the vast majority of cases.


Going forward, it does sound like having this ability would be useful.  
If somebody wanted to provide a patch to newt, that allows it to either 
use an external framework like CMock, or generate a set of mock 
templates itself, I think it would be a great contribution!


Sterling

On 3 Oct 2016, at 12:26, hathach wrote:


Hi all,

I previously used CMock & Unity as unit testing framework for my own 
project. CMock is rather complex since it allows mocking the lower 
layers thus isolating module and making it easy for testing/probing 
its behavior.


For example, when testing an service-adding function, all we care 
about is the ble_gatts_register_svcs()  finally invoked with the exact 
same svc_def. Behavior of ble_gatts_register_svcs() is subject to its 
own unit testing.


Though newt's testutil is still in developing stage, do we have a plan 
to implement some level of mocking framework like CMock. Since it will 
be a challenge to simulate lower layer and stimulate some certain 
scenario.


PS: I found even with mocking, it is also hard to do decent coverage 
of unit test with stuffs like peripherals. And the integration test is 
completely out of control :(


On 03/10/2016 22:42, Christopher Collins wrote:

Hi Kevin,

On Mon, Oct 03, 2016 at 03:08:32PM +0200, Kevin Townsend wrote:

I was wondering if there were any suggestions on how it might be
possible to improve the output of the unit tests to be a bit more
verbose, following some of the other frameworks out there for 
embedded

systems like CMOCK.

Unit testing and test simulation is an important part of the system 
for

any professionally maintained project, but could be even more useful
with a little bit of refinement.

Personally, I find it useful to see a list of tests being run and 
maybe
spot if I missed a module, and to know how many tests were run, 
etc., so

something like this when running the test suite(s)?

 Running 'TestSuiteName' test suite:
Running 'Test Name' ... [OK][FAILED]
Running 'Test Name' ... [OK][FAILED]
[n] unit tests passed, [n] failed

 Running 'TestSuiteName' test suite:
Running 'Test Name' ... [OK][FAILED]
Running 'Test Name' ... [OK][FAILED]
[n] unit tests passed, [n] failed

 Ran [n] unit tests in [n] test suites
 [n] unit tests passed, [n] failed

It's a poor example that needs more thought, but I was interested in
getting the discussion started.
The thinking was that the user doesn't want to be bothered with a 
bunch

of text when there are no failures.  That said, I agree that more
verbose output in the success case would be useful in some cases.  
You
can get something kind of like your example if you provide the 
-ldebug

command line option when you run the test, e.g.,

 newt -ldebug test net/nimble/host
 Executing test:
 
/home/ccollins/repos/mynewt/core/bin/targets/unittest/net_nimble_host_test/test/net/nimble/host/test/net_nimble_host_test
 2016/10/03 08:00:49 [DEBUG]
 
/home/ccollins/repos/mynewt/core/bin/targets/unittest/net_nimble_host_test/test/net/nimble/host/test/net_nimble_host_test
 2016/10/03 08:00:50 [DEBUG] o=[pass]
 ble_att_clt_suite/ble_att_clt_test_tx_find_info
 [pass] ble_att_clt_suite/ble_att_clt_test_rx_find_info
 [pass] ble_att_clt_suite/ble_att_clt_test_tx_read
 [...]
 [pass] 
ble_sm_sc_test_suite/ble_sm_sc_peer_nc_iio1_rio1_b1_iat2_rat2_ik3_rk3
 [pass] 
ble_sm_sc_test_suite/ble_sm_sc_peer_pk_iio2_rio0_b1_iat2_rat2_ik7_rk3
 [pass] 
ble_sm_sc_test_suite/ble_sm_sc_us_jw_iio3_rio3_b1_iat2_rat2_ik3_rk3
 [pass] 
ble_sm_sc_test_suite/ble_sm_sc_us_nc_iio1_rio1_b1_iat2_rat2_ik3_rk3
 [pass] 
ble_sm_sc_test_suite/ble_sm_sc_us_pk_iio2_rio0_b1_iat2_rat2_ik7_rk3

 [pass] ble_uuid_test_suite/ble_uuid_test_128_to_16

 Passed tests: [net/nimble/host/test]
 All tests passed

The output is a bit rough, and -ldebug produces a lot of extra output
that is not relevant, so there is some work to do here.  As an aside, 
I
think newt is not very consistent with its "-v" and "-ldebug" 
options.
As I understand it, "-v" is supposed to produce extra output about 
the
user's project; "-ldebug" is meant for debugging the newt tool 
itself,

and is supposed to generate output relating to newt's internals.

Also, having a 'startup' and 'teardown' function that runs before 
and

after every unit test in the test suite may be nice as well to clear
any variables or put things into a known state, but I'm 

Re: Directory re-org in develop

[Sterling Hughes]

Yep.  That’s the one - Marko and Paul are working this.

Marko just moved it into net/oic.  Paul/Marko have taken iotivity 
constrained and plumbed it into Mynewt.


mgmt/mgmt is now the generic system interface to management APIs to 
return data.  These APIs return responses as key-value pairs, that can 
either be encoded in JSON or CBOR.


mgmt/newtmgr is the existing newtmgr protocol, and the newtmgr facade 
runs over this.  newtmgr is smaller in code size than oic, but is very 
mynewt specific as a transport technology.


mgmt/oicmgr is the mgmt/mgmt handlers transported over the OIC/OCF 
implementation referenced below.


NOTE: for OIC, Marko/Paul haven’t don’t include 6low/IPSP/DTLS over 
BLE, but rather just assume we’re going to run CoAP natively over the 
GATT transport, at least by default (and to start with, it may make 
sense to have this option later.)  There is a WG in OIC underway that is 
looking to standardize this approach - as BLE packets are a little small 
to justify the full IP/DTLS payload.


Sterling

On 5 Oct 2016, at 10:13, Wayne Keenan wrote:


Hiya,

The OIC and OCF to which you refer, is it this?:
https://openconnectivity.org/resources/specifications

All the best
Wayne

On 29 September 2016 at 16:50, Sterling Hughes <sterl...@apache.org> 
wrote:



Hey,

On 29 Sep 2016, at 7:42, James Pace wrote:




imgmgr, and newtmgr could be broken into a TLD mgmt/ directory.  
They

could also be put into “sys.”  Other suggestions?



+1 for /mgmt


OK. mgmt carries the day.  I really don’t like the name, so if you 
have

any other suggestions (I don’t.)

I think iotivity should go into net/ as a sibling to nimble and ip 
(maybe

rename to oic?)  We should also break out and maintain the coap
implementation from iotivity as another sibling in the net/ 
directory.




+1



+1, too, on the rename to “oic". although, bear in mind that this 
will

become “ocf” with the next rev.


OCF it is.  I hope they follow suite when they implement the next 
rev, and

don’t decided to separately name the specs from the standards org.

Sterling

Version on statistics structures

[Sterling Hughes]

As I’m going through the statistics module and documenting it, one 
thing that occurs to me is for the case where STATS_NAME_ENABLE = 0, and 
statistic names are omitted, we should create the statistic name -> 
number mapping, in the target’s directory, in a machine parseable 
format (i.e. JSON.) I’m thinking we should put this into the 
manifest.json when we create an image, that way if a management system 
wants to ingest this data, it can easily take this information, along 
with the created image.


I thought about versioning the structure, however decided against it, 
because:


- Manually updating the statistics version when it changes is error 
prone, because people forget to change version numbers


- I think it is likely that any management system or user who wants to 
interpret these values, will likely have the image definition for that 
image, _AND_ will probably not do an exhaustive search of all images, to 
find one that has a matching definition of version of statistics that 
are found on that device.  (likely:)


Comments welcome.  Below is the documentation I’ve written at the top 
of the module.


NOTE: Newt does not yet support generating statistics mappings in the 
manifest.json, I’m adding that support to create-image now.


Best,

Sterling

/**
 * Declare an example statistics section, which is fittingly, the 
number
 * statistics registered in the system.  There are two, largely 
duplicated,

 * statistics sections in order to provide the optional ability to
 * name statistics.
 *
 * STATS_SECT_START/END actually declare the statistics structure 
definition,
 * STATS_SECT_DECL() creates the structure declaration so you can 
declare
 * these statistics as a global structure, and STATS_NAME_START/END are 
how

 * you name the statistics themselves.
 *
 * Statistics entries can be declared as any of the following values, 
however,
 * all statistics in a given structure must be of the same size, and 
they are

 * all unsigned.
 *
 * - STATS_SECT_ENTRY(): default statistic entry, 32-bits.  This
 *   is the good stuff. Two factors to consider:
 *   - With 16-bit numbers, rollovers happen, frequently.  Whether 
its
 *   testing a pathological condition, or just a long time since 
you've
 *   collected a statistic: it really sucks to not have a crucial 
piece

 *   of information.
 *   - 64-bit numbers are wonderful things.  However, the gods did 
not see
 *   fit to bless us with unlimited memory.  64-bit statistics are 
useful
 *   when you want to store non-statistics in a statistics entry 
(i.e. time),

 *   because its convenient...
 *
 * - STATS_SECT_ENTRY16(): 16-bits.  Smaller statistics if you need to 
fit into

 *   specific RAM or code size numbers.
 *
 * - STATS_SECT_ENTRY32(): 32-bits, if you want to force it.
 *
 * - STATS_SECT_ENTRY64(): 64-bits.  Useful for storing chunks of data.
 *
 * Following the statics entry declaration is the statistic names 
declaration.
 * This is compiled out when STATS_NAME_ENABLE is set to 0.  This 
declaration

 * is const, and therefore can be located in .text, not .data.
 *
 * In cases where the system configuration variable STATS_NAME_ENABLE 
is set
 * to 1, the statistics names are stored and returned to both the 
console
 * and management APIs.  Whereas, when STATS_NAME_ENABLE = 0, these 
statistics
 * are numbered, s0, s1, etc.  The newt tool will create a list of 
statistic #

 * -> statistic name in the
 *  bin/targets//app/apps//manifest.json file.
 * That way, in cases where you want to save on code size, you can 
store the
 * manifest file for the image you've generated, and management tools 
will

 * be able to display the named statistic from the map.
 */
STATS_SECT_START(stats)
STATS_SECT_ENTRY(num_registered)
STATS_SECT_END

STATS_SECT_DECL(stats) g_stats_stats;

STATS_NAME_START(stats)
STATS_NAME(stats, num_registered)
STATS_NAME_END(stats)

Re: MIPS port (WIP)

[Sterling Hughes]

Julian,

Awesome!!  It would be great to get this into 1.0-beta1 (thinking code 
complete in 2 weeks) if at all possible.


Also, if you’re taking further requests, I’d love to see a PIC32 
running Mynewt as well. :-)


Sterling

On 4 Oct 2016, at 8:00, Julian Ingram wrote:


Hello all,

I have just committed a work in progress MIPS port here: 
https://github.com/IMGJulian/incubator-mynewt-core/tree/julian_dev


I am currently working on some tests, and will make a pull request 
soon with a more polished version.


Thanks,

Julian Ingram
Software Design Engineer
MIPS Platforms
Imagination Technologies Limited
t: +44 (0)113 2429814
www.imgtec.com

Directory re-org in develop

[Sterling Hughes]

Howdy,

So the directory re-org is now committed in develop: it’s a fairly 
large, BC breaking set of changes.


Please review the new structure, and use this opportunity to discuss 
anything you don’t like.


There are a few directories I did _not_ move, mainly for lack of a good 
place to put them, specifically:


$ ll core/libs
total 0
drwxr-xr-x  5 sterling  staff  170 Sep 28 18:31 imgmgr
drwxr-xr-x  5 sterling  staff  170 Sep 28 18:31 iotivity
drwxr-xr-x  7 sterling  staff  238 Sep 28 18:31 newtmgr
drwxr-xr-x  5 sterling  staff  170 Sep 28 18:31 newtmgr_oic
drwxr-xr-x  5 sterling  staff  170 Sep 28 18:52 util
$

I’m not sure where imgmgr (image upgrade), newtmgr (system 
management), and the iotivity (OIC protocol) should go.


My random thoughts:

imgmgr, and newtmgr could be broken into a TLD mgmt/ directory.  They 
could also be put into “sys.”  Other suggestions?


I think iotivity should go into net/ as a sibling to nimble and ip 
(maybe rename to oic?)  We should also break out and maintain the coap 
implementation from iotivity as another sibling in the net/ directory.


I’ve been breaking apart “libs/util” into a set of utility 
packages in a TLD “util.”  Should we remove these, we can get rid of 
the libs directory altogether, which would be nice.


Cheers,

Sterling

Re: hal watchdog

[Sterling Hughes]

2 reasons:

- most (all) chips provide that granularity that i’ve seen, so why 
not?  IMO, it’s not up for us to decide what people set watchdog 
interval to in the HAL if it’s portable.


- as you point out, it’s convenient to have a consistent timebase 
between sanity and watchdog, given how i’ve staggered the 
wakeup/watchdog tickle.


I worried about that too, BTW: the default is 500msecs, I just assert if 
it’s less than 200 msecs in os.c


sterling

On 23 Sep 2016, at 10:51, will sanfilippo wrote:

Why is the interval defined in milliseconds btw? Is there a particular 
reason for it? Is it because you wanted to be able to separate the 
sanity interval and the watchdog interval by less than one second? Or 
are you worried that some watchdogs may have very small timeouts and 
milliseconds would be useful? Just curious… and you can probably 
tell from my curiosity that seconds seems to be enough resolution but 
this is really no big deal.


I also worry (slightly) that the default time between sanity waking up 
and the watchdog firing may not be enough. It is configurable so that 
is all good, but maybe the default should be a bit longer as sanity is 
checked in the idle task and if a system has lots of tasks the idle 
task may not run for a bit (although 200 msecs is a while).


On Sep 22, 2016, at 10:58 PM, Sterling Hughes <sterl...@apache.org> 
wrote:


Hey —

A follow up on this, I’ve committed initial support for the Nordic 
platforms for the watchdog, along with modifying this API a bit.


I made the watchdog expiry a millisecond value (in 
hal_watchdog_init()), as pretty much every watchdog I’ve seen 
executes in millisecond resolution.  I removed the 
hal_watchdog_stop() function, as many processors don’t offer the 
ability to stop the watchdog once started.


I also hooked the watchdog into the OS with two new configuration 
options:


   SANITY_INTERVAL:
   description: 'The interval at which the sanity checks should 
run, should be at least 200ms prior to watchdog'

   value: 299500
   WATCHDOG_INTERVAL:
   description: 'The interval at which the watchdog should reset 
if not tickled, in ms'

   value: 30

These are default values, defined by the OS (libs/os/pkg.yml), that 
can be overridden by the BSP.


By default the OS initializes the watchdog with hal_watchdog_init() 
when OS start is called.  I have removed the sanity task (to save 
stack space, and make it run by default), and instead, put all sanity 
related functions within the idle task.


The logic is here (os.c), for reference.  os_sanity_run() calls into 
os_sanity.c, and runs the sanity checks.  Code has also been added to 
make sure that we don’t sleep beyond the sanity interval, and trip 
up the watchdog in our idle loop.


   sanity_itvl_ticks = (MYNEWT_VAL(SANITY_INTERVAL) * 
OS_TICKS_PER_SEC) / 1000;

   sanity_last = 0;

   hal_watchdog_tickle();

   while (1) {
   ++g_os_idle_ctr;

   now = os_time_get();
   if (OS_TIME_TICK_GT(now, sanity_last + sanity_itvl_ticks)) {
   os_sanity_run();
   /* Tickle the watchdog after successfully running sanity 
*/

   hal_watchdog_tickle();
   sanity_last = now;
   }

   OS_ENTER_CRITICAL(sr);
   now = os_time_get();
   sticks = os_sched_wakeup_ticks(now);
   cticks = os_callout_wakeup_ticks(now);
   iticks = min(sticks, cticks);
   /* Wakeup in time to run sanity as well from the idle context,
* as the idle task does not schedule itself.
*/
   iticks = min(iticks, ((sanity_last + sanity_itvl_ticks) - 
now));


   if (iticks < MIN_IDLE_TICKS) {
   iticks = 0;
   } else if (iticks > MAX_IDLE_TICKS) {
   iticks = MAX_IDLE_TICKS;
   } else {
   /* NOTHING */
   }
   /* Tell the architecture specific support to put the processor 
to sleep

* for 'n' ticks.
*/
   os_tick_idle(iticks);
   OS_EXIT_CRITICAL(sr);


For BSPs where hal_watchdog has not been implemented, calling these 
functions has no effect, and I’ve added stubs to the stm32f4 and 
native BSPs.


Sterling


On 30 Aug 2016, at 15:01, marko kiiskila wrote:



On Aug 30, 2016, at 12:59 PM, Mathew Calmer 
<mcal...@exploramednc7.com> wrote:


On August 30, 2016 at 12:28:50 PM, will sanfilippo 
(wi...@runtime.io<mailto:wi...@runtime.io>) wrote:
Sounds reasonable. As I am sure you know, doing it through the 
sanity task sometimes is an issue getting the time right as you 
would then need to know the worst-case timing of all the tasks that 
could be running… but any way you cut it, you have to put some 
time limit on that… in past lives I have seen some pretty 
complicated ways to deal with this but this seems reasonable and if 
developers need something different they can implement it with this 
hal.




I would consider making the return value of init() be the time or 
some reference to the time that was actually set.  So, for ex

Re: newtmgr over Serial

[Sterling Hughes]

No worries: try setting the feature vs CFLAGS.  (Note: all good efforts 
learning about features will be unfortunately useless, as we’ve 
changed to sys config in develop :-( ).


# clear cflags
newt target set bootloader cflags=
# set feature
newt target set bootloader features=BOOT_SERIAL

That will enable extra dependencies and automatically set cflags.   I 
believe marko also had a comment in the pkg.yml about uncommenting 
libs/console/stub — worth looking at that if you have conflicts with 
console after enabling the BOOT_SERIAL feature.


On 23 Sep 2016, at 9:20, Kevin Townsend wrote:


Hi Sterling,

Thanks for the heads up. I added the cflag via '$ newt target set 
bootloader cflags=-DBOOT_SERIAL' and I can see that it exists in 
'/repos/apache-mynewt-core/libs/boot_serial', though when I try to 
build I'm getting:


   $ newt build bootloader
   Building target targets/bootloader
   Compiling boot.c
   Error: boot.c:33:37: fatal error: boot_serial/boot_serial.h: No 
such

   file or directory
 #include 
 ^
   compilation terminated.

The target definition seems fine though (I'm on the 'master' branch 
just as a FYI):


   $ newt target show
   targets/bootloader
app=@apache-mynewt-core/apps/boot
bsp=hw/bsp/feather52
build_profile=optimized
cflags=-DBOOT_SERIAL

I also tried 'newt install' and 'newt upgrade' to refresh the local 
setup but same results. Perhaps I need to update something in the 
local BSP, though ... I'll have a look at that.


Thanks for the heads up about this library, though. Somehow it never 
ended up on my radar, but I'll try to get this building and test it 
out this weekend.


BR,

Kevin

Re: newtmgr over Serial

[Sterling Hughes]

Hi Kevin,

I think (and I’ll let Marko chime in here), you can use the 
boot_serial package to achieve this 
(apache-mynewt-core/libs/boot_serial.)


It speaks the newtmgr protocol, but doesn’t require the shell task or 
an image to be programmed.  I think it will slightly explode the size of 
your boot loader, but that shouldn’t be a huge issue on the NRF52.


apps/boot/ has the following options.

#
# Define BOOT_SERIAL in target features to include serial downloader.
# And uncomment 'libs/console/stub' from pkg.deps.
#
pkg.deps.BOOT_SERIAL.OVERWRITE:
- libs/console/full
- libs/boot_serial
pkg.cflags.BOOT_SERIAL:
- -DBOOT_SERIAL

It’s (unfortunately) been awhile since I’ve tested this, but we’ll 
take a look today and make sure it’s still functioning (it should be.)


Sterling

On 23 Sep 2016, at 2:46, Kevin Townsend wrote:


Hi Will (and company),

Sorry to recycle an old thread, but I was just doing some testing with 
the bootloader on the latest release, and wanted to come back to the 
issue of having a purely serial option for flashing images in the 
bootloader. From my perspective there are a number of valid use cases 
around uploading an image on an empty device (other than the 
bootloader) over UART or USB CDC, but others may disagree.


This would provide an inexpensive mechanism to debrick boards, for 
example, as well as a useful tool for production environments where 
you don´t have the financial or practical means to send a half dozen 
commercially licensed JLink to your assembly house or somewhere in 
China for testing then flashing.


Being able to run something like this with ONLY the bootloader present 
would be a big plus I think:


$ newtmgr -c serial image upload 
bin/bleuart/apps/bleuart/bleuart.elf.bin


As things stand today, you can only do this (I think, please correct 
me if I´m wrong) if you already have a valid image flashed and shell 
support enabled for newtmgr.


Is there an obstacle anyone can see about why this wouldn't be 
practical to implement with only the bootloader present? We've been 
focused on application level code and the peripheral side of nimble so 
I haven't looked at the bootloader code at all, but will have a look 
to try to get a better sense of the requirements here to use it with 
serial without any sort of shell support on the application side.


K.

On 08/06/16 23:59, will sanfilippo wrote:

+1

Guess that is my one cent opinion :-) Wouldnt be hard to do and is 
definitely a handy option for a certain group of folks. BTW, and this 
is a minor detail, I am not so much for polling a pin; the bootloader 
can look at the serial port for a certain sequence of characters. If 
it sees them it enters download mode. If it doesnt see anything it 
likes after that (or doesnt see that sequence), it tries to boot an 
image. If it cant, it just cycles back. If it boots a valid image, 
all good. If it boots a bricked image, you just gotta power cycle it. 
Shouldnt increase boot time too much (which is something to keep in 
mind imo).


On Jun 8, 2016, at 12:42 PM, marko kiiskila  
wrote:


I’m convinced that we should have an option for using standalone 
boot loader

with which you can upload images. These are valid use cases.

We should make that happen.

Re: hal watchdog

[Sterling Hughes]

Hey —

A follow up on this, I’ve committed initial support for the Nordic 
platforms for the watchdog, along with modifying this API a bit.


I made the watchdog expiry a millisecond value (in hal_watchdog_init()), 
as pretty much every watchdog I’ve seen executes in millisecond 
resolution.  I removed the hal_watchdog_stop() function, as many 
processors don’t offer the ability to stop the watchdog once started.


I also hooked the watchdog into the OS with two new configuration 
options:


SANITY_INTERVAL:
description: 'The interval at which the sanity checks should 
run, should be at least 200ms prior to watchdog'

value: 299500
WATCHDOG_INTERVAL:
description: 'The interval at which the watchdog should reset 
if not tickled, in ms'

value: 30

These are default values, defined by the OS (libs/os/pkg.yml), that can 
be overridden by the BSP.


By default the OS initializes the watchdog with hal_watchdog_init() when 
OS start is called.  I have removed the sanity task (to save stack 
space, and make it run by default), and instead, put all sanity related 
functions within the idle task.


The logic is here (os.c), for reference.  os_sanity_run() calls into 
os_sanity.c, and runs the sanity checks.  Code has also been added to 
make sure that we don’t sleep beyond the sanity interval, and trip up 
the watchdog in our idle loop.


sanity_itvl_ticks = (MYNEWT_VAL(SANITY_INTERVAL) * 
OS_TICKS_PER_SEC) / 1000;

sanity_last = 0;

hal_watchdog_tickle();

while (1) {
++g_os_idle_ctr;

now = os_time_get();
if (OS_TIME_TICK_GT(now, sanity_last + sanity_itvl_ticks)) {
os_sanity_run();
/* Tickle the watchdog after successfully running sanity */
hal_watchdog_tickle();
sanity_last = now;
}

OS_ENTER_CRITICAL(sr);
now = os_time_get();
sticks = os_sched_wakeup_ticks(now);
cticks = os_callout_wakeup_ticks(now);
iticks = min(sticks, cticks);
/* Wakeup in time to run sanity as well from the idle context,
 * as the idle task does not schedule itself.
 */
iticks = min(iticks, ((sanity_last + sanity_itvl_ticks) - 
now));


if (iticks < MIN_IDLE_TICKS) {
iticks = 0;
} else if (iticks > MAX_IDLE_TICKS) {
iticks = MAX_IDLE_TICKS;
} else {
/* NOTHING */
}
/* Tell the architecture specific support to put the processor 
to sleep

 * for 'n' ticks.
 */
os_tick_idle(iticks);
OS_EXIT_CRITICAL(sr);


For BSPs where hal_watchdog has not been implemented, calling these 
functions has no effect, and I’ve added stubs to the stm32f4 and 
native BSPs.


Sterling


On 30 Aug 2016, at 15:01, marko kiiskila wrote:



On Aug 30, 2016, at 12:59 PM, Mathew Calmer 
 wrote:


On August 30, 2016 at 12:28:50 PM, will sanfilippo 
(wi...@runtime.io) wrote:
Sounds reasonable. As I am sure you know, doing it through the sanity 
task sometimes is an issue getting the time right as you would then 
need to know the worst-case timing of all the tasks that could be 
running… but any way you cut it, you have to put some time limit on 
that… in past lives I have seen some pretty complicated ways to 
deal with this but this seems reasonable and if developers need 
something different they can implement it with this hal.




I would consider making the return value of init() be the time or 
some reference to the time that was actually set.  So, for example, 
if the user asks for 1 ticks, and the system can only support 
2000, it could return 2000 from init, after trying it’s best to 
support the request.


It could be done in powers of two or some other mechanism, but 
conceptually using that return value to explain what was actually set 
would be a nice interface.   If watchdog was not implemented on given 
hardware, default return could be negative (error) or 0, implying 
watchdog was not set (although 0 also implies success… so…).




I was thinking the same regarding return value from init(), but had 
not written it down in the

API proposal.

I’m including updated version here.

/*
 * Set a recurring watchdog timer to fire no sooner than in 
'expire_secs'

 * seconds. Watchdog should be tickled periodically with a frequency
 * smaller than 'expire_secs'. Watchdog needs to be then started with
 * a call to hal_watchdog_enable().
 *
 * @param expire_secs   Watchdog timer expiration time
 *
 * @return  < 0 on failure; on success return the 
actual

 *  expiration time as positive value
 */
int hal_watchdog_init(int expire_secs);

/*
 * Starts the watchdog.
 *
 * @return  0 on success; non-zero on failure.
 */
int hal_watchdog_enable(void);

/*
 * Stops the watchdog.
 *
 * @return  0 on success; 

Re: Switching to Master

[Sterling Hughes]

Hi,

On 21 Sep 2016, at 8:22, Kevin Townsend wrote:



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.

0-dev seems to match the intent based on the comments here, and seems 
like a good match to me.


I did try pointing to "master" with a new entry but got the error 
below, but perhaps it is looking for a tag not a branch name:


   $ newt upgrade
   Error: Unknown stability (master) in version 0-master

I simply added '"0-master": "master"' as a quick test before deleting 
the project.state file and running the upgrade command above.




Upgrade will pull the repository.yml from apache-mynewt-core/master 
branch directly (for the apache-mynewt-core repository, if you have a 
custom repository, it will pull that repo’s repository.yml.)


To add a tracking tag to your own repo, there are two components.

1- You need to add a “real” version (without the stability tag).  
That real version should point to the git branch. Above we have:


"0.0.0": "develop"

2- Then you can add a tracking tag, by pointing the vers+stability 
entry, at that “real” version:


“0-master”: “0.0.0”

You cannot point a tracking tag directly at a git branch.  We’ve 
hacked this a bit for develop, but in general, the goal of the tracking 
tag is to switch between released versions of Mynewt (i.e. I want to 
track on 1.1-latest and get all minor revision updates, which by our 
release policy are guaranteed to be bug fixes.)


Cheers,

Sterling

Re: Directory re-org conversation

[Sterling Hughes]

I was suggesting it be moved to hw/drivers/nimble.

It’s similar to how other OSes do it, they tend to have the hw drivers 
in the drivers directory, even for the networking stack components.  I 
don’t feel strongly about it, but thought, why shouldn’t we keep to 
convention.


I definitely think the HW drivers should use our device framework, 
unless there is a compelling reason not to.  It will allow there to be a 
central registry of drivers, and if the BT stack needs to be 
suspended/resumed, that’s a logical place to hook it in?


Sterling

On 15 Sep 2016, at 18:39, will sanfilippo wrote:

Just a nit; I need to digest this a bit more but will 
net/nimble/drivers be moved to drivers/nimble or hw/drivers/nimble?


I am also not sure why you would move what is in there into the 
drivers directory and make it conform to the standard drivers as I am 
not sure what that would mean for the BLE stack but we could do it if 
folks thought it a good idea.


On Sep 15, 2016, at 3:50 PM, Sterling Hughes <sterl...@apache.org> 
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.)


Please take this as a _rough_ first cut proposal.  I want people to 
bikeshed this discussion, mainly because I only want to do this 
re-org once in the foreseeable future :-)


Proposed changes (on top of the sterly_refactor and develop branch.)

- IP and Wi-Fi support is moved from libs (e.g. 
libs/inet_def_service, libs/wifi_mgmt) and placed in the net/ 
directory.


- Any IP stack is moved into net/ip

- net/nimble/drivers is moved to drivers/nimble.  These drivers are 
modified to conform to our driver framework.


- libs/tinycrypt and libs/mbedtls are placed in crypto/mbedtls, 
crypto/tinycrypt


- libs/bleuart is placed in net/nimble/host/profiles

- libs/bootutil, libs/boot_serial are both placed in boot/ along with 
apps/boot


- elua is completed removed from mynewt-core.  mynewt-core should 
provide the core engine for any scripting language (JS, Lua, Python), 
but not bundle one by default.


- drivers is moved to hw/drivers, libs/cmsis-core is moved to 
hw/arch/arm/cmsis-core


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

- libs/console and libs/shell are moved to sys/console and sys/shell

- examples/ TLD is created, and libs/flash_test, libs/crash_test, 
apps/blecent, apps/bleprph, apps/bletest, apps/bletiny, apps/bleuart, 
apps/blinky, apps/slinky are all moved to examples.


- libs/os is moved to TLD “os” (or core/os? kern/os?)

- libs/testreport and libs/testutil are moved to a TLD “test/“

- libs/util is broken up into crypto/hash (base64, crc), 
time/datetime (datetime.c), and TPQ is deleted (where do we put 
cbmem?  sys/defs? I think we should probably migrate queue.h from OS 
there too.)


- libs/imgmgr moved to mgmt/, libs/newtmgr moved to 
frameworks/newtmgr


- coap broken out of libs/iotivity and placed into net/.

- libs/iotivity broken into frameworks/oic.

- sys/mn_socket is moved to net/

- sys/reboot: should this be moved to boot or somewhere else, or just 
remain in sys/


Best,

Sterling

Directory re-org conversation

[Sterling Hughes]

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.)


Please take this as a _rough_ first cut proposal.  I want people to 
bikeshed this discussion, mainly because I only want to do this re-org 
once in the foreseeable future :-)


Proposed changes (on top of the sterly_refactor and develop branch.)

- IP and Wi-Fi support is moved from libs (e.g. libs/inet_def_service, 
libs/wifi_mgmt) and placed in the net/ directory.


- Any IP stack is moved into net/ip

- net/nimble/drivers is moved to drivers/nimble.  These drivers are 
modified to conform to our driver framework.


- libs/tinycrypt and libs/mbedtls are placed in crypto/mbedtls, 
crypto/tinycrypt


- libs/bleuart is placed in net/nimble/host/profiles

- libs/bootutil, libs/boot_serial are both placed in boot/ along with 
apps/boot


- elua is completed removed from mynewt-core.  mynewt-core should 
provide the core engine for any scripting language (JS, Lua, Python), 
but not bundle one by default.


- drivers is moved to hw/drivers, libs/cmsis-core is moved to 
hw/arch/arm/cmsis-core


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

- libs/console and libs/shell are moved to sys/console and sys/shell

- examples/ TLD is created, and libs/flash_test, libs/crash_test, 
apps/blecent, apps/bleprph, apps/bletest, apps/bletiny, apps/bleuart, 
apps/blinky, apps/slinky are all moved to examples.


- libs/os is moved to TLD “os” (or core/os? kern/os?)

- libs/testreport and libs/testutil are moved to a TLD “test/“

- libs/util is broken up into crypto/hash (base64, crc), time/datetime 
(datetime.c), and TPQ is deleted (where do we put cbmem?  sys/defs? I 
think we should probably migrate queue.h from OS there too.)


- libs/imgmgr moved to mgmt/, libs/newtmgr moved to frameworks/newtmgr

- coap broken out of libs/iotivity and placed into net/.

- libs/iotivity broken into frameworks/oic.

- sys/mn_socket is moved to net/

- sys/reboot: should this be moved to boot or somewhere else, or just 
remain in sys/


Best,

Sterling

Merge of sterly_refactor -> develop in _1 WEEK_

[Sterling Hughes]

Hey,

I think sterly_refactor is getting pretty close to ready.  Chris & Vipul 
are working on some final items (updating to Will’s latest SPI 
changes, and finishing the ADC driver for the STM32F4 boards.)


I’d like to merge sterly_refactor into develop in 1 week, this will 
likely lead to some instability in develop for a week or so.  IMO, 
that’s consistent with our branching strategy where “master” is 
designed to be stable latest.  SO, if you’re following along with 
develop: be aware, some instability will be introduced, and please 
switch to master if you want to avoid it (now is a good time.)


Changes in sterly_refactor:

- Import of chip vendor packages in an “ext” directory, and a new 
package type of SDK.

- These include newt changes to support this
	- An example of a driver pack import is the Nordic pack here: 
https://github.com/apache/incubator-mynewt-core/tree/sterly_refactor/hw/mcu/nordic
	- you can find the files in src/ext/*, and the compile definitions in 
pkg.yml


- Introduction of a drivers framework:
	- Devices: 
https://github.com/apache/incubator-mynewt-core/blob/sterly_refactor/libs/os/src/os_dev.c
	- Example drivers: 
https://github.com/apache/incubator-mynewt-core/tree/sterly_refactor/drivers


- Refactoring of the HAL:
	- As a refresher, previously the HAL was meant to be higher layer 
abstraction of HW.  We’ve refactored it to be lower-layer, and base 
peripheral abstraction.  The “drivers” layer can then provide 
friendly abstractions, and leverage the base HAL services.
	- The main benefit of the HAL is that it resides with the MCU, and is a 
core set of services that will be implemented with every MCU that we 
support.
	- An good example of a driver using the HAL to provide extra 
functionality is the uart driver above, which uses HAL GPIO and UART to 
provide multiple serial ports on the NRF52 (but allowed on other 
platforms too.)
	- The new HAL is here: 
https://github.com/apache/incubator-mynewt-core/tree/sterly_refactor/hw/hal/include/hal
		- After commit we plan on moving CPUtime to the OS, and adding a HAL 
timer library


- System Initialization
	- Chris has moved system init from the App to the BSP, and replaced 
“features” with a system configuration framework with a 
configuration framework.
	- A good example file is located here: 
https://github.com/apache/incubator-mynewt-core/blob/sterly_refactor/hw/bsp/nrf52dk/pkg.yml


- Low power framework
- The drivers have suspend/resume functions to save and restore state
	- A HAL has been added to HAL BSP to provide hooks for system states: 
https://github.com/apache/incubator-mynewt-core/blob/sterly_refactor/hw/hal/include/hal/hal_bsp.h


- Addition of sys/defs and standardized error codes: 
https://github.com/apache/incubator-mynewt-core/tree/sterly_refactor/sys/defs



Post merge, I think there are a few other things I’d like to clean up:

- Directory re-org: as previously mentioned, json and os should not be 
siblings :-)


- C++ header guards (Tim’s latest work)

- Second stage of sysinit work to centralize flash layout definitions 
and boot loader options.


- Addition of HAL timer, and move of CPUtime to the OS

- Replace current error codes with the sys/defs package error codes 
where appropriate, and make sure that is properly integrated.


best,

Sterling

sys/defs package; power management

[Sterling Hughes]

Hey,

I’m wondering if we should have a new package called “sys/defs” 
which contain system wide definitions.  Right now there are some 
definitions which don’t fit cleanly in packages (e.g. error codes 
require OS package).


By having a “sys/defs” package we could put error codes into that 
package, along with any other system wide definitions that don’t fit 
cleanly within HAL or OS, but are foundational.


On the power management front, I’m thinking I’d put the power 
management calls either in this package, or in hal_bsp.[ch].


Sterling

Re: Adding C++ header guards?

[Sterling Hughes]

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?


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.


Sterling

On 11 Sep 2016, at 14:04, Tim Hutt wrote:


Ah ok, I didn't read the style guide - I just copied the style of the
existing files I checked (the HAL headers) seem to put #ifdef 
__cplusplus
before #includes. I had a further search and some files put it after, 
some

before.

I'll have a look at getting them after the #includes. Might be quite
difficult with my regex hack though... Maybe make a temporary 
exception and

then say all new files must follow the style guide?

On 11 September 2016 at 20:58, Peter Snyder  wrote:

I think this is great too, but I don’t think it’s keeping to the 
mynewt
coding standard. In particular I think the C++ wrappers are supposed 
to
appear after other included files and before any file content. For 
sure
this messes up your script (sorry) but it avoids any potential 
conflicts
with the included headers. I’m fine being corrected on this (sure 
would be

easier to automate this work :-).

Here’s the relevant section from the coding standard <
https://github.com/apache/incubator-mynewt-core/blob/
master/CODING_STANDARDS.md>:
Header files must contain the following structure:

Apache License (see above)
#ifdef aliasing, to prevent multiple includes
#include directives for other required header files
#ifdef __cplusplus wrappers to maintain C++ friendly APIs
Contents of the header file
- peter


On Sep 11, 2016, at 12:41 PM, Christopher Collins 


wrote:


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."

Removing os_error_t

[Sterling Hughes]

Hey,

Across the OS, we have two interfaces: some that use os_error_t, and the 
other that uses int’s for return codes.


Personally, I have never liked using a typedef for an error code 
(largely as a short hand for an enum.)  I like to have a single variable 
“rc” that I use for error accounting — which works fine with 
enums, but if the type changes under me, then all the code doesn’t 
compile.  Plus, there are cases where I want to return values and error 
codes in a single int (positive = val, negative = error code.)  In order 
to stick with the spirit of an enum, I’d have to separate the value 
and return code, and I’m lazy and dislike functions with unnecessarily 
long signatures.


And “os_error_t” only applies to OS error codes, and our libraries 
are mixed.  FS uses ‘#defines’, whereas BLE uses enums again.


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.


Sterling

OS device locking

[Sterling Hughes]

For reference, the OS device code in sterly_refactor:

https://github.com/apache/incubator-mynewt-core/blob/sterly_refactor/libs/os/src/os_dev.c

I wanted to document my assumptions on OS device locking for folks, and 
get input as to whether people agree/disagree that this is the right 
approach.


Assumptions:

- Devices are only created _prior_ to the OS running, and devices are 
_never_ deleted once being created.  Therefore, the OS device list 
itself does not need to be locked, as it is immutable during system 
operation.


- Open & close call the per-device handlers, and those handlers perform 
locking if they view it as necessary.  An example of a handler that 
locks: 
https://github.com/apache/incubator-mynewt-core/blob/sterly_refactor/drivers/adc/adc_nrf52/src/adc_nrf52.c 
(nrf52_adc_open() - line 96.)
	- Currently UNSAFE: in cases where locks don’t occur on the device, 
OS_DEV_STATUS_OPEN is set and released by open and close, without any 
locking.  This means that they can’t be called from multiple task 
contexts.
	- I’m wondering if this should be a reference count, for the cases 
where multiple opens & closes are allowed, that way the system always 
knows if the driver is opened reliably.


- Suspend & resume (TBC - description here), will not look to acquire a 
lock when suspending a device, but rather its up to the driver 
implementation to wait for any locks, or provide any housekeeping 
regarding the driver itself.  Suspend/resume are meant to be called 
outside of the context with which a driver is being used.


- Suspend & resume are ONLY going to be called on OPEN drivers.

Sterling

Re: Low power design

[Sterling Hughes]

- (future) Provide a method to newt by which certain tasks memory can 
be linked earlier in RAM, so that for systems where RAM suspension is 
desired, a core set of system services can be located there, while 
other services can be re-initialized in a second phase.
	- This may cause some modification to the task structure to provide 
these “re-init” functions.




I was specifically wondering if folks had any thoughts on this scenario. 
 This is the case on certain processors where you can go into ever low 
power states, as you retain only certain blocks of RAM (I believe Nordic 
allows you to retain down to 4K of RAM on the NRF52.)


In terms of use-cases, I think the most common one here will be on a 
system where you have the processor need to wake-up from some external 
operation (e.g. button press), and you want to have system asleep until 
that happens.  When implementing these cases, you’ll probably also 
want to have some code that comes up very quickly, and performs certain 
operations, prior to fully booting the system (e.g. debouncing an I/O 
pin.)


My initial thought on this was that we could locate the operating system 
in that 4K of RAM, and designate a single task, which retains context to 
do this.  This could currently be the idle task, and the idle task can 
have a restore from deep sleep hook, which was user provided.  Given 
that the user provided hook would likely be in a separate context from 
the OS, we would dedicate a linker section to user provided retained 
memory so that any data associated with the user hook could also be 
saved.


Then, when the processor wants to transition to sleep mode: either 
through an ISR, or some task’s context.  It tells the system to 
transition into that state, which triggers a saving of critical system 
context.  When the IDLE task comes up, it immediately calls the deep 
sleep hook, to determine if the full system should reboot.  If it 
determines the system should reboot, the entire system then jumps to C 
startup and re-initializes.


I should note that on some processors (e.g. Nordic), in these deep sleep 
RAM retained states, the code begins running from the reset vector (0 in 
internal flash.)  Currently we locate our boot loader there, so we’ll 
need some other code in the boot loader to skip image verification (if 
enabled), and look into RAM for a specific pattern — if that pattern 
is present, restore system operation, otherwise continue booting.


The other option, is to skip multi-purposing the idle task, and instead 
add a linker section for “retained RAM” that goes ahead of all other 
sections.  And then, add a hook in the C startup code that goes prior to 
any initialization.  In this case, that hook can run, look at the 
retained RAM, and perform operations prior to system boot.  This would 
avoid all interactions with the RTOS itself, yet provide a standard way 
of having people hook into this state.


I’m not sure which of these I like more.  The OS approach seems more 
complicated, but somehow feels more right.  Nonetheless, I can’t 
really see why running out of the idle task is that desirable, if you 
end up losing all of your other task contexts.  You’re really going to 
have to re-run system initialization anyway (e.g. reboot) in order to 
get full system functionality.


Are there any other approaches folks have seen in the past/liked?  What 
have people done when they’ve needed to manage these states?



Thanks,

Sterling

Re: Adding C++ header guards?

[Sterling Hughes]

PS: if anyone wants to volunteer to do this work, I’m more than happy 
to cede responsibility :-)


On 9 Sep 2016, at 10:08, Sterling Hughes wrote:


Hey,

In our coding style we’ve agreed to be C++ friendly:

https://github.com/apache/incubator-mynewt-core/blob/master/CODING_STANDARDS.md

But being that none of us really do C++ on a daily basis, we’ve been 
fairly lax in enforcing this.  I’m thinking we should make all our 
header files C++ friendly prior to beta 1 (and fix any remaining 
problems prior to rel.)  (*)


As a part of that, I was wondering if some of the more C++ oriented 
folks on the list knew of a good tool that would automatically 
“C++-ify” C header files, to make the mundane work a little more, 
palatable.  Also, it would be great if there was a mode in coverity, 
or some static analysis tool that could automatically “C++ verify” 
our code on every commit.  Otherwise, I assume we could auto generate 
a big file with all includes, and then try and include that in a C++ 
compile.


Sterling

(*) And we need to add / test C++ support in newt prior to rel.

Re: Low power design

[Sterling Hughes]

Hi Kevin,

On 8 Sep 2016, at 10:41, Kevin Townsend wrote:


Hi Sterling,

I'm sure it's in the planning, but there should definately be some 
sort of callback at the BSP level before going into a lower sleep 
state (deep sleep or halt), as well as after wakeup.  This will allow 
you to configure pins accordingly to disable external pullups, avoid 
as much leakage current on the GPIOs as possible, perhaps switch to a 
lower voltage if you're using a special dual voltage regulator to save 
power, etc. And then when we wakeup the wake callback can be used to 
put the pins back to their pre-sleep state.


I assume that's what you meant though by "application hook for each 
system state", but we should probably be aware of both entering and 
exiting a specific state since there is BSP specific work on both 
ends.




Thanks, yep - that’s the idea.  I was thinking that even the drivers 
wouldn’t automatically suspend, we would just provide a helper 
function for the user implementing these hooks to “suspend all 
drivers.”  But that the shutdown / wakeup order would be per-BSP or 
per-App depending on setup.


Cheers,

Sterling

Re: [jira] [Commented] (MYNEWT-368) Change logging format

[Sterling Hughes]

 In the 16-bit case I don't understand why you would ever reset the index to 0. 
 So long as the value is increasing, you will always have 32k entries prior to 
wrap.   I don't see why you'd care that it starts at a given number.  

Sterling

> On Sep 1, 2016, at 2:28 PM, Ray Suorsa (JIRA) <j...@apache.org> wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/MYNEWT-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15456671#comment-15456671
>  ] 
> 
> Ray Suorsa commented on MYNEWT-368:
> ---
> 
> Ah yes, the index is doing double duty.  The first one is to try to maintain 
> order when the device logs a lot of lines in a short period of time.  The 
> other, which we trying to use it for also is to deal with a lot of clock 
> drift.  It seems to me that we should not reset the index in that way.
> 
> I am sure we will have to experiment a bit and figure out what sort of bounds 
> we are trying to operate in.
> 
> 
> 
> 
>> Change logging format
>> -
>> 
>>Key: MYNEWT-368
>>URL: https://issues.apache.org/jira/browse/MYNEWT-368
>>Project: Mynewt
>> Issue Type: Bug
>> Components: Newtmgr
>>   Reporter: Sterling Hughes
>>   Assignee: Peter Snyder
>>Fix For: v1_0_0_beta1
>> 
>> 
>> Right now newtmgr has an 8-bit index which goes along with a 64-bit 
>> timestamp.  We are having trouble querying logs when time moves forward, 
>> because of the misordering of log entries.
>> We should change this such that we have a 16-bit log index, which can be 
>> used to query logs remotely.  A result of this will be to make the module an 
>> 8-bit value, which it is already assumed to be.
>> While doing this change, on the FCB implementation, we should also add a 
>> short log entry header (4-bytes), that at least contains the version of the 
>> log format that we are writing, that way when we make changes in the future 
>> to the log format, the code can automatically wipe this sector and reformat 
>> it.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

Re: nmgr, shell vs ble host

[Sterling Hughes]

PS: I’d be interested in what Will has to say w.r.t controller, which 
may be an exception — given that it will have hard timing 
requirements, and likely need to be a high priority task.  My mail was 
meant to address more “appy” (app-ish?) libraries.


On 31 Aug 2016, at 16:14, Sterling Hughes wrote:


Hey,

I’ve been wondering how we should handle libraries in the OS, that 
need to run in a task context, but don’t necessarily need their own 
_dedicated_ task context.


I think right now we have two approaches:

- Create a library that takes an event queue, and expects to be called 
within a task context, but doesn’t create it’s own task (example: 
BLE host - 
http://mynewt.apache.org/latest/network/ble/ini_stack/ble_parent_ini/)


- Including that package creates its own task, and requires it to 
operate in that context.  (example: newtmgr - 
https://github.com/apache/incubator-mynewt-core/blob/master/libs/newtmgr/src/newtmgr.c#L504)


Personally, I think we should move the first approach taken by the 
bluetooth host for all system libraries that require a task context to 
operate.  I don’t see any reason why you couldn’t run newtmgr and 
BLE host in the same context, and save the RAM space by having a big 
app task that keeps posting to its own event queue.


What do folks think?  I think while we’re revising system init, it 
would be a good time to look at this, and come up with a consistent 
mode of operation.


Sterling

nmgr, shell vs ble host

[Sterling Hughes]

Hey,

I’ve been wondering how we should handle libraries in the OS, that 
need to run in a task context, but don’t necessarily need their own 
_dedicated_ task context.


I think right now we have two approaches:

- Create a library that takes an event queue, and expects to be called 
within a task context, but doesn’t create it’s own task (example: 
BLE host - 
http://mynewt.apache.org/latest/network/ble/ini_stack/ble_parent_ini/)


- Including that package creates its own task, and requires it to 
operate in that context.  (example: newtmgr - 
https://github.com/apache/incubator-mynewt-core/blob/master/libs/newtmgr/src/newtmgr.c#L504)


Personally, I think we should move the first approach taken by the 
bluetooth host for all system libraries that require a task context to 
operate.  I don’t see any reason why you couldn’t run newtmgr and 
BLE host in the same context, and save the RAM space by having a big app 
task that keeps posting to its own event queue.


What do folks think?  I think while we’re revising system init, it 
would be a good time to look at this, and come up with a consistent mode 
of operation.


Sterling

Re: hal watchdog

[Sterling Hughes]

Hi,

2) When developers create the system and want a HW watchdog, what in 
the OS tickles the watchdog? Is that done by the sanity task or is it 
done by the OS in some other manner (os time tick, for example)? Or 
does the creator of the application need to provide for the tickle?


This would be done by sanity task. For folks who do not want to use 
sanity task would have to come up with

another mechanism.


Thanks

PS I am not sure if memory serves (and it rarely does!) but I think I 
have worked on older MCU’s whose maximum internal watchdog timeout 
was < 1 second. I dont know if current day MCU’s have this kind of 
limitation, but if they did, how would that be addressed? Or is it 
not a concern…


Argh, I had not considered such hardware. I think I would make the 
tickling happen then on 2 layers;
sub second stuff being internal to driver through a timer interrupt, 
and the slower tickling happening

through the watchdog API.



I was assuming that the internal watchdog would not be a sanity level 
watchdog, but rather be tickled within the OS context switch, and that 
if people wanted to tickle a watchdog through sanity, they could 
register a sanity function and do it in that context.


I assume we’ll want an OS level configuration/define that specifies 
how often to tickle the watchdog, and that define should be a power of 
2.


Sterling

Re: Is the Arduino "M0" board supported?

[Sterling Hughes]

Hi Glen,

Awesome!

The M0 does not have a debug chip on it, so if you have an external JTAG 
debugger, I believe it will work (or it will be fairly easy for us to 
support it, if you are determined.)


M0 Pro, Zero and Zero Pro all work well, if you want to get going with 
those.


Sterling

On 26 Aug 2016, at 13:06, Glen Darling wrote:

I am eager to start using mynewt, so I am shopping for hardware and I 
have

a question...

The Arduino "Zero" and "Zero Pro" boards seem to have been replaced 
with

"M0" and "M0 Pro" boards, from reading:
http://www.arduino.org/blog/m0-pro-vs-zero
and also seeing the Zero Pro listed as a "previous" board, here:
http://www.arduino.org/products/boards

I see you have added the "Arduino M0 Pro" board as a supported board 
on

this page:
http://mynewt.incubator.apache.org/
however, the "Arduino M0" board is not listed there. May I assume that
mynewt will also support the M0?

Thanks,

Re: HAL & I2C redux

[Sterling Hughes]

On 25 Aug 2016, at 14:00, Sterling Hughes wrote:


Hi,

On 25 Aug 2016, at 9:48, Stéphane D'Alu wrote:


Hi,

You could want to take a look at others.
ChibiOS has a nice and clean API.




I have taken a look at quite a few (Zephyr, mbed-hal).   I just took a 
look at ChibiOS: I’ll refer to them more in the past.  I haven’t 
paid much attention to them, because I thought they were GPL: but it

 
 future

:)

Re: HAL & I2C redux

[Sterling Hughes]

Hi,

On 25 Aug 2016, at 9:48, Stéphane D'Alu wrote:


Hi,

You could want to take a look at others.
ChibiOS has a nice and clean API.




I have taken a look at quite a few (Zephyr, mbed-hal).   I just took a 
look at ChibiOS: I’ll refer to them more in the past.  I haven’t 
paid much attention to them, because I thought they were GPL: but it 
looks like all their HAL stuff is Apache licensed, which is interesting 
to see! I generally like the design choices I saw there.


Sterling

Re: HAL & I2C redux

[Sterling Hughes]

Hi Kevin,

On 25 Aug 2016, at 9:49, Kevin Townsend wrote:

Although, this will also depend on how things are implemented in the 
.c code ... I only see the header at present. But from experience some 
sensors require the stop to be handled differently between multiple 
read or writes, so it's worth considering how to keep the STOP 
condition flexible and under user control since there isn't a one size 
fits all approach for every I2C sensor out there.





Yeah,  most of the vendor APIs I see have the stop bit as an option (or 
by default) after a write() command, whereas our HAL APIs use begin() 
and end() to generate stop conditions.  Frankly, I think it might make 
more sense to label these start() and stop(), because a lot of the I2C 
protocols can have multiple start conditions and multiple stop 
conditions.  Or maybe a control() command that takes either START or 
STOP, to make it clear that it’s not modifying transaction state in 
anyway.


Sterling

HAL & I2C redux

[Sterling Hughes]

Hi,

While we’re doing the HAL changes, I’d like folks to check out the 
I2C APIs, and provide any comments they have:


https://github.com/apache/incubator-mynewt-core/blob/sterly_refactor/hw/hal/include/hal/hal_i2c.h

I was relatively happy with these APIs, except for maybe the 
hal_i2c_master_data: I think write/read should just take these three as 
arguments: but I didn’t see this as significant enough to change.


However, the one difference between SPI (new SPI HAL APIs) and UART is 
that I2C does not have a non-blocking mode.  I didn’t think this was a 
huge issue, because I assume that I2C is likely going to be mostly slow 
communication in a low-priority task context.  However, I’m interested 
to know if folks think an interrupt based/non-blocking API is desirable 
for I2C, and worth the implementation overhead for people developing the 
HAL.


Also, folks should feel free to review the new HAL which is here:

https://github.com/apache/incubator-mynewt-core/tree/sterly_refactor/hw/hal/include/hal

With the caveat that Will’s new SPI HAL interface isn’t committed, 
and we are missing a watchdog HAL (coming soon.)




Sterling