Re: JIRA

[Sterling Hughes]

Hi Justin,

No, we've pretty much been waiting for the ASF infra.

It will be nice to have JIRA!

Sterling

On Mon, Oct 26, 2015 at 3:11 PM, Justin Mclean  wrote:
> Hi,
>
> I’ve raised a JIRA to setup JIRA here. [1]
>
> Is there an existing JIRA bug base you wish to import issues from?
>
> Thanks,
> Justin
>
> 1. https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-10670

Re: incubator-mynewt-larva git commit: add task info display. re-arrange the task structure a little, removing enum on task state and making it a uint8

[Sterling Hughes]

Hey,

Two things with this commit I wanted to see how people felt about.

1- I've done some re-arrangement of the task structure.

Specifically:

-uint8_t t_pad[2];
+uint8_t t_state;
+uint8_t t_pad;

 char *t_name;
 os_task_func_t t_func;
@@ -57,8 +58,9 @@ struct os_task {

 struct os_sanity_check t_sanity_check;

-os_task_state_t t_state;
 os_time_t t_next_wakeup;
+os_time_t t_run_time;
+uint32_t t_ctx_sw_cnt;


Prior to these changes task state (SLEEP, RDY) was an enum, taking up
4-bytes!  Bad!  (I think I may have done it this way originally :-)

If you look at this section of the structure, you now have:

  uint16_t t_stacksize;
  uint16_t t_flags;

  uint8_t t_taskid;
  uint8_t t_prio;
  uint8_t t_state;
  uint8_t t_pad;

With only 2-bits of flags being used.  I wonder if we should compress
this further, we could, for example:

- Make stack size a multiple of 8, and use 13 bits for it.  Take 2 of
those bits and make that the flags, and 1 bit to indicate Sleep or
ready.

- Eliminate state & pad.

Talking with Will, we decided this wasn't worth it.  We'd rather just
burn the 4-bytes in this structure.

2- In adding task profiling, I've made the structure a further 8-bytes
bigger, by adding context switch count and total run time.  In other
OS's, I've seen these two variable's #ifdef'd out, depending on
profiling level.

Some notes here:

- I've added them in os_arch_ctx_sw(), not within the ISR context.
This means that I could spuriously count a context switch, where the
OS wants to switch context, but before the PEND_SV (Cortex M* series)
interrupt actually swaps in the task, another, higher priority
interrupt executes and switches context to a new task.

I thought this was fine, because even if PEND_SV does switch context,
the interrupt could come before the task executed a single
instruction: there will always be some opportunity for jitter here.
I'd rather not do task accounting within an interrupt context, and
live with this.

- Total run time only increments at the granularity of the OS timer
(currently 1ms on ARM), which means that if you have smaller runtimes,
they won't be counted.  We have a more granular timer in the HAL, but
I decided it wasn't worth bringing in that dependency.  Therefore some
tasks, which execute very quickly, will show 0 runtime.

- Context switch count and total run time are very similar metrics.
However, because CSW count provides an indication of whether a task is
actually being scheduled, and runtime gives you an idea of how long
its been running, I think both are useful.

- There is one more statistic I want to add by default, which is total
stack usage.  This should be the maximum amount of stack used, as
opposed to what the current stack usage is.  I wonder if the task
should also record the bottom of the stack, so we can get the current
amount of stack usage?

Are there any other statistics we should be keeping?  Do folks think
that we should #ifdef these elements out?   I'm somewhat against it,
because I just think its useful enough to always know this, that the
slight efficiency gains you get aren't really worth it.  However, I
could be swayed.

Sterling











On Tue, Nov 17, 2015 at 10:39 AM,  <sterl...@apache.org> wrote:
> Repository: incubator-mynewt-larva
> Updated Branches:
>   refs/heads/master 55082ce6c -> e96c2c3c6
>
>
> add task info display.  re-arrange the task structure a little, removing enum 
> on task state and making it a uint8
>
>
> Project: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/repo
> Commit: 
> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/commit/e96c2c3c
> Tree: 
> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/tree/e96c2c3c
> Diff: 
> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/diff/e96c2c3c
>
> Branch: refs/heads/master
> Commit: e96c2c3c6377452d9f7b40915f741116c8209eb3
> Parents: 55082ce
> Author: Sterling Hughes <sterl...@apache.org>
> Authored: Tue Nov 17 10:39:01 2015 -0800
> Committer: Sterling Hughes <sterl...@apache.org>
> Committed: Tue Nov 17 10:39:12 2015 -0800
>
> --
>  libs/os/egg.yml  |   5 +
>  libs/os/include/os/os.h  |   3 +
>  libs/os/include/os/os_sched.h|   4 +
>  libs/os/include/os/os_task.h |   7 +-
>  libs/os/src/arch/cortex_m4/os_arch_arm.c |   4 +
>  libs/os/src/arch/sim/os_arch_sim.c   |   4 +
>  libs/os/src/os.c |   3 +
>  libs/os/src/os_info.c| 167 ++
>  libs/os/src/os_sched.c   |  56 -
>  libs/os/src/os_task.c|   6 +
>  libs/os/src/os_tim

Task Priorities

[Sterling Hughes]

Howdy,

I'm working on getting blinky a bit more developed as an initial
project.  First part of that is getting console running on sim, which
I have working.

One thing I've been looking at, is the hal_uart starts an OS task when
initialized.  The priority of that task, and stack size is defined by
the MCU definition (e.g. hw/mcu/native, or hw/stm, etc.)

I think task priorities are something that should be defined on a
per-project level.  From what I can see, there are two options for
doing this:

1- Have the individual packages expect a #define from the project, in
the following format:

hal_uart.c:

  os_task_init(OS_PRIO_UART, ..)

project/blinky/include/project/os_cfg.h:
   #define OS_PRIO_UART (10)

This could be enforced using our capabilities concept, where the
package would req_capability: os_cfg, and the project would provide
that.

2- The init function could take the priority to start the task at.
So, when hal_uart_init_cbs() is called, it would take two additional
arguments the priority, and stack size.  Anything that creates a task,
would be called directly from the project, with these arguments.
(uart code needs a little refactoring to make this easy, but should be
fine.)

I'm leaning slightly towards option #2, as I don't like messing with
defines.  That said, #1 is much more common, and they way that other
operating systems do it (I think, so that all priorities are defined
in a single header file, and you don't have to look through the code
to find them.)

What do folks think?

Sterling

ASF Copyright header

[Sterling Hughes]

Hey,

At some point in the near future, I'm going to go through and replace
all the header files from:

/**
 * Copyright (c) 2015 Runtime Inc.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *   http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

To the appropriate one now that we're an ASF project.  I assume this
is the correct header?

-- 

Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.

--

I will also create NOTICE and LICENSE files in each source code
directory.  I assume this should bring us "up to code" from a legal
perspective?

Thanks,
Sterling

Re: Mynewt logo - request for input

[Sterling Hughes]

I think that is good, singular case looks better to me.  what i
especially like about #1 is that it takes the y, and makes it look
cool..

On Tue, Nov 17, 2015 at 4:32 PM, aditi hilbert <ad...@runtime.io> wrote:
> It will be hard to capitalize the M on the first one but maybe we settle for 
> “mynewt” and “mynewt OS” and change all reference to that (e.g. docs, website 
> etc.)?
>
> aditi
>
>> On Nov 17, 2015, at 3:33 PM, Sterling Hughes <sterl...@apache.org> wrote:
>>
>> I like the one on the upper left hand corner of the second page as well.
>>
>> On Tue, Nov 17, 2015 at 3:31 PM, will sanfilippo <wi...@runtime.io> wrote:
>>> I like #1 too.
>>>
>>> Will
>>>> On Nov 17, 2015, at 10:13 AM, Christopher Collins <ch...@runtime.io> wrote:
>>>>
>>>> I think they are all really good, but my preference is for 1 or 2.
>>>>
>>>> I lke 1's font the best, and I like the way the newt's tail wraps around
>>>> the y.  So actually I guess I like 1 the best :).
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> On Tue, Nov 17, 2015 at 09:49:24AM -0800, aditi hilbert wrote:
>>>>> Good point! Doing that now :)
>>>>>
>>>>>> On Nov 17, 2015, at 9:47 AM, P. Taylor Goetz <ptgo...@gmail.com> wrote:
>>>>>>
>>>>>> Cool!
>>>>>>
>>>>>> For the purpose of discussion, it might be a good idea to annotate the 
>>>>>> PDF to give each one a number for easier reference. Otherwise we’ll have 
>>>>>> to reference them by description (e.g. “The green one with the ‘m’ 
>>>>>> inside the newt’s tail.” ;) )
>>>>>>
>>>>>> -Taylor
>>>>>>
>>>>>>
>>>>>>> On Nov 17, 2015, at 12:32 PM, aditi hilbert <ad...@runtime.io> wrote:
>>>>>>>
>>>>>>> Thanks, all. I just created MYNEWT-12 
>>>>>>> <https://issues.apache.org/jira/browse/MYNEWT-12>.
>>>>>>>
>>>>>>> aditi
>>>>>>>
>>>>>>>
>>>>>>>> On Nov 17, 2015, at 9:21 AM, P. Taylor Goetz <ptgo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Confirming that no attachments were received on your reply.
>>>>>>>>
>>>>>>>> Looks like another route is in order. JIRA attachments might be the 
>>>>>>>> easiest route.
>>>>>>>>
>>>>>>>> -Taylor
>>>>>>>>
>>>>>>>>> On Nov 17, 2015, at 12:12 PM, Marvin Humphrey 
>>>>>>>>> <mar...@rectangular.com> wrote:
>>>>>>>>>
>>>>>>>>> On Tue, Nov 17, 2015 at 7:32 AM, aditi hilbert <ad...@runtime.io> 
>>>>>>>>> wrote:
>>>>>>>>>> I did attach the document with 4 drawings of “mynewt” to my mail. I 
>>>>>>>>>> am going
>>>>>>>>>> to try a second time with the original drawings of 6 “mynewts". 
>>>>>>>>>> Please
>>>>>>>>>> ignore the first page with drawings of newt on it. The following two 
>>>>>>>>>> pages
>>>>>>>>>> should show a total of 6 drawings. Hope you can see them this time!
>>>>>>>>>
>>>>>>>>> It seems that this emailing list is configured to strip attachments.  
>>>>>>>>> As extra
>>>>>>>>> confirmation, I've attached the Incubator's egg logo to this email; I 
>>>>>>>>> predict
>>>>>>>>> you won't see it, though because of gmail's quirky deduping I 
>>>>>>>>> probably will.
>>>>>>>>>
>>>>>>>>> The easiest way to share an image is probably to open a MYNEWT Jira 
>>>>>>>>> issue and
>>>>>>>>> attach it there, or possibly just to commit the files to the site svn 
>>>>>>>>> repo.
>>>>>>>>> For text there are lots of other options such as paste.apache.org, 
>>>>>>>>> Github
>>>>>>>>> gists or pull requests, and so on, but for images there's not a 
>>>>>>>>> perfect answer
>>>>>>>>> that I know of.  The downside is that we won't be able to view them 
>>>>>>>>> in our
>>>>>>>>> browsers without downloading first because of MIME type issues 
>>>>>>>>> (unless you
>>>>>>>>> commit to svn and fiddle with the svn properties), but since the 
>>>>>>>>> target
>>>>>>>>> audience is developers, it's not unreasonable to ask us to figure 
>>>>>>>>> things out.
>>>>>>>>>
>>>>>>>>> Marvin Humphrey
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>

Re: subsystem configuration ideas

[Sterling Hughes]

I think lua for configuration would make sense, but I agree, a simpler
mechanism is also useful for more constrained systems.  I think it
would make sense that lua have hooks into the simpler configuration
system, and then more complex functions can be directly exposed by
lua.  Lua can supersede the simpler config if present.





On Mon, Jan 4, 2016 at 11:48 PM, will sanfilippo  wrote:
> I am fine with the naming and the interface and all that. Not so sure about 
> lua for config though. Seems like a heavyweight thing for config so I am glad 
> you are considering something simpler :-)
>
> Will
>
>> On Jan 4, 2016, at 10:58 AM, marko kiiskila  wrote:
>>
>> Hi,
>>
>> so we need to have a way to set/read settings for subsystems.
>> These are the ones to be adjusted at runtime.
>>
>> What I’m thinking is to build this in a way where names of
>> these are strings, and that you should be able to have hierarchical
>> naming. E.g. to have subsystem to be part of the name.
>>
>> subsystem1/variable1 = value
>> subsystem1/variable2 = another_value
>> subsystem2/var1 = yet_another_value
>>
>> I’d rather use strings as identifiers as opposed to say, enumerated
>> values, because it would be easier to keep them unique.
>>
>> As for setting/reading them, I was going to start with a CLI interface.
>> And have interface from newtmgr as well.
>>
>> Of course, we will need to persist configuration. So there’s few
>> options here. Either use lua scripts, which would be read at
>> bootup time and they can change these settings. And/or
>> a simpler script interface for cases when lua is not present.
>>
>> Let me know if you have comments on this,
>> M
>>
>>
>

Re: Changes to HAL/BSP/Drivers

[Sterling Hughes]

On 6 Jun 2016, at 12:56, marko kiiskila wrote:

On Jun 2, 2016, at 5:07 PM, Sterling Hughes <sterl...@apache.org> 
wrote:


...



:)

Right now, we don’t have a drivers interface, and the HAL is 
dual-purposing both.  The ADC is a good example of this, so I’ll 
focus in on that API.


…



:)

* The hal_adc_read() function blocks on read.  This is for user 
convenience, but does not represent how the underlying hardware 
implements an ADC read.


Should we have non-blocking implementation available as well?
IMHO, it’s easy to use non-blocking implementation in a blocking
fashion, but doing it the other way around is not as easy.
This is especially important with HALs which go over a bus (I2C, SPI).

I admit, I don’t have much experience with use of ADC peripherals
themselves.


My view: we should remove blocking, have a non-blocking only version and 
remove sysid mappings.


* hal_adc_start(adc0, mode, my_callback_func); // see desc below
* hal_adc_rdy(adc0);  // is there a reading (doesn’t block)
* hal_adc_read(adc0); // read the value of the adc, doesn’t block
* hal_adc_stop(adc0); // stop in free running mode.

Where my_callback_func is the callback that’s called when a reading is 
available.  this is called from the interrupt context.  Mode is either 
free running, or one-shot.


We should also have functions that map to approximation and sampling, 
gain & offset, as that is common across most peripheral implementations 
that I have seen.


Sterling

Re: newtmgr over Serial

[Sterling Hughes]

Hi Kevin,

I’ll caveat my comments below with: I agree with you, there should be 
a serial port option in the boot loader, so take the rest as capturing 
thoughts in this area. :-)




Thanks for the reply.
On Jun 7, 2016, at 5:07 AM, Kevin Townsend  
wrote:


Dev probably isn't the ideal place to post this, but I'm filing it 
here in case the request is useful to other people in the future.


I'm trying to determine how the bootloader functions with image 
management, and what functionality is currently in place, and I was 
hoping someone could clarify is whether flashing only the bootloader 
(on the nRF51822 in this case) is enough to allow for firmware 
updates over serial?
It is not. Bootloader does not have serial port or newtmgr command 
processing in it.

Image uploads/list etc commands are processed by the app itself.

Bootloader gets instructed by the app what image to boot next, and it 
acts on this info

on next reset.

If you can type in console input and see responses over the serial, 
then the target should
be able to process newtmgr commands as well (assuming newtmgr is 
included, of course).
That seems like a significant shortcoming of the bootloader process, 
then, if it relies on a valid secondary firmware image to be present. 
What if a faulty image is flashed, for example, or the firmware flash 
memory is corrupted resulting in essentially a bricked device that 
will require a JLink to restore, which is an unreasonable expectation 
in the field in my opinion.




If a faulty image is uploaded, the boot loader will fall back to the 
previous image.  So the process typically works, upgrade the new image, 
ensure stability, then confirm it as the default image.


In my experience, if the flash is corrupted you generally want a RMA, as 
these flashes should not corrupt themselves.  That said, the use case I 
was previously acquainted with was devices out in the field, that 
required field techs to bring them in.  I can see how if it’s a 
consumer, re-flashing serially might be desirable.


It would seem far safer to integrate the communication process into 
the bootloader itself so that it's entirely autonomous, although I 
understand the COM port conflict at that point as well.


For me, the bootloader should be the single, independent constant and 
the main fail safe mechanism in the system with no external 
dependencies, but perhaps I've misunderstood some of the design goals 
as well.  That's just how every other bootloader I've dealt with was 
designed.




Well, that’s the case here.  It just doesn’t have a serial port 
option, it assumes the flashing is done either via JTAG, or OTA.  This 
is very similar to the Nordic option which has the MBR (boot loader), 
and then the DFU<->SoftDevice, which are outside of the boot loader 
region, and not self contained.


I don’t think we want the boot loader itself to provide OTA (BLE) 
update, as that would make it prohibitively large (and as you point out, 
the boot loader should not be upgradable, so all code there would be 
fixed.)


I agree we should add a serial port option to the boot loader, it 
shouldn’t be that hard, and could be optionally compiled.


Cheers,

Sterling

Re: newtmgr over Serial

[Sterling Hughes]

On 7 Jun 2016, at 10:12, Kevin Townsend wrote:


Hi Sterling,

If a faulty image is uploaded, the boot loader will fall back to the 
previous image.  So the process typically works, upgrade the new 
image, ensure stability, then confirm it as the default image.


In my experience, if the flash is corrupted you generally want a RMA, 
as these flashes should not corrupt themselves.  That said, the use 
case I was previously acquainted with was devices out in the field, 
that required field techs to bring them in.  I can see how if it’s 
a consumer, re-flashing serially might be desirable.


The problem here is that an image can be valid, but the 'code' can be 
bad such as an inappropriate clock setup so it locks up waiting for 
the PLL to get a fix. This shouldn't happen in the real world but bad 
images do get out into the wild, of course, and the bootloader will 
still accept it as valid, and customers may not be able to recover 
their device.




Yup, the previous scenarios I’ve worked in have been primarily large 
scale mesh.  So a field tech would never reflash a device serially, but 
would rather pull it out, replace it with a new one, and return it to 
RMA facility, where JTAG was easy (we had a fixture.)


In this case, I can definitely see the benefit of serial in boot loader.

Sterling

Re: newtmgr over Serial

[Sterling Hughes]

Hi David,

On 8 Jun 2016, at 11:17, David Moshal wrote:


Thanks Wayne, that's very interesting, I think it helps explain the
disconnect here.

I understood David Simmons to be suggesting that Makers (like me) are
the target end-users,
i.e: that MyNewt would be an alternative to, say, Arduino (and why 
not).


However, in your use-case, you are the end-user of MyNext, and Makers
are your end-users, no?
i.e: a layer lower in the stack. So, in that case MyNewt would be
positioned as an alternative to an RTOS (or no RTOS) for embedded C
programmers building devices for Makers.

So, if I may, I'd suggest that we step back and ask Sterling who
exactly he envisages as the end user of this project:
 Makers, or embedded C developers building devices for Makers?


I’ll give my 2c here, but I do want to point out: this is up to all of 
us, I’m just one vote.


I think Mynewt can have a broad set of users, which include:

- Makers who are embedded C developers
- Embedded C developers who are building devices for Makers
- Scripting language OS support
- Embedded product developers
- Microcontroller and sensor vendors who want to provide reference 
support for their platforms


And actually, having the project support a broader set of these 
use-cases should reinforce itself.


As an example, I’m a maker who is an embedded C developer.  I would 
_never_ use Wiring or Javascript to develop a project unless forced to.  
I enjoy writing things in C, and don’t mind typing a little extra or 
managing memory in order to have direct access to the underlying 
hardware.  Mynewt needs to be easy to use, and efficient for people like 
me, that’s why we’ve bundled toolchains with Docker, and have built 
a build & package management tool.


As you point out, there are plenty of cases where Wiring, Python and 
Javascript are better choices, and reach a broader set of people.  If 
you look at the popular languages in embedded IoT, almost all of them 
re-invent the HAL, BSP, and many facets of the OS.  If we can provide an 
engine, and they can hook into that, we can gain re-use on the 
non-language specific elements across all of the scripting languages.  I 
look at this very similar to how PHP and Perl relied on Apache as the 
web-server.  There is no reason that Micropython and Espruino 
shouldn’t be sharing HAL and BSP work, and the best way to do that 
(IMO) is to share efforts on a OS that they both plug into.


And the OS itself should be low-level and architected well enough that 
product developers can actually put it into real products and 
manufacture at scale.  At Runtime, we’re building the system we always 
wished we had, and have had to reinvent at every company we’ve been 
at.  While it’s an additional effort to support Makers and Maker 
platforms, there are real benefits to product developers in using an OS 
supported by Makers:


- Testing: If 100’s of thousands of Makers use Mynewt’s BLE stack, 
they are going to find bugs in it very quickly, and motivate Apple, 
Google and everyone else to be interoperable with it.  With enough eyes 
all bugs are shallow.


- Ease-of-use: You see this in devkits as well.   Take the NRF51/NRF52.  
They are not only widely used in products, but are beginning to be very 
popular in maker platforms.  The more support for sensors, peripherals 
and cheap hardware you have around this platform, the easier it is to 
develop prototypes and move it into products.


- Innovation: Products aren’t always going to be built around things 
like LORA, or Sigfox right away.  But if Makers support these platforms, 
it becomes easier for product companies to play with them, and then 
start adding them to things.


So.  I do think Mynewt itself will always be a low-level C operating 
system.  That said, I don’t think we should be tied to a use-case, but 
rather just go where it makes sense.  I think for Makers that like C, we 
should make it as easy to use and robust as possible, and we should have 
it work with as many scripting engines as possible (Wiring, Python, 
Javascript, Lua, etc.)


Sterling

Re: Base a custom bsp on an existing one

[Sterling Hughes]

Hi Simon,

I agree with Will’s response, the problem you have with 
“inherit’ing” BSPs, at least at this stage, is that the APIs are 
changing, and everything that inherits the BSP will have to change as we 
morph APIs.


However, you shouldn’t have to maintain a different BSP for every 
slightly different version of your own boards.  If you use something 
called features, you can control these settings.


A good example of this is the Arduino zero BSP, here:

https://github.com/runtimeinc/mynewt_arduino_zero

If you look at the pkg.yml in hw/bsp/arduino_zero 
(https://github.com/runtimeinc/mynewt_arduino_zero/tree/master/hw/bsp/arduino_zero), 
you’ll see the following lines:


pkg.cflags.arduino_zero_pro: -DARDUINO_ZERO_PRO
pkg.cflags.arduino_zero: -DARDUINO_ZERO

This changes the values of the CFLAGS based upon which feature is set, 
either arduino_zero or arduino_zero_pro.  This is to accommodate the 
fact that on the board, two pins are swapped depending on whether you 
get it from .cc or .org.  The C code can then check this with #ifdefs.


Features allow you to change dependencies, cflags, lflags and anything 
else, depending on which features are set in the build system.  Features 
can be either specified as a package variable (pkg.features), or at the 
target level by doing


$ newt target set your_target features=“feature1 feature2”

Features are global to the build system, and everything will respect 
them.


sterling

On 8 Jun 2016, at 12:43, Simon Ratner wrote:


I would like to create a couple of custom bsps for boards which are
identical to nrf51dk but a few small tweaks (e.g. led pin, flash area
layout).

From the docs, I gather that copying hw/bsp/nrf51dk and patching bsp.h 
and
os_bsp.c would do the trick, and it seems that's how mynewt itself 
handles
this. However, I'd really prefer not to, so I can keep up with 
upstream and

avoid duplicating fixes in multiple places (like
https://github.com/apache/incubator-mynewt-core/commit/c70353c193bf3e91a095cfc5076ac578f8e1bc69).


Any suggestions on how to best layer my tweaks on top of an existing 
bsp?

Can I abuse the deps system somehow?

Simon.

Re: newtmgr over Serial

[Sterling Hughes]

Hi Wayne,

On 8 Jun 2016, at 10:35, Wayne Keenan wrote:


On 8 June 2016 at 17:14, David Moshal  wrote:


David you make good points, though I have to say, sadly, that serial
vs JTag is the least of MyNewt's worries when it comes to targeting
the Maker market, if indeed that is your target market. Just saying.

I'm happy to explain that statement further if anyone is interested.



I'd like to hear more please, it's very relevant to aspects of my 
mission

at the moment...

To make things simpler for the Maker market I have a MicroPython 
prototype
up and running on MyNewt.   It comes with a couple of Python modules 
for
accessing GPIO (very basic) and configuring BLE (support for:  uuid16 
or
uuid128 bit GATT Services/Characteristics and Eddystone beacons) it 
also
has a simple Python 'single line eval' (a not yet multiline 
indentation

tolerant REPL) on serial.



That’s awesome!! Anyway I can play with this?

So from this perspective the only thing to flash might be the text of 
a
Python Script in part of a flash filesystem, but, I'd still like to be 
able

to upgrade the MicroPython 'app' using a boot loader that was always
present for app recovery/reflashing.



Absolutely.  Depending on what board you’re targeting, I imagine the 
Python scripts would either be a file, or just a flash blob.  The host 
OS image should be separately upgradable.


Sterling

Re: Javascript Support (was Re: [SUMMARY][DISCUSS] A users@ mailing list for Apache Mynewt)

[Sterling Hughes]

Hi David,


You look at Espruino’s compiler, and it was clearly written in
a swashbuckling style:


Thanks for the links. At this point though my C knowledge isn't
sufficient to comment either way.

However, I will share that I have a class of 3-6 graders (22 kids aged
8-11 years), who are all quite happily coding on the Espruino platform
(actually a port of the Espruino platform to the ESP8266), without any
problems. This is just a regular class of kids, only 2 are what I'd
call geeks. (I'm a volunteer parent at the school). And, we're using
real hardware, on breadboards, not plastic toy parts.

I don't know of any other embedded platform capable of supporting that
use case, or that abuse, do you?
I mean, that's literally the ultimate newbie scenario - completely new
to programming!

So, personally, I'd look to Gordon's work as an good example of
trade-offs that work, from an end-user perspective, just saying.
i.e: if he's not doing it the way others are, and his way works, then
it's probably worth pausing to consider, no?
that's my gut feel, I could be wrong.



Just to clarify here: when I say swashbuckling, I mean it as a 
compliment. :-) Gordon has done a great job with Espruino, and as you 
point out, he’s done an excellent job directly supporting the boards 
and making them _usable_ out of the box.  He’s really the first one to 
do that, and he seems committed to his ideas and able to turn them into 
something very cool.  Which probably means he’s already worked around 
many of the corner cases.  I would love if Espruino could migrate onto 
the Mynewt core.


The OS provides a lot of the functions that Espruino currently 
implements for each platform, meaning we really only need the core from 
the project (we will have drivers, HALs and BSPs.)  Jerryscript is just 
the core, and while it’s slightly less optimized, it also hasn’t 
made as many trade-offs for the smaller systems.  I’m merely 
speculating though — it will be interesting to see what David thinks 
when he digs into it. :-)


Have you taken a look at the other JS engines: V7, KinomaJS, Duktape, 
Tiny-JS?




V7 is GPL, and the code is all one file: whenever I see networking 
support and an AST (syntax tree) implementation in the same file, it 
stops my motivation to dig further.  KinomaJS is targeted at higher end 
systems from what I can tell.


Duktape looks pretty cool - 
http://www.slideshare.net/seoyounghwang77/js-onmicrocontrollers was 
interesting.  I hadn’t dug into it much, I’ll take a look.  Tiny-JS 
was GF’s first attempt, I think Espruino would be a better choice.


Best,
Sterling

Re: Correct way to add a task that only runs once

[Sterling Hughes]

Hi James,

Callouts are perfect for this type of function.  I’d recommend 
multiplexing this within the task context you are running out of.   
Essentially the logic works like:


- Turn the LED on
- Set a callout for 1 second to turn the LED back off

If your task is waiting on an event queue, it will process that event in 
one second.


More information on callouts and event queues can be found here:

- Tutorial on using these: 
http://mynewt.apache.org/os/tutorials/event_queue/

- Callouts: http://mynewt.apache.org/os/core_os/callout/callout/
- Event Queues: 
http://mynewt.apache.org/os/core_os/event_queue/event_queue/


You don’t need to add a specific task for the LED function, you can 
just multiplex it as an event.  If you want to create a separate task 
(so that it has higher priority, or doesn’t block/isn’t blocked by 
other functions), you can.


Sterling

On 28 May 2016, at 14:39, James Howarth wrote:


Hi,

I want to be able to flash an LED on for ~1 second when some condition
occurs.  I don't want this to be flashing all the time like the blinky
example.

What's the right way to add a task that runs only once?  Or should I 
not be

using a task at all for this?

Cheers
James

Re: [DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc2

[Sterling Hughes]

I agree - it should just default to 0 imo.  When I run on real targets I 
usually just provide 0.0.0.  

Failing a default, it should work consistently and display an error when you 
don't provide a version. 

Sterling 

> On May 28, 2016, at 3:48 PM, Christopher Collins <ccoll...@apache.org> wrote:
> 
>> On Sat, May 28, 2016 at 01:38:48PM -0700, Sterling Hughes wrote:
>> $ newt run  
>> 
>> Will do this for you.  No need to call binary directly.
> 
> If you are building for real hardware (i.e., not sim), then you need to
> add a version number to the end of the command.  So, the command would
> look something like this:
> 
>newt run myblinky 0
> 
> If you leave off the 0, you will get a cryptic and intimidating error
> message.
> 
> I was thinking we might want to make the version number optional.  When
> people use the run command, most of the time they probably don't care
> what version number the produced image has.
> 
> Chris

Re: [DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc2

[Sterling Hughes]

Newt target show.  In your case it's my_blinky_sim.  I can tell because it's in 
the path to the elf file-- every target's build is put in a separate directory. 
 

Sterling 

> On May 28, 2016, at 6:05 PM, David Moshal <dmos...@gmail.com> wrote:
> 
> how do I find the name of the target?
> Dave
> 
> 
>> On Sat, May 28, 2016 at 4:46 PM, Sterling Hughes <sterl...@apache.org> wrote:
>> $ newt run my_blinky_sim
>> 
>> Just the name of the target, don’t provide the binary path.  All of the
>> commands run based on the name of the target.
>> 
>> We’ll update the documentation here:
>> http://mynewt.apache.org/os/get_started/project_create/
>> 
>> to use newt run.  It was written prior to the Docker image being supported,
>> and works with the native toolset.
>> 
>> Newt run is documented here:
>> http://mynewt.apache.org/newt/command_list/newt_run/, albeit it should
>> probably have better documentation for simulated targets.
>> 
>> Sterling
>> 
>>> On 28 May 2016, at 16:18, David Moshal wrote:
>>> 
>>> ```
>>> ⇒  ../newt run ./bin/my_blinky_sim/apps/blinky/blinky 0
>>> Error: Invalid target name: ./bin/my_blinky_sim/apps/blinky/blinky
>>> ```
>>> 
>>> Undocumented cryptic commands required for 'getting started' project ?
>>> Not good, and doesn't inspire newbies to donate their time to the
>>> project, just saying.
>>> 
>>> For reference: it took me 5 mins from zero to blinky light on the mBed
>>> platform, which seems like a reasonable alternative to MyNewt, best as
>>> I can tell, so there's room for improvement if you want to grow the
>>> platform.
>>> 
>>> David
>>> 
>>> 
>>> 
>>> On Sat, May 28, 2016 at 3:48 PM, Christopher Collins
>>> <ccoll...@apache.org> wrote:
>>>> 
>>>>> On Sat, May 28, 2016 at 01:38:48PM -0700, Sterling Hughes wrote:
>>>>> 
>>>>> $ newt run 
>>>>> 
>>>>> Will do this for you.  No need to call binary directly.
>>>> 
>>>> 
>>>> If you are building for real hardware (i.e., not sim), then you need to
>>>> add a version number to the end of the command.  So, the command would
>>>> look something like this:
>>>> 
>>>>newt run myblinky 0
>>>> 
>>>> If you leave off the 0, you will get a cryptic and intimidating error
>>>> message.
>>>> 
>>>> I was thinking we might want to make the version number optional.  When
>>>> people use the run command, most of the time they probably don't care
>>>> what version number the produced image has.
>>>> 
>>>> Chris

Re: Javascript Support (was Re: [SUMMARY][DISCUSS] A users@ mailing list for Apache Mynewt)

[Sterling Hughes]

also: as you look at this, if you need changes to newt (tool) or can 
think of ways to have newt make bringing in 3rd party libraries easier, 
feel free to ping dev@ (ideal) or me directly.


we enforce a directory structure on packages with newt, but that 
doesn’t always need to be the case — we control our destiny with the 
tool.  i’ve been toying around with a few things, including having 
newt call a pre-build script which can take a 3rd party library, and 
layout it so that newt can build it/or can call it to build the library, 
and then just link in the sources.


anyhow, as you dig in: i’d be interested in thoughts, and if you have 
ideas on how to change it, i’d be happy to put in the work to make it 
easier.


sterling

On 28 May 2016, at 10:38, Sterling Hughes wrote:


Hi David,

On 26 May 2016, at 8:36, David G. Simmons wrote:

This is fantastic! Glad to see so much enthusiasm for JavaScript on 
an IoT device.


Here’s the thinking I have had on the subject, and why I have 
turned to MyNewt to try to make it a reality. JavaScript is hugely 
popular, and resents a fairly low-bar for entry into IoT development. 
JavaScript — when done right — can be extremely efficient and 
fast


I have been focussing on Node.js for a few reasons. Some of the 
server-side stuff is incredibly useful for IoT — enabling REST APIs 
on-device is a big win, etc. But Node is far too large. It just 
won’t fit on any reasonable IoT device, and the processing power to 
run it quickly and efficiently is too much for a truly IoT device. So 
what to do about these things?


In a galaxy far far a way, at a different time in IoT history (before 
there really was an IoT) I worked on a project where we implemented 
Java on IoT. Java on the metal. And it was basically the full Java 
SE, minus all the UI stuff. We did some interesting things that I was 
thinking of applying to this project. We did compile and build on the 
host machine pre-deployment to the device (we had an ARM9), and in 
that compile and deploy stage we basically pulled out anything that 
wasn’t used explicitly. We created stripped-down bytecode that ONLY 
contained what was used in the application. The underlying OS — 
also Java — handled strictly OS-related tasks and took care of 
networking, storage, power management, etc. and executed the byte 
codes sent as apps. We had a set of sensor libraries that handled the 
SPI, I2C, PWM, ADC, etc. and abstracted out a bunch of stuff like 
servos, stepper motors, etc. so developers didn’t have to do the 
dirty work on a lot of those things.


So I was thinking of a similar architecture for Node. A basic runtime 
that handled OS-integration functions, with MyNewt handling the HAL, 
BSP, Drivers, etc. as Sterling noted below. Developers could use 
pretty much any npm modules they need, and these would be stripped of 
any methods/functions not used, combined with Node (similarly 
stripped of any functionality not explicitly used) and then deployed 
on-device to be executed.


There is a vast amount of work to be done in making this system smart 
enough to be able to do the above-mentioned magic of stripping down 
everything and effectively and efficiently compiling it, but it could 
make for a very small, efficient, and almost infinitely extensible 
and flexible developer experience.




+1 — I think this is perfect.  What’s great is that early on, this 
will be very suitable for makers, but eventually also product 
developers.  Fundamentally, what you’d like is a set of expertise 
that is “kernel” — new networking stacks, board support 
packages, drivers, and then an interface that is Javascript.  That 
way, even product companies, can just pay consultants to port the 
kernel, and develop the majority of the application in JS.


We have Lua ported, but I think we’d look to have Javascript be the 
go forward option, if it was working with the system.


Anyway, that’s my stream-of-conciousness brain-barf on the subject, 
and where my thinking has been headed on this, and why I’m doing 
it. I’ve been targeting some (soon-to-come) *extremely* low power 
IoT SoCs — these are 2-3 orders of magnitude lower power than 
anything available today that operate in the 10-20휇W range at full 
power, in the nano-watt range for idle (including radios). These are 
going to be based on Cortex M-0 architecture (maybe M-3) as well.




Awesome— I think I have an idea of who you’re talking about :)

I’ll take a look at JerryScript and see what the effort there might 
be.




Cool.  I’d be interested in your thoughts as you dig in.  If they 
are unsuitable for a public mailing list, I’d be interested unicast 
as well. :-)


Sterling

Re: [DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc2

[Sterling Hughes]

$ newt run  

Will do this for you.  No need to call binary directly. 

Newt run also will upload targets to the host device for you, when you connect 
one.  

Not sure about the mapping, I'll let Todd and Chris chime in.  

Sterling 

> On May 28, 2016, at 1:26 PM, David Moshal <dmos...@gmail.com> wrote:
> 
> ok, so Docker knowledge is a pre-requisite, has been ages since I last
> used Docker.
> what's the host directory mapped to?
> 
> Dave
> 
> 
> On Sat, May 28, 2016 at 1:18 PM, Sterling Hughes
> <sterling.hughes.pub...@gmail.com> wrote:
>> Newt run target name will run it in the container-- when using docker the 
>> sim binary is compiled under Linux to run on Linux.
>> 
>> Sterling
>> 
>> (Thumb typing)
>> 
>>> On May 28, 2016, at 1:07 PM, David Moshal <dmos...@gmail.com> wrote:
>>> 
>>> Not sure if this is the best place to put this, I managed to get
>>> MyNewt to build, but ran into same error:
>>> 
>>> This was the missing step (duh):
>>> ```
>>> ⇒  eval $(docker-machine env default)
>>> ```
>>> 
>>> then:
>>> ```
>>> ⇒  ../newt install
>>> apache-mynewt-core
>>> ```
>>> 
>>> and:
>>> ```
>>> ../newt test all
>>> 
>>> All tests passed
>>> ```
>>> 
>>> but:
>>> ```
>>> ⇒  ./bin/my_blinky_sim/apps/blinky/blinky.elf
>>> zsh: exec format error: ./bin/my_blinky_sim/apps/blinky/blinky.elf
>>> ```
>>> 
>>> David
>>> 
>>> 
>>> 
>>>> On Sat, May 28, 2016 at 12:12 PM, David Moshal <dmos...@gmail.com> wrote:
>>>> Ok,
>>>> 
>>>> The twin challenges for a double-newbie are:
>>>> 
>>>> a) selecting the right toolchain and development tools, ide etc.
>>>> - so far I've identified at least ten (mbed, platformio, Kiel, IVR,
>>>> Crossworks, Clion, Sublime (seems most common), etc.
>>>> 
>>>> b) evaluating MyNew against alternatives:
>>>> - no OS (seems most common), FreeRTOS, mBed, etc. etc.
>>>> 
>>>> In each case the defacto evaluation task seems to be blinking the onboard 
>>>> LED.
>>>> 
>>>> So, with regards to MyNewt:
>>>> - I used the Docker install option, but couldn't get the first
>>>> project to work, the error was:
>>>> 
>>>> ```
>>>> ../newt install
>>>> docker: Cannot connect to the Docker daemon. Is the docker daemon
>>>> running on this host?.
>>>> See 'docker run --help'.
>>>> ```
>>>> 
>>>> Note: Docker machine was started without any problem:
>>>> ```
>>>> ⇒  docker-machine start default
>>>> Starting "default"...
>>>> (default) Check network to re-create if needed...
>>>> (default) Waiting for an IP...
>>>> Machine "default" was started.
>>>> Waiting for SSH to be available...
>>>> Detecting the provisioner...
>>>> Started machines may have new IP addresses. You may need to re-run the
>>>> `docker-machine env` command.
>>>> 
>>>> ⇒  docker-machine env default
>>>> export DOCKER_TLS_VERIFY="1"
>>>> export DOCKER_HOST="tcp://192.168.99.100:2376"
>>>> export DOCKER_CERT_PATH="/Users/davem/.docker/machine/machines/default"
>>>> export DOCKER_MACHINE_NAME="default"
>>>> # Run this command to configure your shell:
>>>> # eval $(docker-machine env default)
>>>> ```
>>>> 
>>>> also the simulated version didn't seem to want to run:
>>>> 
>>>> ```
>>>> ⇒  ./bin/my_blinky_sim/apps/blinky/blinky.elf
>>>> zsh: exec format error: ./bin/my_blinky_sim/apps/blinky/blinky.elf
>>>> ```
>>>> 
>>>> 
>>>> So, that's as far as I got with MyNewt.
>>>> Hope it helps.
>>>> 
>>>> David
>>>> 
>>>> ps: do we have a slack channel or Github issue system?
>>>> Easier to past code with markdown than in email.
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Sat, May 28, 2016 at 11:54 AM, Sterling Hughes <sterl...@apache.org> 
>>>>> wrote:
>>>>> Hi David,
>>>>> 
>>>>> On 28 May 2016, at 11:47, David Moshal wrote:
>>>>> 
>>>>>>> i’d be interested in what others (especially newcomers) would have found
>>>>>>> helpful in the release tarballs in terms of documentation.  i feel like 
>>>>>>> we
>>>>>>> have a fairly good set of docs on mynewt.apache.org, but that often 
>>>>>>> people
>>>>>>> want to see the docs next to the source code— and not have to wonder 
>>>>>>> what’s
>>>>>>> on a website.  but i’d take others thoughts here: i usually just go 
>>>>>>> ahead
>>>>>>> and try and break things, and then search for docs after they don’t 
>>>>>>> work.
>>>>>> 
>>>>>> 
>>>>>> Sterling: I'm a double newcomer, i.e: new to MyNewt, and new to embedded
>>>>>> C.
>>>>>> Does that count?
>>>>> 
>>>>> Of course.  We’ll take it in that context, but if you’re willing to take 
>>>>> the
>>>>> time to put your thoughts down- it will only help us.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Sterling

Re: [DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc2

[Sterling Hughes]

Newt run target name will run it in the container-- when using docker the sim 
binary is compiled under Linux to run on Linux.

Sterling 

(Thumb typing) 

> On May 28, 2016, at 1:07 PM, David Moshal <dmos...@gmail.com> wrote:
> 
> Not sure if this is the best place to put this, I managed to get
> MyNewt to build, but ran into same error:
> 
> This was the missing step (duh):
> ```
> ⇒  eval $(docker-machine env default)
> ```
> 
> then:
> ```
> ⇒  ../newt install
> apache-mynewt-core
> ```
> 
> and:
> ```
> ../newt test all
> 
> All tests passed
> ```
> 
> but:
> ```
> ⇒  ./bin/my_blinky_sim/apps/blinky/blinky.elf
> zsh: exec format error: ./bin/my_blinky_sim/apps/blinky/blinky.elf
> ```
> 
> David
> 
> 
> 
>> On Sat, May 28, 2016 at 12:12 PM, David Moshal <dmos...@gmail.com> wrote:
>> Ok,
>> 
>> The twin challenges for a double-newbie are:
>> 
>> a) selecting the right toolchain and development tools, ide etc.
>> - so far I've identified at least ten (mbed, platformio, Kiel, IVR,
>> Crossworks, Clion, Sublime (seems most common), etc.
>> 
>> b) evaluating MyNew against alternatives:
>> - no OS (seems most common), FreeRTOS, mBed, etc. etc.
>> 
>> In each case the defacto evaluation task seems to be blinking the onboard 
>> LED.
>> 
>> So, with regards to MyNewt:
>> - I used the Docker install option, but couldn't get the first
>> project to work, the error was:
>> 
>> ```
>> ../newt install
>> docker: Cannot connect to the Docker daemon. Is the docker daemon
>> running on this host?.
>> See 'docker run --help'.
>> ```
>> 
>> Note: Docker machine was started without any problem:
>> ```
>> ⇒  docker-machine start default
>> Starting "default"...
>> (default) Check network to re-create if needed...
>> (default) Waiting for an IP...
>> Machine "default" was started.
>> Waiting for SSH to be available...
>> Detecting the provisioner...
>> Started machines may have new IP addresses. You may need to re-run the
>> `docker-machine env` command.
>> 
>> ⇒  docker-machine env default
>> export DOCKER_TLS_VERIFY="1"
>> export DOCKER_HOST="tcp://192.168.99.100:2376"
>> export DOCKER_CERT_PATH="/Users/davem/.docker/machine/machines/default"
>> export DOCKER_MACHINE_NAME="default"
>> # Run this command to configure your shell:
>> # eval $(docker-machine env default)
>> ```
>> 
>> also the simulated version didn't seem to want to run:
>> 
>> ```
>> ⇒  ./bin/my_blinky_sim/apps/blinky/blinky.elf
>> zsh: exec format error: ./bin/my_blinky_sim/apps/blinky/blinky.elf
>> ```
>> 
>> 
>> So, that's as far as I got with MyNewt.
>> Hope it helps.
>> 
>> David
>> 
>> ps: do we have a slack channel or Github issue system?
>> Easier to past code with markdown than in email.
>> 
>> 
>> 
>> 
>>> On Sat, May 28, 2016 at 11:54 AM, Sterling Hughes <sterl...@apache.org> 
>>> wrote:
>>> Hi David,
>>> 
>>> On 28 May 2016, at 11:47, David Moshal wrote:
>>> 
>>>>> i’d be interested in what others (especially newcomers) would have found
>>>>> helpful in the release tarballs in terms of documentation.  i feel like we
>>>>> have a fairly good set of docs on mynewt.apache.org, but that often people
>>>>> want to see the docs next to the source code— and not have to wonder 
>>>>> what’s
>>>>> on a website.  but i’d take others thoughts here: i usually just go ahead
>>>>> and try and break things, and then search for docs after they don’t work.
>>>> 
>>>> 
>>>> Sterling: I'm a double newcomer, i.e: new to MyNewt, and new to embedded
>>>> C.
>>>> Does that count?
>>> 
>>> Of course.  We’ll take it in that context, but if you’re willing to take the
>>> time to put your thoughts down- it will only help us.
>>> 
>>> Thanks,
>>> 
>>> Sterling

Re: [DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc2

[Sterling Hughes]

On 28 May 2016, at 10:38, aditi hilbert wrote:


I think John D. Ament raised some good points.

* Nothing in our binaries say Mynewt - do we need to by Apache rules?
* Our repos already include mynewt - so we should be fine there.
*  the package "apache-newt" lacks a NOTICE/LICENSE file
* our license includes references to code that doesn't match our 
notice - not sure which ones?




We don’t need it to say Mynewt by apache rules, John was pointing out 
that it was confusing to him.


apache-newt does have a NOTICE/LICENSE file now, that is why Chris 
repackaged the release.  for some reason, only the newt directory of 
apache-mynewt-newt was included in the source tarball of newt.


LICENSE/NOTICE issues can be resolved in a subsequent release IMO.  We 
have kept all the license info out of NOTICE, which I actually believe 
is appropriate: I don’t believe we’re required by BSD license to put 
that in a notice file (LICENSE should suffice.)


i’d be interested in what others (especially newcomers) would have 
found helpful in the release tarballs in terms of documentation.  i feel 
like we have a fairly good set of docs on mynewt.apache.org, but that 
often people want to see the docs next to the source code— and not 
have to wonder what’s on a website.  but i’d take others thoughts 
here: i usually just go ahead and try and break things, and then search 
for docs after they don’t work.


cheers,

sterling

Javascript Support (was Re: [SUMMARY][DISCUSS] A users@ mailing list for Apache Mynewt)

[Sterling Hughes]

I'd like to echo the sentiments here: I think this would be great.

I think good scripting language support is very important for Mynewt. 
Most of the newer chipsets (like the NRF52), have enough RAM and Flash, 
that you can run the OS, Bluetooth stack, and still have 256KB or more 
left over for a fairly complex application.  Also, you could imagine the 
Mynewt OS being preloaded on boards, and then someone uploading code to 
them using firmata -- whether it be Javascript, Python or Wiring code. 
This would provide a simple programming model, but enable full OS 
support -- and I think this could be easily integrated into PlatformIO 
or the Arduino IDE.


Additionally, if you look at a lot of the popular scripting languages 
(Espruino, Micropython, Wiring) -- they end up having to implement a 
whole bunch of things better left to the operating system (HAL, BSP, 
Network stacks, Drivers.)  If they can plug in to Mynewt, they don't 
have to worry about any of that.


I don't know how much time I have in the next couple of months to devote 
to this, but count me in on joining in the development/helping to 
support as much as possible.   I'll definitely test things :-)


Some thoughts on the various options for Javascript.  This is meant as 
more of a dump of what I've looked at / been thinking about in case you 
find it useful:


- Jerryscript: Apache 2 license, which is critical should we want to 
bundle it with Apache Mynewt.  It looks like a good Javascript 
interpreter, my only concern is that it separates the compile & run 
stages, and I'm not sure how memory efficient the compiler is.


What's very nice is that Jerryscript is just the Javascript engine, and 
it looks fairly easy to write custom extensions for it.  If somebody 
could evaluate the memory usage when parsing, it would be great.


- Espruino: Espruino's popularity is, I think, due to the fact that it 
provides a full operating environment, not just the Javascript engine 
itself.  It looks pretty solid, and both the parser and engine have been 
shown to run on exactly the microcontrollers we've been targeting.


Espruino uses the MPL, and has a copy-left license, which is somewhat 
more restrictive then the Apache license.  It is also less complete than 
Jerryscript, from what I can see.


- v7 is GPL.

- Javascript to Lua compilation:  We already support Lua, and it's an 
incredibly efficient virtual machine for these small environments. 
Since Javascript is made to be compiled, and recompiled -- we could 
support Javascript today through a JS->Lua compiler.  This would also 
mean we only needed to do the language bindings once, and could run both 
options.


The downside is, what actually runs is Lua, not Javascript.  There 
wouldn't be a Javascript console on the device.


(compilers: https://github.com/PaulBernier/castl,
https://www.npmjs.com/package/lua-colony)

I personally like the Jerryscript option the best (thus far), due to the 
license, and the fact that it's just a JS engine.  Followed probably by 
the JS->Lua compiler (which, with one effort gets us both Lua & JS 
support.)


I don't imagine getting Jerryscript ported will be a whole bunch of 
work, it's just importing it into our build system.  I think the big 
effort will be around making sure we choose the right OS APIs.  I think 
it will be good to look at a few things on the OS side, to make it 
easier for the Javascript integration:


- Ensuring our BLE APIs are designed to map easily to the JS interpreter

- Adding some form of sensor API, to abstract access to common sensors

- Adding a bunch of higher level drivers (above the HAL), that provide 
simpler APIs to access hardware functions -- that we then map into JS.


But first things first, just getting the interpreter up & running & 
talking to the OS would be awesome!


Sterling



On 5/25/16 7:57 PM, David Moshal wrote:

Ok David, I'm game.

I'm familiar with NodeJs, have mission critical NodeJs software in
production, with no downtime, since 2011.

I don't know what platforms MyNewt runs on, but you're going to need
significant horse power to run the NodeJs V8 engine.  I've run NodeJs on
the Arduino YUN (400Mhz, 64Mb ram), using Linux, so that's probably the
ballpark, spec-wise.

On the other hand, if what you want is a Javascript engine in general, then
there are at least half a dozen alternatives. I've used Espruino, on its
own Pico board (STM32f401), and on ESP-8266 (32bit Tensilca core). There
are others, V7, TinyJS, JerryScript, etc.

So, what are the next steps? What's the best IDE environment to use (I'm on
OSX).
Can Platform.IO be used, or is that a competitor?

Dave






On Wed, May 25, 2016 at 4:56 PM, David G. Simmons  wrote:


Maybe we should work together! My goal is to get Javascript (actually
Node.js) running on MyNewt. I have C experience, but there is lots to do in
order to make this work the way I need it to.

Best regards,
dg


On May 25, 2016, at 6:49 PM, David Moshal 

Re: Javascript Support (was Re: [SUMMARY][DISCUSS] A users@ mailing list for Apache Mynewt)

[Sterling Hughes]

Oh, and on PlatformIO --

- They do have a build & package management system which has some of the 
same functionality of newt.


- That said, it's mostly focused on their IDE.

- If we can make our stuff work more easily with Apache Mynewt -- I'm 
all for it!


Sterling

On 5/26/16 12:19 AM, Sterling Hughes wrote:

I'd like to echo the sentiments here: I think this would be great.

I think good scripting language support is very important for Mynewt.
Most of the newer chipsets (like the NRF52), have enough RAM and Flash,
that you can run the OS, Bluetooth stack, and still have 256KB or more
left over for a fairly complex application.  Also, you could imagine the
Mynewt OS being preloaded on boards, and then someone uploading code to
them using firmata -- whether it be Javascript, Python or Wiring code.
This would provide a simple programming model, but enable full OS
support -- and I think this could be easily integrated into PlatformIO
or the Arduino IDE.

Additionally, if you look at a lot of the popular scripting languages
(Espruino, Micropython, Wiring) -- they end up having to implement a
whole bunch of things better left to the operating system (HAL, BSP,
Network stacks, Drivers.)  If they can plug in to Mynewt, they don't
have to worry about any of that.

I don't know how much time I have in the next couple of months to devote
to this, but count me in on joining in the development/helping to
support as much as possible.   I'll definitely test things :-)

Some thoughts on the various options for Javascript.  This is meant as
more of a dump of what I've looked at / been thinking about in case you
find it useful:

- Jerryscript: Apache 2 license, which is critical should we want to
bundle it with Apache Mynewt.  It looks like a good Javascript
interpreter, my only concern is that it separates the compile & run
stages, and I'm not sure how memory efficient the compiler is.

What's very nice is that Jerryscript is just the Javascript engine, and
it looks fairly easy to write custom extensions for it.  If somebody
could evaluate the memory usage when parsing, it would be great.

- Espruino: Espruino's popularity is, I think, due to the fact that it
provides a full operating environment, not just the Javascript engine
itself.  It looks pretty solid, and both the parser and engine have been
shown to run on exactly the microcontrollers we've been targeting.

Espruino uses the MPL, and has a copy-left license, which is somewhat
more restrictive then the Apache license.  It is also less complete than
Jerryscript, from what I can see.

- v7 is GPL.

- Javascript to Lua compilation:  We already support Lua, and it's an
incredibly efficient virtual machine for these small environments. Since
Javascript is made to be compiled, and recompiled -- we could support
Javascript today through a JS->Lua compiler.  This would also mean we
only needed to do the language bindings once, and could run both options.

The downside is, what actually runs is Lua, not Javascript.  There
wouldn't be a Javascript console on the device.

(compilers: https://github.com/PaulBernier/castl,
https://www.npmjs.com/package/lua-colony)

I personally like the Jerryscript option the best (thus far), due to the
license, and the fact that it's just a JS engine.  Followed probably by
the JS->Lua compiler (which, with one effort gets us both Lua & JS
support.)

I don't imagine getting Jerryscript ported will be a whole bunch of
work, it's just importing it into our build system.  I think the big
effort will be around making sure we choose the right OS APIs.  I think
it will be good to look at a few things on the OS side, to make it
easier for the Javascript integration:

- Ensuring our BLE APIs are designed to map easily to the JS interpreter

- Adding some form of sensor API, to abstract access to common sensors

- Adding a bunch of higher level drivers (above the HAL), that provide
simpler APIs to access hardware functions -- that we then map into JS.

But first things first, just getting the interpreter up & running &
talking to the OS would be awesome!

Sterling



On 5/25/16 7:57 PM, David Moshal wrote:

Ok David, I'm game.

I'm familiar with NodeJs, have mission critical NodeJs software in
production, with no downtime, since 2011.

I don't know what platforms MyNewt runs on, but you're going to need
significant horse power to run the NodeJs V8 engine.  I've run NodeJs on
the Arduino YUN (400Mhz, 64Mb ram), using Linux, so that's probably the
ballpark, spec-wise.

On the other hand, if what you want is a Javascript engine in general,
then
there are at least half a dozen alternatives. I've used Espruino, on its
own Pico board (STM32f401), and on ESP-8266 (32bit Tensilca core). There
are others, V7, TinyJS, JerryScript, etc.

So, what are the next steps? What's the best IDE environment to use
(I'm on
OSX).
Can Platform.IO be used, or is that a competitor?

Dave






On Wed, May 25, 2016 at 4:56 PM, David G. Simmon

Re: [SUMMARY] [DISCUSS] A users@ mailing list for Apache Mynewt

[Sterling Hughes]

Hi David,

Good to see you on the list.

On 25 May 2016, at 15:49, David Moshal wrote:


Thanks, actually I've been using both lua and JavaScript (espruino) on
esp8266-12e for a couple months.

As mentioned to Sterling at the maker faire last weekemd, my interest 
in
mynewt is actually to try and embedded js on the emw3165, which has 
the

stm32f411 plus wifi.

However I have zero experience with c, and specifically with the tool 
chain

and use setup.


The documentation, especially here is pretty good:

http://mynewt.apache.org/os/tutorials/arduino_zero/

Picking a board we support and trying to get that up & running is 
probably the best first step.


We are on #mynewt on freenode, if you need help getting it up & running, 
and would be happy to support you.


Porting Mynewt to a new board will be very low layer, but we’d be 
happy to help if you want to try it.  Probably easiest to chat via IRC.


Best,
Sterling

Re: Enabling the Nordic HAL gpio external IRQ detection

[Sterling Hughes]

Hi Wayne,

I’m working on fleshing out the HAL for Nordic chips as we speak, but 
going slowly.


If you’d like to make the changes, I’d make sure to merge anything 
you did into my work, and we’d appreciate the contribution.  If 
you’d like me to make them, I can reorg some stuff and make sure to 
get that in first, but can’t promise it will be before early next week 
at this point, given everything else going on.


Best,

Sterling

On 1 Jun 2016, at 1:24, Wayne Keenan wrote:


Hi,

I'd like to detect button pressed via IRQ based edge detection because 
polling gpio pins is currently not a practical solution for my 'app'.


I could just remove  the #if defines in the hal .c and just try it but 
those are obviously there for a 'bigger picture' reason.


I couldn't find an open issue on JIRA so wondered if anyone could 
please let me know a bit more and if this is on anyones radar?


All the best
Wayne

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc2

[Sterling Hughes]

Hey Chris,

On 29 May 2016, at 13:14, Christopher Collins wrote:


I'm attaching git diffs between the following two revisions:
a: commit when BSD license text was added (mbed repo)
b: first commit to the mynewt core repo.

The Mynewt files are "b" in the attached diffs.  That is, "+++" are
changes added by Mynewt; "---" is removed by mbed.


Of course I attached the wrong diffs.  Here are the correct ones.

Sorry about that!

Chris


Thanks for doing this.

Given that we’ve already released multiple versions of Mynewt with 
CMSIS header files, we’re releasing a 0.9 and ARM has pretty much 
licensed every other version of this header file under a BSD license in 
recent years — I’d vote that we add an item in the NOTICE file, and 
release.  This is an area where we’re not wholly in accordance with 
policy, but I think the risk to the end user is very low, and all of our 
previous releases have had this issue.


For reference, the file that is being changed contains offsets to 
interrupt vectors on ARM platforms.  The new (correctly) licensed 
functions look perfectly fine to me, and I think post release (and in 
develop) we should replace these files.  But I’d like to have some run 
time with them (more than a few days), prior to releasing, in case 
anything subtle occurs that we don’t catch in our regression tests.


Justin/Chris — would that be fine for you?

Sterling

Re: 6LoWPAN over BLE

[Sterling Hughes]

Hi Jan,

Schoene Gruesse aus Kalifornien!

On 23 Jun 2016, at 7:55, Jan Rüth wrote:


Hi (skip the first paragraph to get to the actual topic),

first of all thanks for the project, I came across it yesterday and it
was ridiculously easy to get it running on my nrf51 based blenano from
RedBearLabs. Even though the new Docker version on OS X isn't capable 
of
passing USB (the MK20 that comes with the blenano) devices to the VM, 
I

managed to flash the images using OpenOCD natively (after painfully
realizing that 0x800 and 0x8000 are two very different addresses).



:-)


Actual topic here:

I was wondering about the state of IPv6 over BLE in the project.
The BLE stack introduction lists it as a roadmap item:

"Enables users to assign an Internet Protocol (IP) address (complaint
with the IPv6 or 6LoWPAN standard) to a Bluetooth device through
Internet Protocol Support Profile (IPSP) Roadmap"

I could not find it in the JIRA tracker as an item, is this already
implemented? And if so, are there examples how to use it or can you
guide me to the appropriate APIs?

If not, do you guys know when this will be added to the OS?



I don’t think as a project we’ve planned IP support, however, I’ll 
tell you what Runtime is working on.


The plan is to integrate a socket API (marko recently posted to the 
dev-list): 
http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201606.mbox/%3C248CFDC8-021F-406D-A489-94C945541504%40runtime.io%3E


We’re doing this to support the new Arduino boards, which either have 
a WNC1000 from Atmel (Arduino MKR1000) or an ESP8266 on them.  These 
chips don’t require a full IP stack, but rather offer an AT interface 
to them.  We would abstract the API to these chips through our 
“standard” socket API.


Then, in the August/September timeframe we’ll start looking at adding 
IPv4 and IPv6 support to the Mynewt OS (for a post 1.0 release.)


_BUT_ if somebody wanted to get to this sooner, I think it would be 
awesome.  It’d be good to link up with Marko.


Current thoughts are to smash together uIP (good IPv6) and LWIP (good 
IPv4), and have them plug into this socket API.  Then, convert both of 
those stacks to use our MBUF APIs — so the BT stack and the IP stack 
would be using the same kernel buffering scheme.  We’d then start 
hammering on them to make sure the resulting stack was solid/optimize 
memory usage/test features/etc.


I'm supervising a communications lab at my university in the next 
winter

term and I was thinking about using mynewt as the foundations for
various projects there and getting IP connectivity would be a big 
plus.

I could also imaging that the lab students implement parts of rfc7668
for mynewt, what is your opinion on that?



That would be awesome, and I think the timing here would work out.  
We’ll have the basics of the stack up & running by that point for 
sure.


Best,
Sterling

Address Randomization in net/nimble

[Sterling Hughes]

Howdy:

How hard is it to get address randomization in the net/nimble stack?  I 
realize that full Bluetooth security is probably a month or two away, 
but would it be possible to just provide the randomization component of 
it, for privacy and tracking considerations?


Sterling

Re: [jira] [Resolved] (MYNEWT-16) need to be able use json without floating points

[Sterling Hughes]

On 2/6/16 11:45 AM, Marko Kiiskila (JIRA) wrote:


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

Marko Kiiskila resolved MYNEWT-16.
--
 Resolution: Fixed

If you want it, define FLOAT_SUPPORT either in project.cflags,
or in target cflags.



I think this should be a capability (that generates a cflag), not a cflag.

To me the difference is a cflag is something that a single package might 
expect, whereas we should start having a few defined "capabilities" 
(SHELL, NEWTMGR, FLOAT_SUPPORT), that then generate different cflags 
based on the egg being compiled.


Perhaps this isn't the best mechanism, but I'm not sure just writing 
cflags is either...


Thoughts?

Sterling

Re: Larva content review for license

[Sterling Hughes]

On 2/5/16 8:39 AM, marko kiiskila wrote:

First of all; thanks for going through the licenses. This is good info.


On Feb 4, 2016, at 8:03 PM, Sterling Hughes <sterl...@apache.org> wrote:




We can raise this with legal, alternatively we could move the MCU &
BSP definitions to github.  People would need to config newt to point
at the github URL (newt add-clutch), but it would get around ASF
license issues.


Only if it’s considered an optional dependancy, but I think that is the
case. i.e. It not required for newt/larva to work. We had similar issue
with Adobe licensed software and Apache Flex.



It is an optional dependency.  These files are board support headers and 
drivers for the STM32F3Discovery board.  We'll have support for Nordic, 
Arduino, other STMicro boards in the default release - it would be just this 
board that was banished to Github.  Plus, it will be fun to test out if our 
clutch system actually works :-)


Ah, well that finding is inconvenient.

However, the good thing is that the stm32f3xx driver library dependency
in actuality is pretty small. I can drop that altogether.

Given that I brought it in, I can take it out.
—


I also think it will be good to have one external dependency on GH.  It 
adds a bit of visibility to start having a set of 3rd party packages :)


Sterling

Re: Vanity import domain

[Sterling Hughes]

Hi Justin,

mynewt.io would be a vanity domain to make git imports simpler, so 
instead of doing:


import (
"git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt/cli"
)

You'd do:

import (
"mynewt.io/newt/cli"
)

And for installation of packages, you would do:

go install mynewt.io/newt

Instead of:

go install git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt

All the cool kids are doing it :-)

mynewt.io would just provide a set of go metadata.

We (runtime) have purchased and set this up, because we are lazy and 
don't like typing things.  We'd be happy to gift this to the ASF, and 
run it on ASF infrastructure (perhaps redirect to 
mynewt.incubator.apache.org).


I'd be interested in your view, but to me, I feel like this is a nice 
developer convenience that makes us agnostic to git structure, and if 
the Mynewt project ever decided Runtime were being bad citizens, it's a 
very quick change to the source code to remove these references.


Sterling


On 2/4/16 1:11 PM, Justin Mclean wrote:

Hi,

I may be missing something but this may not be the best idea from a being open 
point of view. Who has access to mynewt.io? How are changes tracked? How do 
committers make changes?

Justin

Re: Mailing lists

[Sterling Hughes]

absolutely, let's update it!

On 2/4/16 4:31 PM, Justin Mclean wrote:

Hi,

Notice the readme’s at [1][2] are pointing people to stack-...@googlegroups.org 
shouldn’t it be this mailing list instead?

Thanks,
Justin

1. https://github.com/apache/incubator-mynewt-tadpole
2. https://github.com/apache/incubator-mynewt-larva

Re: Larva content review for license

[Sterling Hughes]

On 2/4/16 7:55 PM, Justin Mclean wrote:

Hi,


If you'd like to create an overall shout-out, then go for it. The
Subversion project does this, and uses the same file to track partial
commit (as Mynewt has adopted). See:
http://svn.apache.org/repos/asf/subversion/trunk/COMMITTERS


Apache Flex does this a little differently and names people by release:
https://github.com/apache/flex-sdk/blob/develop/CONTRIBUTORS

(Note this includes people who are not committers, the idea behind it was to 
encourage them to become so.)

But it not a requirement and each PMC can decide on how to or not do it.



This seems good to me.

At some point it seems like we'll want MAINTAINERS, as there is a fair 
amount of specialization (an OS is technically very broad.)  But I guess 
we can start breaking things into sub-projects when we hit that problem. 
(*)


Sterling

(*) As an example, net/nimble is the _first_ open-source Bluetooth stack 
(both Host & Controller) for MCUs.  Given contributor bandwidth, IMO it 
makes sense to bundle governance in with Mynewt, but over time I could 
imagine this being MCU agnostic and being its own Apache project in the 
Mynewt ecosystem.

Re: Larva content review for license

[Sterling Hughes]

rel_v0_0_8-b1 for example.

- newt's built in package manager knows to fetch packages from that
git branch (we make the changes to newt once we branch.)


May be an issue with this (I think not 100% sure), does that imply that
a release can basically change over time? Or that it would be
downloading un-released software?



I misspoke, it's probably a tag not a branch.  I guess somebody could 
always move a tag, but somebody can always replace a tarball too.


I'm pretty flexible about how we push this out -- feedback and thoughts 
are really welcome.  Let me give some quick technical background for the 
uninitiated.




newt is the build and package management tool that pulls the various 
components of our OS together and generates builds.   A collection of 
eggs (packages), forms a nest.  And newt knows how to build all the eggs 
in a nest.  "Larva" is our default nest, with a collection of eggs.


In newt, you can generate what is called a clutch.  A clutch is a 
snapshot of the eggs in a given nest at a given point in time.  As an 
example, here is the start of a clutch file generated on git master larva:


$ newt nest generate-clutch larva http://mynewt.apache.org
name: larva
url: http://mynewt.apache.org
eggs:
project/test:
vers: 0.1.0
hash: 8de883b9aa460677bb79da3c495fc654186b017e
deps:
- fs/nffs@none#stable
- libs/testutil@none#stable
- libs/os@none#stable
- libs/bootutil@none#stable
- libs/testreport@none#stable
hw/bsp/stm32f3discovery:
vers: 0.0.0
hash: 73f2aa944dec135e07891f4f0a1e154858b99024
deps:
- hw/mcu/stm/stm32f3xx@none#stable
project/blinky:


A user can configure newt to look at remote clutch files (HTTP or GIT), 
and newt will go read those files and install them in the user's local 
nest (along with resolving any dependencies.)


The idea is that the core of Mynewt will mature in the ASF, and people 
will get the default set of packages from there, and those packages will 
track along with overall project maturity (e.g. they'll be stable 
someday :-)


However, around this core, hopefully people will be adding all sorts of 
cool things around Mynewt.  These could be either Apache sub-projects 
(ala Hadoop ecosystem), corporations who share code across projects or 
just some guy who happened to put a cool library on Github.  Each of 
these would generate and distribute their own clutch-file, which the 
newt tool can be pointed at.






For something to be a release it must be voted on and while in
incubation also voted on by the incubator PMC. So as long at that git
branch only contained approved software that would be fine.


Agree.




- We build newt for all supported platforms (Linux, Mac OS X, Windows)
-- and we distribute that, along with necessary LICENSE files on our
website.


Best to distribute via the apache mirrors, there a cgi script you can
use to grab the artefacts from the nearest mirror. Not there must needs
to be a source only release and an optional binary convenience release.



Agree.  We'll need some help with this once we've got the tarballs.



- Those eggs then come with individual LICENSE files, which have their
license info.


Yep the LICENSE (and NOTICE) files need to reflect only what is bundled
in the artefact downloaded.


They are Apache -- can you point me to the specific files you're
referencing so I can double check?

./hw/bsp/nrf51dk/include/bsp/cmsis_nvic.h
./hw/bsp/nrf52pdk/include/bsp/cmsis_nvic.h
./hw/bsp/olimex_stm32-e407_devboard/include/bsp/cmsis_nvic.h
./hw/bsp/stm32f3discovery/include/bsp/cmsis_nvic.h
./libs/cmsis-core/src/cmsis_nvic.c



Thanks I'll dig into these & report back.


Anyhow, here is the FatFs license, it is liberal


Yep no issue there.


We can raise this with legal, alternatively we could move the MCU &
BSP definitions to github.  People would need to config newt to point
at the github URL (newt add-clutch), but it would get around ASF
license issues.


Only if it’s considered an optional dependancy, but I think that is the
case. i.e. It not required for newt/larva to work. We had similar issue
with Adobe licensed software and Apache Flex.



It is an optional dependency.  These files are board support headers and 
drivers for the STM32F3Discovery board.  We'll have support for Nordic, 
Arduino, other STMicro boards in the default release - it would be just 
this board that was banished to Github.  Plus, it will be fun to test 
out if our clutch system actually works :-)


Sterling

Bye Bye Eggs :-(

[Sterling Hughes]

Hey,

I have implemented the bug report here: 
https://issues.apache.org/jira/browse/MYNEWT-71


I think everyone has noticed that on-boarding new users becomes 
difficult because we use custom terms for packages, package lists and 
repositories.  While I personally like these terms (I named them that 
way), I think we wan the package and build system to be as easy to use 
as possible, and keeping track of these seems to be creating too much of 
a hurdle.


So, I have a bunch of mondo commits to rename these.  They are low risk, 
and I've tested them.


When I commit, in order to maintain your existing targets, you will need 
to do the following:


- rename .nest in larva to .repo (this is custom per install, so I 
can't move this for you)


- rename nest.db to repo.db in .repo

- rename clutches/ directory pkg-lists/ in .repo

Everything else should operate well, unless you have changes to egg.yml 
files that are uncommitted.  You will need to manually port those over.


Also, as a part of this commit, I've removed .git from the newt import 
path.  It seems like the majority of people are able to go get this 
without the .git, and it was causing conflicts with newtmgr.  (*)


I'll push these to origin master this evening if nobody has objections.

Sterling

(*) These will eventually be moved, again, when Todd adds 
mynewt.apache.org support.

Re: [2/2] incubator-mynewt-larva git commit: Simpler linker script for STM32F3 discovery board.

[Sterling Hughes]

Re [1] - Thanks, will do.

Re [2] - What defines major? :-)  I ask this because of libjson.

We've taken microjson (http://www.catb.org/esr/microjson/), and are 
doing some fairly major surgery to it:


- conversion into our coding standards (tabs to spaces, line length)
- removal of all logging statements
- addition of support for non-contiguous buffers (instead of *p++, call 
a read_next_byte() handler.)

- removal of time support APIs

Would these go under the original license terms?  And, if so, what would 
be a case where it wouldn't go under original license terms.


Sterling

On 2/5/16 3:59 PM, Justin Mclean wrote:

Hi,


I will try and find some time this weekend to do a run through of the entire 
source code base and update this.  Tedious, but it will only get more tedious.


This should help and has the correct text [1]

One of the other things I noticed while doing the license review is that serval 
files incorrectly have a Runtime Inc header on top of another say BSD header. 
In most cases a file should only have one header (i.e. that of the original 
copyright owner). See [2].  This can get tricky when you start making changes 
to a file and at some point the header may need to change.

Thanks,
Justin

1. http://www.apache.org/legal/src-headers.html#headers
2. http://www.apache.org/legal/src-headers.html#3party

Re: [2/2] incubator-mynewt-larva git commit: Simpler linker script for STM32F3 discovery board.

[Sterling Hughes]

I agree.

I will try and find some time this weekend to do a run through of the 
entire source code base and update this.  Tedious, but it will only get 
more tedious.


sterling

On 2/5/16 3:47 PM, Justin Mclean wrote:

Hi,

Probably should start getting into the habit of putting in the correct 
copyright header i.e. Apache not RunTime Inc. All part pf the legal and 
branding obligations of being an Apache project. Also one less to change later.

Thanks,
Justin

OS Task Statistics

[Sterling Hughes]

Heehaw,

I'm looking to add statistics to the core RTOS (libs/os), to improve
instrumentation.

Here are the commands, and data I'm bring back in those commands.  I'd
love people's input on what else they think should be included here.

Taskinfo:

- Array of tasks, each containing:
  - Task Name
  - Priority
  - Number of context switches
  - Task Run Time
  - State (RUN, SLEEP, SEM_WAIT, MUTEX_WAIT)
  - Stack Usage
  - Stack Size
  - Last Sanity Checkin
  - Next Sanity Checkin

Memory Pool Info:

- Array of memory pools, each containing:
  - Memory Pool Name
  - Pool Element Size
  - Number of blocks in the pool
  - Number of free blocks in the pool
  - Address of last free, and allocate from this pool
(Should this be a variable size array?)

Also, right now memory pools are not centrally linked.  This change
would require there to be a list of all memory pools initialized by
the system, adding 4 bytes to the mempool structure, and 4 bytes of
.bss.  Any objections?

Sterling

Re: Add my jira user to Mynewt

[Sterling Hughes]

I'll do this
Sterling

On 2/23/16 10:27 AM, todd mitton wrote:

Hi Justin,

Could you please add my jira user (mitton) to Mynewt?  Aditi would like to
assign tickets to me.

Thanks,
-Todd

Re: Planning to add log facilities

[Sterling Hughes]

Welcome Gordon!

That would be awesome.

Sterling

On 2/22/16 3:37 AM, Gordon Chaffee wrote:

Hi, I'm new to the list, and I'm working on some code to extend the
existing logs capabilities. Specifically, I'm planning to add the following:

newtmgr:
- Create 'logs' command for dealing with logs
- Add 'logs show' command for pulling logs from the target device
- Add 'logs clear' to erase the existing logs on the target device

newt:
- Implement the facility to encode logs for newtmgr

I'll be following up with some pull requests shortly that will implement
these. I'd welcome any feedback you might have.

TIA,
Gordon

Re: Bye Bye Eggs :-(

[Sterling Hughes]

On 2/24/16 1:06 PM, aditi hilbert wrote:

Sorry to pipe up late and I know how involved the changes are but I need to 
understand the reasoning better to be able to document properly.

For the most part I get the changes and agree with them. The only one that I am 
struggling with is “app” instead of “nest”. The term “application" doesn’t quite 
convey the sense of a collection (repo) even though that’s what it is (our larva, tadpole 
etc.). And the packages in such a nest (legacy term) could be composed to enable 
different applications in the real world from a user perspective. I am wondering whether 
“workspace” or “app container” or simply “repo" conveys the meaning better.



I really didn't like "repo" or "repository" -- it made sense to me, but 
people got confused by git repository vs our repository.


"workspace" is good too, and I'm happy to change it if people prefer 
that.  I did application because that was the more common term (ruby on 
rails, node, etc.)   That said, this is kinda a different space.


For context, an application is where you keep all of your packages for a 
class of device.  Projects are where the main() function resides, and 
specify the set of linked packages that compose software that gets 
built.  So think of project as the top level src/ directory, and an 
application as a combination of src/ and any linked libraries.


I'd really be interested in other people's thoughts here, what makes 
more sense to you:


  [  ]  workspace/application
  [  ]  application/project

Sterling

Re: hal organization and multiple smaller packages

[Sterling Hughes]

On 2/22/16 1:24 PM, will sanfilippo wrote:

My 1/2 cent on this topic (and I certainly dont think you killed the 
discussion; it is a difficult topic):

* I think the HAL is meant to be a fairly general, simple, abstraction. 
Hopefully over time we will be able to incorporate more advanced HAL features, 
but most HALs I have seen implement the basics and I bet that works for most 
folks.
* I think the HAL should live in hw/mcu. Well, api in hw/hal and implementation 
in hw/mcu.
* As sterling says, drivers can be built that use the HAL. Take the external 
ADC example. There would be a driver for that ADC chip that would use a SPI HAL 
if it had SPI. For internal ADCs, the HAL provided in hw/hal should be enough 
as I suspect it will (eventually), implement what most folks want.
* As far as being able to see what features of a HAL are implemented, I dont 
see why this is such a problem but it is probably because I am not thinking of 
“beginner” users. Doesnt seem terribly difficult to document, on a per mcu 
basis, which features of the HAL are supported by that particular MCU. And if 
the developer calls an API with some parameters that are not implemented on 
this MCU they get an error. Part of the problem I have with this is is my own 
personal bias: I would never blindly call HAL functions without first reading 
the chip documentation. I dont see why anyone would do such a thing :-)
* I am not a fan of runtime HAL introspection APIs. To me, that is just extra 
code that serves very little useful purpose.


I agree with no runtime, but think there should be capabilities on a 
more granular basis.


i.e. a driver can require a hal-adc, or hal-gpio capability, and an MCU 
can export these, rather than the just "hal."



* I think the HALs should allow for the user to choose which “peripheral” to 
bind to and that is done through the BSP or the HAL API itself. For example, 
the user should be able to pick ADC #1 or ADC #3.
* I do agree that sometimes it is difficult to know that you need to call 
functions like bspProvideADCconfig() and the like. Not sure how this gets 
solved other than documentation and looking at examples that we provide.



IMO, the HAL should provide APIs to do this, and the BSP should call 
those APIs.


Did you see other email: what do you think about flash?  Should the HAL 
APIs just apply to internal flash / should we get rid of HAL Flash 
altogether, or should HAL flash encompass both internal & external 
flashes...?


Sterling

our HAL and the new mbed-hal

[Sterling Hughes]

Hi,

I posted:

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

If folks have a little spare time to look at this over the weekend, I'd 
be super appreciative for any thoughts people have.


I've spelled out what I'm thinking in the comments section.  But the 
summary here is: it would be good to have some re-use of the mbed-hal 
work, and not force chip vendors who are doing new microcontrollers to 
implement both mbed's hal and ours.


The ideal case would be that we can map our HAL to Mbed's HAL, and then 
find someway that we can use our package system to include all the 
mbed-hal libraries.  That way, for ARM Cortex-M* platforms, we can share 
effort on the HAL.


And the benefit to keeping our HAL, and developing against it -- we can 
be microcontroller architecture (i.e. non-ARM) agnostic.


Anyhow, please do look through the mbed-hal, and an implementation:

https://github.com/ARMmbed/mbed-hal (top-level HAL apis)
https://github.com/ARMmbed/mbed-hal-silabs (general silabs hal)
https://github.com/ARMmbed/mbed-hal-efm32gg (EFM32 silabs chipset impl)

(there are more links in the ticket)

Thoughts?  Issues?

Sterling

Re: our HAL and the new mbed-hal

[Sterling Hughes]

On 2/28/16 10:02 PM, will sanfilippo wrote:

Given the current state of the Mynewt hal, I think the question we need to 
answer is whether or not the mbed hal provides the functionality we think 
developers will need. Looks like what mbed is doing and mynewt is doing are 
very similar. Why not just co-opt the mbed HAL entirely? I cant think of a good 
reason not to, but I have not looked at the mbed hal in enough detail, 
especially in regard to bsp.

Anyway, i dont think it will be hard to map mynewt to mbed. I just dont like it 
if it adds another layer of indirection (i.e. efficiency).



I think we will need to: mbed-hal is being developed only for ARM 
processors.  If we want to use the HAL on other MCUs (MIPS, 8051, Intel, 
etc.) -- it would be good to have this mapped.


It seems like a lot less work to map the API into ours (once), then have 
to maintain mbed-hal separately from ARM for non-ARM MCUs.


Sterling

Re: "newt target label" command question

[Sterling Hughes]

that’s right. The manifest file contains items which describe the build. I.e. 
info about what packages were included, their
version numbers, time of the build, target definition etc.

The reason I added this was because I did not want to have to build bin2img, a 
separate target, just to assign
a version number to an image.
Previously what you had to do (when you wanted to have a meaningful version 
number for your build), was
to execute ‘newt target build’ for your target and run bin2img manually.
Part of this was hidden by the download scripts, which executed bin2img 
automatically, but the version number
assignment was problematic.

Now you can execute ‘newt target label’, and this builds your image, creates 
image file with header file and version
number on it. Also creating this manifest file in the process. In fact, I was 
going to get rid of bin2img tool completely.



+1


Our targets don’t contain info about whether image header is required or not. 
So it is up to the user to know
whether they execute ‘newt target build’ only or ‘newt target label’.



So build creates the ELF file, and label creates the image that the 
bootloader can... boot.  Is that correct?


I assume these are broken into 2 steps, because you don't want to 
re-build the target when you build the image.


I think label is a little confusing, I get it: you are labeling the 
binary, but I think we should name it more explicitly: what about 
create-image?


 >> 2. Is version number the only input allowed now or can we add other 
labels to the image header? In the future?


There is something else also. I changed the image format such that you can have 
TLVs at the end of image.
First TLV I added was SHA over the image; bootloader checks that this matches 
the binary before executing
it. Next I would add optional signature TLV (RSA or similar) calculated over 
the SHA. This so that you can create
products where bootloader only allows signed images to boot.



+1

Sterling

Documentation & ease of use

[Sterling Hughes]

Howdy,

For those of you on the list not at Runtime, you may have noticed a slow 
down in commits.  Internally, we're making a push towards documentation 
and ease of use, now that we're moving towards releasing / releasing. 
Everyone is sitting and dutifully writing docs.


As its a Friday, I'm holding on some threads that I'll kick off next 
week, specifically:


- Roadmap: all of us have been spending a fair amount of effort getting 
the releases planned out in JIRA.  This will need to get turned into a 
project roadmap, as we start planning things out.


- Release Notes: as we start releasing, I think it will be critical to 
have detailed release notes.  Especially as we are getting out there 
with quite a few known bugs and Mynewt is under fairly active development.


- Release artifacts & branching strategy: it became apparent in our last 
release that we have a ways to go in order to make our method of 
distribution compatible with ASF release procedures.  Further, as we 
begin managing releases we'll need a clearly articulated branching strategy.


Fun.  That's all next week...

But for now, I wanted to make a quick point: we are NOT code freezed for 
Beta 2.  So, as you document things, if you find little ways to make the 
code easier to use, or see obvious bugs.  Let's fix it!  :-)


Sterling

Re: Question on nlip protocol and log messages

[Sterling Hughes]

- Allow for mutex protection around console_write(), and block between
multiple tasks calling to the console.  NLIP can handle interleaved
data, between calls to console_write().  (*)

The downside here is that calls to console_write() will block.  So if
you have a higher priority task that wants to write data to the console,
it will have to wait for the lower priority task to finish writing
before executing.  These are 128-byte writes.



I should add, this behavior could be optional.  For people who don't 
really care, or want to allocate newtmgr it's own console, they could do 
so.  For people who do care, they could turn on console write locking...


Anyhow, I've said enough: thoughts?  :-)

Sterling

Re: Question on nlip protocol and log messages

[Sterling Hughes]

On 2/26/16 6:53 PM, marko kiiskila wrote:



On Feb 26, 2016, at 4:35 PM, Sterling Hughes <sterl...@apache.org> wrote:



- Allow for mutex protection around console_write(), and block between
multiple tasks calling to the console.  NLIP can handle interleaved
data, between calls to console_write().  (*)

The downside here is that calls to console_write() will block.  So if
you have a higher priority task that wants to write data to the console,
it will have to wait for the lower priority task to finish writing
before executing.  These are 128-byte writes.



I should add, this behavior could be optional.  For people who don't really 
care, or want to allocate newtmgr it's own console, they could do so.  For 
people who do care, they could turn on console write locking...

Anyhow, I've said enough: thoughts?  :-)




Newtmgr protocol was meant to take different data path than
the console (i.e. Bluetooth/IP), and running it over serial was
a bit of stopgap until that’s possible.



Yes, although I think you will want to run newtmgr over console or 
serial port as well.  For example: how do you do firmware upgrade to a 
device without newtmgr?



Given that, I’m not a big fan of adding locking to console.

If the use case is just with simulator, I’d rather just allocate another
serial port. Ptys are cheap.



If it were just SIM, I totally agree.



On the other hand, if the thought is that users will be running this
on real systems, we need a lock here. But in that case there
also needs to be a lockless path to serial port as well, as the system
outputs it’s state in case of assert()/fault, and these cases cannot
wait for lock.



+1

Sterling

Re: [VOTE] Release Apache Mynewt 0.8.0-b1-incubating

[Sterling Hughes]

On 2/24/16 11:45 AM, will sanfilippo wrote:

+1


On Feb 23, 2016, at 5:29 PM, Christopher Collins  wrote:

Hello all,

I am pleased to be calling this vote for the source release of
apache-mynewt-0.8.0-b1-incubating.

Apache Mynewt is a community-driven, permissively licensed open source
initiative for constrained, embedded applications.

This would be the first release of Apache Mynewt; what has changed since
the last release is: literally everything :).

All automated tests in the mynewt test project for this release were
executed with no failures.  Testing was performed using the "sim"
architecture on an OS X 10.10.5 machine.

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

The commits under consideration are as follows:

larva:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva
commit: ba1586a4f2cbe47c25cf4d202fd3f999e47e0843

tadpole:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-tadpole
commit: a9723f015eb42edcd6e14e9b366d35fb7707fde8

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

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

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

[ ] +1 Release this package


+1

Sterling

Go include path / Git Include Path

[Sterling Hughes]

Howdy,

Right now there is a conflict in how newtmgr & newt include libraries using go.

Newtmgr uses:

git-wip-us.apache.org/repos/asf/incubator-mynewt-newt/newtmgr

Whereas Newt uses:

git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt

In order for both of these packages to compile, we're going to need to
choose one layout and stick with it.  Personally, I'm fine with either
-- I think newtmgr's makes more sense, but if there is a good reason
for sticking with Newt's pathes, and I'm ok with that as well.

Thoughts?

Sterling

Re: Proposed changes to sys/stats

[Sterling Hughes]

1. The STATS_SECT_START and STATS_SECT_END macros just define a struct;
they don't create an instance.  Generally, these macros would be used
in a header file so that source files can have access to the struct
definition.

2. The addition of a STATS_SECT_DECL macro.  This macro would be used in
two places:
 * In source files to instantiate a stats struct.
 * In header files to expose an extern declaration of a stats
   instance.

3. As a consequence of the above two points: the names of struct
instances are no longer auto-generated.  The user needs to specify the
exact name.  All macros which derive the instance name from the struct
name are changed: now they just accept the instance name directly.




+1



4. Remove the "s" which prefaces the name of each stat field in a
statistics struct.  By doing this, the STATS_SECT_VAR, STATS_INC, and
STATS_INCN macros can be removed.



-1

I think we want these macros used everywhere: they allow us more 
flexibility to refactor this, and there is a relatively well defined 
access mechanism for stats.


Sterling

Kicking off a release

[Sterling Hughes]

Mynewtites,

It looks like master has stabilized, and we're pretty much done with B1 
bugs:


The remaining issues are here:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20MYNEWT%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20v0_8_0_beta1%20ORDER%20BY%20priority%20DESC

They consist of:

- Adding a download to the downloads page, which contains the release
- Fixing license dependencies

The latter, I think, has been successfully resolved on dev@mynewt and 
general@incubator -- the consensus being that we can go ahead with the 
release, and remove the LGPL dependency in the newt tool after the B1 
release, so long as we add a notice in the release notes and NOTICE file.


SO, I'll defer to the other mentors here, but I believe the process is:

- Add release notes to the mynewt distribution
- Tag the tree with a B1 release tag (mynewt_0_8_0_b1_tag)
- Start a [VOTE] thread to [VOTE] on the Mynewt release (along with the 
given tag)
- Should that [VOTE] go through, that tag can then be built into a 
series of release artifacts:

  - Source tarballs of each repository
  - A build of newt for Mac OS X and Linux

- That can then be posted on the Mynewt website, along with release notes.

Does this sound right?

If so, I'll add release notes, tag, and start the [VOTE] thread.


Thanks,
Sterling

Wiki / Confluence

[Sterling Hughes]

Hey,

I'm starting to take a first stab at things like:

- Release process
- Roadmap

Etc.  It would be useful to have a WIKI to document these (we may end up 
summarizing them on the site, but I think this should live in a Wiki.)


Is there ASF infrastructure to support a Wiki?  Would someone mind 
putting together a ticket for infrastructure, so we can start capturing 
this stuff there?


Thanks,

Sterling

Re: Newt targets as packages

[Sterling Hughes]

- Target specific header files begin to get confusing.  You end up
having to have 100's of different copies of the same header file per
build target.

If you want to specify target specific defines, that's what the CFLAGS
setting is for.  Or, as in the bletiny case below, the project can
decide how many connections to allocate based upon available memory, or
another BSP hint.



I should have prefaced this with "IMHO."  Lots of people do it the way 
Chris proposed.  I'm just not a huge fan, as I start to get angry when I 
grep for a define, and I get tons of results and I'm not really sure 
where its coming from.


Actually, it would be great if there were a part of the newt tool that 
per-target could tell you what the value of a given '#define' would be. 
 That would be freaking magic :-)


Sterling

Re: Newt targets as packages

[Sterling Hughes]

I don't think we ever settled on this.

There were 3 proposals:

#1- Newt targets as packages
#2- Newt targets stored as text in a targets/ directory
#3- Newt targets having target specific header files

I am unreservedly a fan of #2.  I think we should have a targets 
directory, one-file per target, that contains the target definition.


I don't think I like #1 & #3, and this is why:

- Build targets should be cheap & easy to create.  Having to create an 
entire package structure when you want to create a build target seems 
like overkill.


- Target specific header files begin to get confusing.  You end up 
having to have 100's of different copies of the same header file per 
build target.


If you want to specify target specific defines, that's what the CFLAGS 
setting is for.  Or, as in the bletiny case below, the project can 
decide how many connections to allocate based upon available memory, or 
another BSP hint.


Sterling

On 2/12/16 10:09 AM, Christopher Collins wrote:

Regarding compile-time options, I was thinking of cases involving BLE
applications.  Nimble is a complete BLE stack, and some applications may
not want the entire package to be compiled in to the end product.  For
example, some devices are simple peripherals (slaves) that don't need
any of the central (master) functionality.  These targets would need to
define the appropriate nimble macros to "compile out" unneeded
functionality.  Similarly, an application may need to minimize the
amount of statically allocated memory.  If an application/BSP combo
(i.e., target) only has enough RAM for a single concurrent connection,
the NIMBLE_OPT_MAX_CONNECTIONS setting needs to be set to 1.

There are a few solutions to the above problems that work today:
 * Minimize the amount of code in each project, and create a separate
   project for each target.
 * Use identities to configure groups of settings at a time.

The first solution doesn't "feel right" to me; I dislike the idea of
having to create a separate main() function for each configuration.

The second solution works for coarse-grained configuration (e.g.,
central vs. peripheral vs. combined), but it is not ideal for more
precise configuration (setting a specific number of max monnections).

I have an actual use case for this: the bletiny project.  bletiny is a
simple project which provides a shell interface to the nimble
host API.  I want this project to be capable of running on a variety of
different hardware with different amounts of RAM.  BSPs with 16kB RAM
might only support peripheral functionality with a single connection,
while other BSPs can support something more ambitious.  It would be nice
if the same project could be used in both cases.

Chris


On Fri, Feb 12, 2016 at 05:42:15PM +, p...@wrada.com wrote:

I think that is fantastic.  Right now it feels a bit mysterious where the
come from and its a bit awkward to share them.

I was also thinking about target specific options.  Some were compiler
options like debug or optimization that you may want to turn off for
simulation targets etc, but I think that current method would work ok for
these since they are limited.  What kinds of target specific options were
you thinking of? Can you give some examples?


Paul

On 2/12/16, 9:31 AM, "will sanfilippo"  wrote:


+1 sounds great to me.


On Feb 11, 2016, at 11:05 PM, Christopher Collins 
wrote:

Hello all,

It occurs to me that in the newt world, there is one entity that is not
like the others: targets.  Everything else--pacakges, projects, compiler
definitions--all share the same structure: a .yml file and some source
files
enclosed in a directory.  Targets, on the other hand, are tables stored
in a sqlite database.  I was wondering if it would be better if targets
had the same structure as everything else.

I am envisioning a directory called "targets".  Each subdirectory in the
targets directory would contain an individual target definition.  I
think this change would provide several benefits:

1. Targets could be shared and downloaded using the newt package
   manager.

2. Target definitions would be stored as yml files.  This would bestow a
   simple means of reading, modifying, and copying targets, the ability
   to add comments next to target variables, and all the other benefits
   inherent in human-readable configuration files.

3. A target's directory could contain target-specific header files.

The last point is what spurred me to write this email.  I was thinking
about the best way to allow compile-time configuration of packages.
Modifying settings at the project or package level is not precise enough
for some uses.  There are some cases where settings need to be
configured at the target level.  The newt tool allows you to specify
compiler flags for each target (via the "cflags" variable), but this
becomes unwieldy when you need to configure hundreds of settings.

Anyway, just a thought.  Feel free to chime in with 

Re: Kicking off a release

[Sterling Hughes]

On 2/16/16 5:07 PM, Justin Mclean wrote:

Hi,

Who is going to act as release manager?



Good question: I nominate Chris.




- Add release notes to the mynewt distribution
- Tag the tree with a B1 release tag (mynewt_0_8_0_b1_tag)
- Start a [VOTE] thread to [VOTE] on the Mynewt release (along with
the given tag)
- Should that [VOTE] go through, that tag can then be built into a
series of release artifacts


The release artefacts are built first. The  [VOTE] email will have links
to the source tar (and binary if we’re creating them) to vote on.

After the vote here, you then need to put it up for vote on the
incubator general mailing list were only incubator PMC votes are
binding. A few of the mentors are IPMC (myself included) so that should
help.




Nice.  So Chris (or whoever) needs to create all the release artifacts 
(source tarball, binaries, etc.) and tag the tree.  Compose an email to 
dev@ first (with a [VOTE] thread?), and then if that passes, compose a 
similar email to general@, with the note that it has already passed a 
release vote within the podling, correct?



Only after both votes pass can you do this:

- That can then be posted on the Mynewt website, along with release notes.


And send out a release announcemt!

The LICENSE and NOTICE files also need to be updated [1] before a VOTE
can be called.

Also last time I looked 2 or 3 repos still have a few header files and
the like to clean up. It would probably pass an incubator vote in that
state (given there a JIRA to fix it) but best to clean up before release
I think?



I'll run through and make changes today.

Thanks,
Sterling

Re: hal organization and multiple smaller packages

[Sterling Hughes]

Paul -

I think you make a number of good points here, but I'm not sure all of 
them argue for re-organizing the HAL, but perhaps just improving the 
existing structure.


The purpose of the HAL is to abstract MCU peripheral functions, and make 
that portable across various MCU architectures.  This is why the HAL 
APIs are defined in the hw/hal package, but the implementation for the 
HAL lives in the various mcu support packages in hw/mcu (*).


I think it makes sense to group the definition of MCU support functions 
together.  That way, as people use it, and contribute support back -- 
support for a given processor grows in a cohesive fashion.  Now, of course:


- Not all MCUs will implement all HAL interfaces (e.g. DMA v non-DMA chips)
- Not all HAL implementations are going to be complete: if I don't use 
the ADC on a chip, am I going to spend my time developing a MCU support 
package for it?


I think, however, that this can be exposed both:

- At runtime, with HAL introspection APIs
- At package/compile time, using capabilities (MCU packages export more 
fine grained hal capabilities, e.g. hal-adc, hal-adc-outc)


That way people who are searching for MCU support packages, can inspect 
what aspects of the HAL are/aren't implemented (view capabilities.)


I think then, on top of the HAL there can be more complex drivers for 
everything you want to do with it.  As an example, hal-gpio would just 
have on/off, and read state (abstracting peripherals): but you might 
distribute a gpio-led package on top of that, which had common functions 
for controlling LEDs through GPIO (PWM for color, etc.) This driver 
would require that their be a hal-gpio capability present, but it 
wouldn't need to specify the specific support package necessary.


Fundamentally, I think the question comes down to me: where do you want 
the implementation of MCU specific functionality to live.  Ideally MCU 
support is in a single package/set of packages in hw/mcu that is being 
constantly improved for all peripheral interfaces.  The HAL then becomes 
a glue to let all the higher layer drivers operate, without knowing 
about the specifics of the underlying MCU implementation.


Thoughts?

Sterling

(*) hw/hal does take some definitions from the BSP.  I'm more inclined 
to move these out of the HAL, and have the HAL just be MCU support.  But 
that is a discussion for another day.



On 2/18/16 4:32 PM, p...@wrada.com wrote:


Just wanted to pass on some thoughts I had today about the hal ...

I was thinking about how much is in a hal, how it will grow over time and how to tell 
"how complete" a given hal is.  And more importantly how to provide simple 
stuff that does basic HW (like polling GPIO) while allowing advanced features of chips 
that support it.

Let's consider one example: ADC.

For now assume that the customer wants a simple way to poll ADC.  So they go to newt and 
look at possible packages with "*adc*".

The find

Libs/poll_adc
Libs/adc_periodic
Libs/adc_compare
And perhaps some custom ADC libraries that are not hardware agnostic written by 
HW vendors that want to provide the best interfaces to their products (open 
source is great)

Which is my trying to say that there is different functionality that they may 
want from adc and generally folks don't want to learn anything more than they 
have to especially with these frameworky things that are already hard to get 
your head around.

The chose the simple one since they are not ready to do anything fancy and just 
want to see it working.  And add it to their project.yml file.

Now lets consider their Hardware platform they have.  Suppose the customer has 
the following different combinations of hardware

   1.  A board with an MCU with ADC channels built into the MCU
   2.  A board with an MCU with no ADC channels
   3.  A board with an external SPI ADC device (possibly to replace the 
internal ADC that was not accurate enough).

They include libs/poll_adc into their project ...  if it were me I'd want the 
dependency system to say that "unresolved dependency, libs/poll_adc requires a 
driver that implements hw/simple_adc_driver.  The following packages implement 
hw/simple_adc_driver:

  *   samd21/adc
  *   nr52/adc
  *   ..
  *   sim/adc
  *   stub/adc
  *   mcp3008/adc (This is an external SPI ADC)

The customer now knows what is available or what they need to write.  This may 
be an important step.  For example suppose they have both #1 and #3 and have 
internal and external ADC for different purposes (not accurate enough etc).  
How to they select that they are binding the ADC to #3 or #1.  Or do they get 
to?  Do we need to make sure its their choice, but we give them enough guidance 
to make it easy? What if the customer wants both an internal and external ADC 
through our simple API?

They just chose the one for their internal ADC and move on.  Now they build and 
get some unresolved external

Unersolved reference to 

Re: Release dependant on LGPL

[Sterling Hughes]

On 2/19/16 6:15 AM, Bertrand Delacretaz wrote:

On Sun, Feb 14, 2016 at 5:46 AM, Greg Stein  wrote:

...Speaking as an IPMC Member, and a Mynewt Mentor … yes, this is fine with a
disclaimer in the release notes


Except we don't have a standard for release notes, so how about we
require a mention in the DISCLAIMER file that incubating releases are
required to include?

Something like "This release is not fully compliant with Apache
release policy and includes..." in that file.




That would be fine with us. The main point of this release was to 
familiarize ourself with the process, and find out all the warts. We 
have a beta2 planned shortly afterwards, where we will clean up 
everything we found going through beta1 (which seems doable.)


We'd like to go ahead, just so we've put it through the paces prior to 
our next beta, and we have the full list of things we need to improve.


As a quick summary on the license front, we've found:

- We have some Go LGPL dependencies in our build tool that need to ... 
go...  This is a day's worth of work, unfortunately because of where 
they are in the dependency chain.


- (more serious) Some of the chip vendor license headers have a modified 
3-clause BSD license for their driver headers.  They end up being some 
derivant of: 
http://www.st.com/web/en/resource/legal/legal_agreement/license_agreement/ultimate-liberty-v2.txt?sc=software_license_agreement_liberty_v2


"4.	This software, including modifications and/or derivative works of 
this software, must execute solely and exclusively on microcontroller or 
microprocessor devices manufactured by or for STMicroelectronics."


That's obviously not kosher.  We have two potential remedies, which 
we'll need to work through prior to next release:


1- Many of these vendors seem to have the same header files licensed 
many ways, depending on version and phase of the moon.  Sometimes the 
exact same files are available straight up BSD.  We'll move to those 
where possible.


2- For ones that aren't, Newt has a package search and install tool. 
These files are in packages that only need to be included when building 
for that platform (and therefore compliant with the license.)  We can 
break these out and host them on Github, and people can search for and 
install them.We've done this with one of the packages as a test for this 
release: https://github.com/runtimeinc/mynewt_stm32f3


3- We'll work with the chip vendors and ask them to re-license their 
files.  This will be a slower process, but many of them are actually 
excited about Mynewt, and may be receptive.


Thanks,

Sterling

Re: [BLE] Questions about BLE on Apache Mynewt

[Sterling Hughes]

Hi Quang,

No problem, that's exciting!

Documentation on Mynewt is located here: 
http://mynewt.incubator.apache.org/documentation/


It's good that you're working on the Nordic platform, we've spent a lot 
of time supporting that chip.


We are currently in the middle of our first beta -- if you are looking 
to adopt, I would say it's probably best to get started next Monday / 
Tuesday, as we'll be revving the documentation between now and then to 
reflect some of the changes.  I've also attached some preliminary 
instructions on how to use the Nordic chipsets.


If you have any questions or comments while you're trying to get Mynewt 
up & running: don't hesitate to ask the list.  We'll find the feedback 
very useful, and help debug any issues you have.


Best,

Sterling


STEPS:

# 1. Create the "mynewt" directory in your home directory.
[ccollins@ccollins-mac:~]$ mkdir ~/mynewt

# 2. Grab the larva repository from the apache server.
[ccollins@ccollins-mac:~]$ cd ~/mynewt
[ccollins@ccollins-mac:~/mynewt]$ git clone 
https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva

Cloning into 'larva'...
remote: Counting objects: 14729, done.
remote: Compressing objects: 100% (4408/4408), done.
remote: Total 14729 (delta 8765), reused 14556 (delta 8620)
Receiving objects: 100% (14729/14729), 3.83 MiB | 4.22 MiB/s, done.
Resolving deltas: 100% (8765/8765), done.
Checking connectivity... done.
[ccollins@ccollins-mac:~/mynewt]$ cd larva
[ccollins@ccollins-mac:~/mynewt/larva]$

# 3. Create some required newt targets by running the attached
# "create-targets.sh" script (this step assumes the script is in the
# current directory).
[ccollins@ccollins-mac:~/mynewt/larva]$ ./create-targets.sh
Creating target bleprph-nrf51-16kbram
Target bleprph-nrf51-16kbram successfully created!
Target bleprph-nrf51-16kbram successfully set arch to cortex_m0
Target bleprph-nrf51-16kbram successfully set bsp to hw/bsp/nrf51dk
Target bleprph-nrf51-16kbram successfully set compiler to 
arm-none-eabi-m0

Target bleprph-nrf51-16kbram successfully set project to bleprph
Target bleprph-nrf51-16kbram successfully set compiler_def to debug
Target bleprph-nrf51-16kbram successfully set cflags to 
-DNIMBLE_OPT_ROLE_CENTRAL=0 -DNIMBLE_OPT_ROLE_OBSERVER=0 
-DNIMBLE_OPT_GATT_DISC_ALL_DSCS=0 -DNIMBLE_OPT_GATT_READ=0 
-DNIMBLE_OPT_GATT_READ_UUID=0 -DNIMBLE_OPT_GATT_READ_LONG=0 
-DNIMBLE_OPT_GATT_READ_MULT=0 -DNIMBLE_OPT_GATT_WRITE_NO_RSP=0 
-DNIMBLE_OPT_GATT_SIGNED_WRITE=0 -DNIMBLE_OPT_GATT_WRITE=0 
-DNIMBLE_OPT_GATT_WRITE_LONG=0 -DNIMBLE_OPT_GATT_WRITE_RELIABLE=0

Creating target bletiny-nrf51-16kbram
Target bletiny-nrf51-16kbram successfully created!
Target bletiny-nrf51-16kbram successfully set arch to cortex_m0
Target bletiny-nrf51-16kbram successfully set bsp to 
hw/bsp/nrf51dk-16kbram
Target bletiny-nrf51-16kbram successfully set compiler to 
arm-none-eabi-m0

Target bletiny-nrf51-16kbram successfully set project to bletiny
Target bletiny-nrf51-16kbram successfully set compiler_def to debug
Target bletiny-nrf51-16kbram successfully set cflags to 
-DNIMBLE_OPT_ROLE_CENTRAL=0 -DNIMBLE_OPT_ROLE_OBSERVER=0 
-DNIMBLE_OPT_GATT_DISC_ALL_DSCS=0 -DNIMBLE_OPT_GATT_READ=0 
-DNIMBLE_OPT_GATT_READ_UUID=0 -DNIMBLE_OPT_GATT_READ_LONG=0 
-DNIMBLE_OPT_GATT_READ_MULT=0 -DNIMBLE_OPT_GATT_WRITE_NO_RSP=0 
-DNIMBLE_OPT_GATT_SIGNED_WRITE=0 -DNIMBLE_OPT_GATT_WRITE=0 
-DNIMBLE_OPT_GATT_WRITE_LONG=0 -DNIMBLE_OPT_GATT_WRITE_RELIABLE=0

Creating target boot-nrf51-16kbram
Target boot-nrf51-16kbram successfully created!
Target boot-nrf51-16kbram successfully set arch to cortex_m0
Target boot-nrf51-16kbram successfully set bsp to 
hw/bsp/nrf51dk-16kbram
Target boot-nrf51-16kbram successfully set compiler to 
arm-none-eabi-m0

Target boot-nrf51-16kbram successfully set project to boot
Target boot-nrf51-16kbram successfully set compiler_def to 
optimized


# 4. Now you should have four newt targets (bin2img,
# bleprph-nrf51-16kbram, bletiny-nrf51-16kbram, and boot-nrf51-16kbram).
# Make sure they are all there.
[ccollins@ccollins-mac:~/mynewt/larva]$ newt target show
bin2img
arch=sim
bsp=hw/bsp/native
compiler=sim
compiler_def=debug
name=bin2img
project=bin2img
bleprph-nrf51-16kbram
arch=cortex_m0
bsp=hw/bsp/nrf51dk
cflags=-DNIMBLE_OPT_ROLE_CENTRAL=0 
-DNIMBLE_OPT_ROLE_OBSERVER=0 -DNIMBLE_OPT_GATT_DISC_ALL_DSCS=0 
-DNIMBLE_OPT_GATT_READ=0 -DNIMBLE_OPT_GATT_READ_UUID=0 
-DNIMBLE_OPT_GATT_READ_LONG=0 -DNIMBLE_OPT_GATT_READ_MULT=0 
-DNIMBLE_OPT_GATT_WRITE_NO_RSP=0 -DNIMBLE_OPT_GATT_SIGNED_WRITE=0 
-DNIMBLE_OPT_GATT_WRITE=0 

Re: LICENSE and NOTICE contents / headers

[Sterling Hughes]

Hi Justin,

These are both in tadpole and larva.  Are you suggesting moving these 
prior to release?


Also: I've updated tadpole with the latest license changes, so re your 
previous mail, that should be fixed.


newtvm.exe is also removed from the newt distribution.

Sterling

On 2/20/16 9:00 PM, Justin Mclean wrote:

Hi,

Also a few extra LICENSE file sin tadpole?

./hw/bsp/native/LICENSE
./libs/os/LICENSE
./libs/testutil/LICENSE

Thanks,
Justin

Re: hal organization and multiple smaller packages

[Sterling Hughes]

On 2/21/16 8:39 PM, Sterling Hughes wrote:

BTW, I hope I didn't kill discussion on this one. :-)

I think this is an important topic to get right, and I'd like other
people's thoughts here as well.


And I should further add, one issue I'd also like to discuss -- Should 
the HAL abstract away flash implementation?


To me, the HAL is designed to abstract MCU peripheral specific 
functionality, not BSP level functionality.  I wonder if flash shouldn't 
be it's own thing, and not in the HAL, given that its BSP dependent.


Sterling

Re: hal organization and multiple smaller packages

[Sterling Hughes]

BTW, I hope I didn't kill discussion on this one. :-)

I think this is an important topic to get right, and I'd like other 
people's thoughts here as well.


Sterling

On 2/18/16 9:23 PM, Sterling Hughes wrote:

Paul -

I think you make a number of good points here, but I'm not sure all of
them argue for re-organizing the HAL, but perhaps just improving the
existing structure.

The purpose of the HAL is to abstract MCU peripheral functions, and make
that portable across various MCU architectures.  This is why the HAL
APIs are defined in the hw/hal package, but the implementation for the
HAL lives in the various mcu support packages in hw/mcu (*).

I think it makes sense to group the definition of MCU support functions
together.  That way, as people use it, and contribute support back --
support for a given processor grows in a cohesive fashion.  Now, of course:

- Not all MCUs will implement all HAL interfaces (e.g. DMA v non-DMA chips)
- Not all HAL implementations are going to be complete: if I don't use
the ADC on a chip, am I going to spend my time developing a MCU support
package for it?

I think, however, that this can be exposed both:

- At runtime, with HAL introspection APIs
- At package/compile time, using capabilities (MCU packages export more
fine grained hal capabilities, e.g. hal-adc, hal-adc-outc)

That way people who are searching for MCU support packages, can inspect
what aspects of the HAL are/aren't implemented (view capabilities.)

I think then, on top of the HAL there can be more complex drivers for
everything you want to do with it.  As an example, hal-gpio would just
have on/off, and read state (abstracting peripherals): but you might
distribute a gpio-led package on top of that, which had common functions
for controlling LEDs through GPIO (PWM for color, etc.) This driver
would require that their be a hal-gpio capability present, but it
wouldn't need to specify the specific support package necessary.

Fundamentally, I think the question comes down to me: where do you want
the implementation of MCU specific functionality to live.  Ideally MCU
support is in a single package/set of packages in hw/mcu that is being
constantly improved for all peripheral interfaces.  The HAL then becomes
a glue to let all the higher layer drivers operate, without knowing
about the specifics of the underlying MCU implementation.

Thoughts?

Sterling

(*) hw/hal does take some definitions from the BSP.  I'm more inclined
to move these out of the HAL, and have the HAL just be MCU support.  But
that is a discussion for another day.


On 2/18/16 4:32 PM, p...@wrada.com wrote:


Just wanted to pass on some thoughts I had today about the hal ...

I was thinking about how much is in a hal, how it will grow over time
and how to tell "how complete" a given hal is.  And more importantly
how to provide simple stuff that does basic HW (like polling GPIO)
while allowing advanced features of chips that support it.

Let's consider one example: ADC.

For now assume that the customer wants a simple way to poll ADC.  So
they go to newt and look at possible packages with "*adc*".

The find

Libs/poll_adc
Libs/adc_periodic
Libs/adc_compare
And perhaps some custom ADC libraries that are not hardware agnostic
written by HW vendors that want to provide the best interfaces to
their products (open source is great)

Which is my trying to say that there is different functionality that
they may want from adc and generally folks don't want to learn
anything more than they have to especially with these frameworky
things that are already hard to get your head around.

The chose the simple one since they are not ready to do anything fancy
and just want to see it working.  And add it to their project.yml file.

Now lets consider their Hardware platform they have.  Suppose the
customer has the following different combinations of hardware

   1.  A board with an MCU with ADC channels built into the MCU
   2.  A board with an MCU with no ADC channels
   3.  A board with an external SPI ADC device (possibly to replace
the internal ADC that was not accurate enough).

They include libs/poll_adc into their project ...  if it were me I'd
want the dependency system to say that "unresolved dependency,
libs/poll_adc requires a driver that implements hw/simple_adc_driver.
The following packages implement hw/simple_adc_driver:

  *   samd21/adc
  *   nr52/adc
  *   ..
  *   sim/adc
  *   stub/adc
  *   mcp3008/adc (This is an external SPI ADC)

The customer now knows what is available or what they need to write.
This may be an important step.  For example suppose they have both #1
and #3 and have internal and external ADC for different purposes (not
accurate enough etc).  How to they select that they are binding the
ADC to #3 or #1.  Or do they get to?  Do we need to make sure its
their choice, but we give them enough guidance to make it easy? What
if the customer wants both an internal and extern

Re: [jira] [Resolved] (MYNEWT-137) Replace YAML dependency in Newt tool

[Sterling Hughes]

can we submit a pull request to the viper author?

sterling

On 2/29/16 7:21 PM, Christopher Collins (JIRA) wrote:


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

Christopher Collins resolved MYNEWT-137.

 Resolution: Fixed

The solution was to rewrite the parts of yaml.v2 that we need.  This wasn't as 
bad as it sounds because:
 * Most of yaml.v2 is actually MIT-licensed, as it is a direct port from 
the libyaml C library.
 * We only need to decode YAML, not encode.

That said, this naive solution is still troubling.  All libraries which depend 
on yaml.v2 need to be forked and changed so that they import our yaml library 
instead.  In our current code base, viper is the only library which depends on 
yaml.v2, so the maintenance cost isn't horrible.


Replace YAML dependency in Newt tool


 Key: MYNEWT-137
 URL: https://issues.apache.org/jira/browse/MYNEWT-137
 Project: Mynewt
  Issue Type: Improvement
  Components: Newt
Reporter: Sterling Hughes
Assignee: Christopher Collins
Priority: Blocker
 Fix For: v0_8_0_beta2


We need to replace the YAML dependency in the newt tool.  Currently this LGPL 
dependency is causing issues with building and distributing Newt.




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

New Newt & Process for B2

[Sterling Hughes]

Howdy,

I'd like to talk about the process for releasing B2 here, in the context 
of a number of changes that have been made for newt.  I am sending a 
separate email to describe the changes in detail, but wanted to first 
begin to settle on process items.


Newt is our build and package management tool, and after a conversation 
last Friday, we decided to rewrite pretty large parts of it.  The new 
version is in develop now, and it matches up nicely with 
incubator-mynewt-core/develop and incubator-mynewt-blinky/develop.


We have a release coming up, and I think its important to get these 
changes out there, because:


- The longer we have the B1 code out there, the more we have to support 
it.  We're seeing many people are starting to adopt and play around with 
Mynewt, and don't want to have to break their way of working.


- B2 is really way better than B1.  Plus, I have confidence in our 
approach for build and package management for B2.  So while it may need 
to stabilize and improve, the B1 code is a dead-end.


So, in the context of getting B2 out the door, what I'd like to do:

- Agree that the process for release is going to be:

	- Merge origin/develop into origin/master and tag origin/master for 
release.
		- There will be a large number of changes to origin/master prior to 
release.  However, the changes to the os core are small, it's mainly the 
packaging system.


- Vote on the tag of origin/master.

Typically, we would not make (any) changes to origin/master a week prior 
to release, or make a very small number.  However, because of the 
changes to Newt, I don't think this is the right call for this release.


NOTE: We have not made any major changes to the core C libraries that 
people would be building against, just the build & package tool.


Does this work for everyone?

If so, I propose that we get origin/develop ready for release today, and 
then merge to origin/master tomorrow evening (to give people a little 
time to respond to this mail.)   We then send out a mail Saturday 
morning with the release tag for VOTING on the incubator list, and push 
things through the larger incubator process.


I apologize for this process, we had, I think, all planned to have no 
major changes to the source code the week prior to release.  However, I 
really believe this the right decision because the new approach in newt 
is much better, and we don't want to have to change the way people build 
& manage products once we've started to get adoption.  The current B1 
release is therefore something we'd want to get people off of as quickly 
as possible.


Alright, description of newt is my next mail. :-)

Thanks,
Sterling

Re: New "Newt"

[Sterling Hughes]

On 3/14/16 12:21 PM, ray suorsa wrote:

On Mar 14, 2016, at 11:49 AM, marko kiiskila  wrote:



On Mar 11, 2016, at 6:28 PM, Christopher Collins  wrote:

On Sat, Mar 12, 2016 at 10:31:12AM +1100, Justin Mclean wrote:

download Download built target to board


Would install rather than download be better? download to me means download 
something to your computer not upload to the target device.


I agree that "download" might not be the best name for this command.
There is already a command called "install", though.  Perhaps the
command should be renamed to "upload"?



I’m not a big fan of “upload”; that feels like sending something out to 
Internet.
I’d be ok with “load”, or maybe “program”.

How about ‘load’


‘load’ makes sense to me.



+1.  I'm not touching the other connotations here, load makes sense.

sterling

Re: the

[Sterling Hughes]

Hi Nges,

Have you taken a look at:

http://mynewt.apache.org/os/modules/testutil/testutil/

This should give you a fair amount of documentation on using the 
testutil library.


If you have any further / specific questions, feel free to ask on list 
or on IRC!


Cheers,
Sterling

On 3/15/16 9:23 AM, Nges B wrote:

ok thanks all,
I got all of the above ,
I was asking for something like a documentation explaining the
functionalities of the functions and variables. since the code is not
really commented.

But am still trying to understand the functions knowing that no such
documentation exist.



On 3/15/16, Sterling Hughes <sterl...@apache.org> wrote:

Hi Nges,

On 3/15/16 5:12 AM, Nges B wrote:

I have gone through the unit test documentation and have all the test
and a perfact understanding of how it happens ,
I will need to to know if there is any documentation on the header
file e ?


When you include a library in your package dependencies (e.g.
libs/testutil), you automatically get the header files for that package.

$ tree -L 3 libs/testutil/
libs/testutil/
├── design.txt
├── include
│   └── testutil
│   └── testutil.h
├── pkg.yml
└── src
  ├── arch
  │   ├── cortex_m4
  │   └── sim
  ├── case.c
  ├── suite.c
  ├── testutil.c
  └── testutil_priv.h

6 directories, 7 files
$

Here you see, you will get -I libs/testutil/include in your path, which
will give you access to:

#include 


if any how can I access it?? I will like to better understand this
header.
Thanks in advance



Hope this helps.

Cheers,
Sterling

Re: [VOTE] Release Apache Mynewt 0.8.0-incubating-b2

[Sterling Hughes]

On 3/15/16 10:56 PM, Christopher Collins wrote:

On Wed, Mar 16, 2016 at 03:41:27PM +1100, Justin Mclean wrote:

Hi,

Sorry -1 binding as:

[...]

Yikes!  Thanks for the thorough review, Justin.


- Contains source code (hashicorp) that is MPL licensed [2] this is not allowed 
in a source release.


Darn, I failed to notice that the MPL is only valid in binary (not
source) releases.  I am actually a bit confused by this; I was
under the impression that a binary releas must not contain anything
that is not included in the corresponding source release.  If that is
true, then when is a "binary only" license applicable?

I think we can resolve the rest of the issues fairly easily.  The MPL
issue might pose a bit of a challenge.  In the meantime, I will cancel
the vote.


My understanding was - MPL binaries can be linked in to form the final 
binary (and presumably included alongside the source in the 
distribution), but their source must not be included, is how I read it. 
 I think in certain cases MPL source is allowed, and this code might 
even fall under those conditions (we're not modifying it, relatively few 
exposed APIs).  However, reviewing what we've included, it looks 
relatively small and easy to engineer out.  It is some log filtering 
code, and an unused configuration format that was supported by viper.


Sterling

Re: [VOTE] Release Apache Mynewt 0.8.0-incubating-b2

[Sterling Hughes]

I'll leave the license stuff for Chris to address, it all seems 
reasonable to me.  I was holding on my +1 for that, this time btw :=)


It looks like we'll need to remove the hashicorp stuff.  bummer. 
luckily it looks easy enough to strip out, unlike the yaml stuff which 
was a pain.


I wanted to address the installation from source.  Have you looked at 
the INSTALLING.md?  That document should work, but as you point, is not 
compiling and installing from source tarball, but I wanted to double 
check you didn't have an error with this.


Regarding source tarball, I agree we need installation instructions for 
that: I believe you need to do a godeps restore if you want to compile 
from source tarball -- Chris did this portion, so I'll let him chime in. 
 But this really should just be updating the README.


Sterling


For Mynewt if I copy the source release to $GOPATH/src/mynewt.apache.org/ and 
try and compile I get this:
Fetching https://mynewt.apache.org/newt/newt/cli?go-get=1
ignoring https fetch with status code 404
Fetching http://mynewt.apache.org/newt/newt/cli?go-get=1
Parsing meta tags from http://mynewt.apache.org/newt/newt/cli?go-get=1 (status 
code 404)
import "mynewt.apache.org/newt/newt/cli": parse 
http://mynewt.apache.org/newt/newt/cli?go-get=1: no go-import meta tags
package mynewt.apache.org/newt/newt/cli: unrecognized import path 
"mynewt.apache.org/newt/newt/cli"
Fetching https://mynewt.apache.org/newt/util?go-get=1
ignoring https fetch with status code 404
Fetching http://mynewt.apache.org/newt/util?go-get=1
Parsing meta tags from http://mynewt.apache.org/newt/util?go-get=1 (status code 
404)
import "mynewt.apache.org/newt/util": parse 
http://mynewt.apache.org/newt/util?go-get=1: no go-import meta tags
package mynewt.apache.org/newt/util: unrecognized import path 
"mynewt.apache.org/newt/util"

Thanks,
Justin

1. hw/mcu/stm/stm32f4xx/include/mcu/*
2. http://www.apache.org/legal/resolved.html#category-b

C++ compatibility

[Sterling Hughes]

Hi,

I recently talked with a user of Mynewt, and they were trying to get our 
system header files into a C++ project.


I'm wondering if folks on the list know a better way of doing this, than 
just manually going to every header file and adding:


#ifdef __cplusplus
extern "C" {
#endif

#ifdef __cplusplus
}
#endif

If not, I guess we should probably go ahead and do that.

Sterling

Re: [VOTE] Release Apache Mynewt 0.8.0-b2-incubating-rc3

[Sterling Hughes]

+1 binding 

It's ready to go!

> On Mar 20, 2016, at 10:00 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> +1 binding
> 
> I checked (in all artefacts):
> - names contain incubtating
> - signatures good
> - DISCLAIMER exits
> - LICENSE and NOTICE good
> - No unexpected binary files
> - Source files have apache headers
> - Could compile from source (with some issues)
> 
> In newt I ran into a couple of minor issues:
> - repository.yml is missing an Apache header
> - when running build.sh realpath doesn’t exist in OS X. To solve this I brew 
> install coreutils and used grealpath instead.
> - build.sh also failed with an earlier version of go because of this:
>go version | cut -d ' ' -f 3
>go1.4.2
> (solved by updating go)
> - would be nice for the build.sh to tell you a little of what was going on 
> when building
> 
> Thanks,
> Justin

Re: more ADC hal discussion

[Sterling Hughes]

Hey Paul,

I read through the APIs, I think they look good.  I made a few comments,
entirely coding standards related.

There are a few other things I'd like to understand/discuss, which I'll
post to dev@:

- Can you post a description of how pins are mapped across MCU, BSP and
Application?  I think I followed it, but want to make sure we have a
record.

- Should system device descriptor be preprocessor directives rather than
an enum.  Would there be a case where you'd want to do:

#ifdef SYSTEM_DEV_ADC5
/* do X */
#else
/* do Y */
#endif

- hal_adc_get_reference_voltage_mvolts i feel could be shortend to
hal_adc_refv() or hal_adc_refmv().  Shouldn't this just take a resolution.

- hal_adc_val_convert_to_mvolts(), should this just be hal_adc_convert()
and take a resolution.

Cheers,
Sterling

On 3/25/16 4:52 PM, Paul Dietrich wrote:
> This new implementation is posted as
> 
> https://github.com/apache/incubator-mynewt-core/pull/25
> 
> Take a look and let me know what you think.  Without negative feedback,
> I’ll commit on Monday/Tuesday
> 
> Paul
> 
> On 3/25/16, 2:58 PM, "Paul Dietrich"  wrote:
> 
>> Just updating the group with my plan
>>
>> Folks commented offline that they didn¹t like that the mbed hal doesn¹t
>> allow multiple kinds of devices with the same HAL API at the same time.
>>
>> But they liked the pin mapping and init function that tied it to a pin.
>>
>> So the new API will combine the best of hal_adc3 and hal_adc2.  I¹ll
>> hopefully post the pull request by the COB or during the weekend.
>>
>> One NOTE.  The memory (RAM) issues of hal_adc2 will be addressed by
>> getting the device initializer from the BSP.  So the BSP may malloc memory
>> for these to be efficient.
>>
>>
>>
>>
>>>
>>
>>
> 
> 

Fwd: [1/3] incubator-mynewt-core git commit: Add read supported commands and read local supported features commands

[Sterling Hughes]

Hi Will,

I think some folks were looking for these features, should they try develop 
branch to test them out?  

Cheers,
Sterling 


Begin forwarded message:

> From: w...@apache.org
> Date: March 22, 2016 at 11:13:29 PM PDT
> To: comm...@mynewt.incubator.apache.org
> Subject: [1/3] incubator-mynewt-core git commit: Add read supported commands 
> and read local supported features commands
> Reply-To: dev@mynewt.incubator.apache.org
> 
> Repository: incubator-mynewt-core
> Updated Branches:
>  refs/heads/develop e233384b4 -> 8a7eb7d48
> 
> 
> Add read supported commands and read local supported features commands
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-core/repo
> Commit: 
> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-core/commit/8a7eb7d4
> Tree: 
> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-core/tree/8a7eb7d4
> Diff: 
> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-core/diff/8a7eb7d4
> 
> Branch: refs/heads/develop
> Commit: 8a7eb7d4817d935feb8cf8492685d9251a7651fd
> Parents: 3dc5a47
> Author: wes3 
> Authored: Tue Mar 22 23:12:38 2016 -0700
> Committer: wes3 
> Committed: Tue Mar 22 23:12:43 2016 -0700
> 
> --
> apps/bletest/src/main.c |  10 +
> .../controller/include/controller/ble_ll_hci.h  |   4 +
> net/nimble/controller/src/ble_ll_hci.c  |  49 +
> net/nimble/controller/src/ble_ll_supp_cmd.c | 197 +++
> net/nimble/host/include/host/host_hci.h |   2 +
> net/nimble/host/src/host_dbg.c  |  83 +---
> net/nimble/host/src/host_hci_cmd.c  |  20 ++
> net/nimble/include/nimble/hci_common.h  | 101 +-
> 8 files changed, 388 insertions(+), 78 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-core/blob/8a7eb7d4/apps/bletest/src/main.c
> --
> diff --git a/apps/bletest/src/main.c b/apps/bletest/src/main.c
> index 8b62c77..0863bf4 100755
> --- a/apps/bletest/src/main.c
> +++ b/apps/bletest/src/main.c
> @@ -792,6 +792,16 @@ bletest_task_handler(void *arg)
> assert(rc == 0);
> host_hci_outstanding_opcode = 0;
> 
> +/* Read local features */
> +rc = host_hci_cmd_rd_local_feat();
> +assert(rc == 0);
> +host_hci_outstanding_opcode = 0;
> +
> +/* Read local commands */
> +rc = host_hci_cmd_rd_local_cmd();
> +assert(rc == 0);
> +host_hci_outstanding_opcode = 0;
> +
> /* Read version */
> rc = host_hci_cmd_rd_local_version();
> assert(rc == 0);
> 
> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-core/blob/8a7eb7d4/net/nimble/controller/include/controller/ble_ll_hci.h
> --
> diff --git a/net/nimble/controller/include/controller/ble_ll_hci.h 
> b/net/nimble/controller/include/controller/ble_ll_hci.h
> index 3e1558f..0f80b54 100644
> --- a/net/nimble/controller/include/controller/ble_ll_hci.h
> +++ b/net/nimble/controller/include/controller/ble_ll_hci.h
> @@ -20,6 +20,10 @@
> #ifndef H_BLE_LL_HCI_
> #define H_BLE_LL_HCI_
> 
> +/* For supported commands */
> +#define BLE_LL_SUPP_CMD_LEN (36)
> +extern const uint8_t g_ble_ll_supp_cmds[BLE_LL_SUPP_CMD_LEN];
> +
> /* 
>  * This determines the number of outstanding commands allowed from the
>  * host to the controller.
> 
> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-core/blob/8a7eb7d4/net/nimble/controller/src/ble_ll_hci.c
> --
> diff --git a/net/nimble/controller/src/ble_ll_hci.c 
> b/net/nimble/controller/src/ble_ll_hci.c
> index 7ac07db..e726fd3 100644
> --- a/net/nimble/controller/src/ble_ll_hci.c
> +++ b/net/nimble/controller/src/ble_ll_hci.c
> @@ -123,6 +123,45 @@ ble_ll_hci_rd_local_version(uint8_t *rspbuf, uint8_t 
> *rsplen)
> }
> 
> /**
> + * Reade local supported features
> + * 
> + * @param rspbuf 
> + * @param rsplen 
> + * 
> + * @return int 
> + */
> +static int
> +ble_ll_hci_rd_local_supp_feat(uint8_t *rspbuf, uint8_t *rsplen)
> +{
> +/* 
> + * The only two bits we set here currently are:
> + *  BR/EDR not supported(bit 5)
> + *  LE supported (controller)   (bit 6)
> + */ 
> +memset(rspbuf, 0, BLE_HCI_RD_LOC_SUPP_FEAT_RSPLEN);
> +rspbuf[4] = 0x60;
> +*rsplen = BLE_HCI_RD_LOC_SUPP_FEAT_RSPLEN;
> +return BLE_ERR_SUCCESS;
> +}
> +
> +/**
> + * Read local supported commands
> + * 
> + * @param rspbuf 
> + * @param rsplen 
> + * 
> + * @return int 
> + */
> +static int
> +ble_ll_hci_rd_local_supp_cmd(uint8_t *rspbuf, uint8_t *rsplen)
> +{
> +memset(rspbuf, 0, BLE_HCI_RD_LOC_SUPP_CMD_RSPLEN);
> +memcpy(rspbuf, g_ble_ll_supp_cmds, sizeof(g_ble_ll_supp_cmds));
> +

Re: renaming apache-mynewt-larva to apache-mynewt-os

[Sterling Hughes]

:)

Hey all -

I wanted to get a few more opinions on this.  We're going to need to 
change some repositories around on the newt/newtmgr side (Chris/Todd, 
can you send a summary to the list?)


I'd like to get this all done at once.  I don't think we need a formal 
vote on this one, but just lazy consensus.  My suggestion is that Chris 
send a summary of the go changes, and we leave this open till Sunday. 
If anyone has objections before then, we can stop & vote.


Also, we have our last few features/changes coming in this week. So, we 
should uncharacteristically have a few days to poke around at the 
release prior to releasing B2.


Sterling


On 3/3/16 4:09 AM, Jim Jagielski wrote:

Maintaining the precedent also becomes more painful as
things move forward :)


On Mar 2, 2016, at 6:28 PM, Sterling Hughes <sterl...@apache.org> wrote:

Howdy,

Awhile ago we decided to be cute about naming things: eggs, eggshells, 
clutches, etc.  One holdover from this was larva: our main package repository, 
which includes the OS and most of the packages.

While its painful to rename the git repo: it's only going to get more painful 
as we move forward.  Do we think it makes sense to make it clearer, and rename 
this to apache-mynewt-os or apache-mynewt-main?

Sterling

Re: renaming apache-mynewt-larva to apache-mynewt-os

[Sterling Hughes]

oh, and please specify your preferred option:

 [  ] apache-mynewt-mynewt
 [  ] apache-mynewt-os
 [  ] apache-mynewt-core
 [  ] apache-mynewt-main

Mine is apache-mynewt-mynewt, since this really is the "mynewt" portion 
of the mynewt project.


For efficiencies sake, unless noted otherwise, by +1 you are saying "I 
am fine with all of these options", and then expressing a preference for 
a particular one.  If you feel strongly about any of these, please call 
it out.


Sterling

On 3/3/16 5:38 PM, will sanfilippo wrote:

+1



On Mar 3, 2016, at 4:24 PM, marko kiiskila <ma...@runtime.io> wrote:

+1 for the rename. Sooner the better if we’re going to go ahead with this one.


On Mar 3, 2016, at 3:50 PM, Sterling Hughes <sterl...@apache.org> wrote:

:)

Hey all -

I wanted to get a few more opinions on this.  We're going to need to change 
some repositories around on the newt/newtmgr side (Chris/Todd, can you send a 
summary to the list?)

I'd like to get this all done at once.  I don't think we need a formal vote on this 
one, but just lazy consensus.  My suggestion is that Chris send a summary of the go 
changes, and we leave this open till Sunday. If anyone has objections before then, 
we can stop & vote.

Also, we have our last few features/changes coming in this week. So, we should 
uncharacteristically have a few days to poke around at the release prior to 
releasing B2.

Sterling


On 3/3/16 4:09 AM, Jim Jagielski wrote:

Maintaining the precedent also becomes more painful as
things move forward :)


On Mar 2, 2016, at 6:28 PM, Sterling Hughes <sterl...@apache.org> wrote:

Howdy,

Awhile ago we decided to be cute about naming things: eggs, eggshells, 
clutches, etc.  One holdover from this was larva: our main package repository, 
which includes the OS and most of the packages.

While its painful to rename the git repo: it's only going to get more painful 
as we move forward.  Do we think it makes sense to make it clearer, and rename 
this to apache-mynewt-os or apache-mynewt-main?

Sterling

Re: the fs/nffs

[Sterling Hughes]

Hi Nges,

On 3/3/16 1:49 PM, Nges B wrote:

Hello,
I downloaded the the newt binary and placed it inside my lerva directory.
Now I have created my_app .
also ran the command
$ ./newt pkg search fs
and got the following output.

Installed package project/ffs2native@
Installed package fs/nffs@0.8.0
Installed package fs/fs@

I now  proceed to run the following command
 $ ./newt pkg install fs/nffs


In which directory did you run newt package install?  You would need to 
run it in the my_app directory in order to have it work.


When you do that, remember to make sure to add larva as a remote package 
list for the installation:


$ cd my_app
$ newt app add-pkg-list larva 
https://github.com/apache/incubator-mynewt-larva
Downloading pkg-list.yml from 
https://github.com/apache/incubator-mynewt-larva/master... ok!

Verifying pkg-list.yml format...
 ok!
Package list larva successfully installed to application.
$
$ newt pkg search fs
Package list larva has package project/ffs2native@0.0.0
Package list larva has package fs/nffs@0.8.0
Package list larva has package fs/fs@0.0.0

Then you can use newt package install.  You'll also want to install the 
fs/fs package, which provides an abstraction of filesystem access 
routines for nffs, which is a specific implementation of the file system.


Cheers,
Sterling

Re: Introduction and first contribution

[Sterling Hughes]

Welcome Neel!

On 3/3/16 12:19 PM, Neel Natu wrote:

Hi,

My name is Neel Natu and I recently started hacking on Apache Mynewt. I
have been lurking on the dev list, digesting the documentation, making
simple changes to the OS etc and its been a pleasant experience thus far.

My first contribution is adding wallclock time support to Mynewt:
https://github.com/apache/incubator-mynewt-larva/pull/8



Looks great, I see that you & Will are already discussing it.

Cheers,
Sterling

Re: Tutorial topics for Apache Mynewt

[Sterling Hughes]

On 3/1/16 7:03 PM, Jules Damji wrote:


I wonder having a tutorial or user guide for the newt will help. What we have today 
for  http://mynewt.apache.org/newt/newt_mac/ 
 is only how to build it (on platform 
of your choice) not how to use its extensive commands and subcommands.

Noted that in doing Blinky projects you get a flavor or taste of its range and 
scope, but having a user guide, in addition to reference manual, does help the 
developer whose primary interface to build, package, debug, and test Mynewt OS 
apps is using newt.

Just thinking out loud….


I think that's a great idea -- how about:

- Creating a new application and project with newt
- How to create a custom package repository and redistribute packages

... others?

Sterling

Re: trivial mbuf api thoughts: os_mbuf_free() and os_mbuf_free_chain()

[Sterling Hughes]

On 3/2/16 11:45 AM, will sanfilippo wrote:

I was hoping that the other mbuf API exposed would be enough for users and they 
would never need to call os_mbuf_free. I also think that when you unlink 
something from a list, setting its next pointer to NULL is just good practice.

I was just trying to avoid the myriad bugs I have seen in the past by having 
both of these api exposed. But I am fine if folks want to keep it.



I think we want both functions, people who work with mbufs (me!) are 
very used to m_free() and m_freem().  I was debating whether we should 
call free_chain(), freem() instead, but decided free_chain() was 
clearer.  I would be fine if people thought I was wrong, and wanted to 
rename it to freem().


Sterling

Re: Interested inYour Gsoc Project Project

[Sterling Hughes]

Hi Nges,

Thanks for your interest.  Can you comment on the GSoC tickets within 
the ASF JIRA?


I think it would be great if you came on and helped us with the 
regression testing: we're going to be doing a ton of work on that this 
summer, and would love the help.


Cheers,

Sterling

On 3/2/16 1:41 PM, Nges B wrote:

Please I am also interested in the" GATT based BLE profiles, Services,
and Protocols"
will also like to have some directives on this project.
I have taken courses on Computer Networks and Protocols, Computer
Architectures and Operating Systems . I know my knowledge from the
above mentioned courses and the research I am already doing on this
projects coupling with my C,C++ and Web programming skill is going to
help me through with this organization.

Re: Analysis of our first release process

[Sterling Hughes]

On 3/1/16 4:02 PM, Justin Mclean wrote:

Hi,

Great summary!


0.8.0-b1 is exceptional in that it is our first release.  In subsequent
releases we will want to specify what has been added or fixed since the
last release, as well as highlight known issues.


JFYI this is usually done in a separate file call RELEASE_NOTES or similar. For 
example see [1] but there no prescribed way of doing this it’s up.



yes.  I think next release has to spend quite a bit of time on this 
file, given the early state of OS releases, we need to be super clear 
with people about where we are.



(4) Fix our release naming procedure.


Again up to the PMC how they name releases, other than having the project name, 
‘incubating’ and (optionally) apache. “rc" (for release candidate) is usually used 
rather than "b” tends to be typical but again totally up to the PMC. That those 
names seem fine to me.

Having the release process documented would be a good idea so that other 
committers can make a release if they want.



+1.  I think we'll need to document two things on the Mynewt wiki, 
branching strategy and release process.


1- We should document the current release process that we used, along 
with thoughts on the improvements


2- I'll work on documenting our branching strategy.

I think there are a number of things we'll want to discuss re [1], 
including:


- How do we manage non-ASF compatible packages.  Do they get distributed 
on Github, and does the ASF repository point to these external packages.


What type of warnings do we want to provide in the Newt tool for non-ASF 
compatible licenses.


- Do we want to have a list of these 3rd party package repositories in 
the official ASF documentation?


- How do we provide binary and source distributions of the Newt tool. 
My instinct is that close to 99% of our users will take the newt binary 
as opposed to source, so we need to make this easy, while still 
following the ASF philosphy of source first releases.


- How do we want to allow people to access the ASF package repository 
with releases of newt.  For example, by default should a newt release 
point to a specific tag on the incubator-mynewt-larva package 
repository?  Should we allow people to chose different versions based on 
a tag / branch strategy here?


- How do we facilitate upgrade of packages when migrating to a new release.

Chris, if you take a first pass at this with what we've done for this 
release, I can take a second pass, and then let's send around to the 
list for discussion?


Cheers,
Sterling

Re: installing the Newt

[Sterling Hughes]

When pointed at the apache server, on the other hand, "go get" seems to
require the ".git" suffix.  An I mentioned earlier, this results in the
creation of a directory that also has the ".git" suffix.

The problem is: the behavior of "git clone" is in conflict with the
behavior of "go get", at least with regards to the apache git server.
At one point the installation documentation was accurate, but it seems
we have since opted for git-friendliness rather than
go-get-friendliness.

We will need to find a simpler workaround.  In the meantime, we should
at least update the documentation.  Also, soon newt binaries will be
available for download which help to alleviate problems with go.



Weren't Todd & Aditi making "mynewt.apache.org" a valid import path, 
that would point to the proper Apache git repository?   I thought this 
would solve that problem?


Sterling

Master newt does not build released software

[Sterling Hughes]

Hey,

Try:

$ newt target show
targets/arduino_boot
app=@apache-mynewt-core/apps/boot
bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
build_profile=optimized
features=arduino_zero_pro
targets/my_blinky_sim
app=apps/blinky
bsp=@apache-mynewt-core/hw/bsp/native
build_profile=debug
$ newt build arduino_boot
Error: bsp package (hw/bsp/arduino_zero) is not of type bsp; type is: lib
$

I understand that we introduced package types into the new release. 
What I'm not sure of is why we've broken compatibility here?


Yes, we're beta, and compatibility breaks are allowed, but:

A- We should call them out on dev@ _PRIOR_ to breaking compatibility, so 
things like the docs can be changed.


B- In this case, was a compatibility break really necessary?  Couldn't 
we have just accepted the package type if it was lib-- at least for a 
couple of releases?


Sterling

Re: Master newt does not build released software

[Sterling Hughes]

Hey,

On 4/2/16 12:37 PM, Christopher Collins wrote:

I agree that that is a compatibility break, but that change was made at
the same time as a host of other backwards-incompatible changes
(0.8.0-b2).  I think this particular problem is a bit more complicated,
so strap yourself in for some mind-numbing post-mortem analysis.

The root of this issue is that the arduino repository.yml file
incorrectly pointed to the develop branch rather than an appropriate tag
on the master branch.  Under these conditions, everything worked for a
while, because the arduino bsp's pkg.yml file on the develop branch does
specify the correct package type ("bsp").  Eventually, a change was made
to the arduino develop branch which was incompatible with the core
master branch [*], which is not surprising.  This incompatible change
exposed the bug in the arduino repository.yml file.  As a consequence,
the arduino repository.yml file was modified to point to the master
branch.  The mistake here was in assuming the repository.yml change
would be sufficient for fixing the arduino build issues.



Yes, I was bitten by this the other day.  Which is why I created a tag 
to switch to 0-dev.



In my opinion, temporarily removing the package type restrictions is not
the right thing to do here.  We would need to re-release newt for that
fix to have any effect.  Instead, I believe we should create a new tag
on the arduino repo with the pkg.yml fix.  I can make this change and
ensure arduino apps build properly.  However, I don't have an arduino
with me, so I can't actually test image upload or debug.



I'll test once you make the fix.  If you can get it to compile, I'll 
make sure it loads on the board.


Sterling

Re: more ADC hal discussion

[Sterling Hughes]

On 3/28/16 9:44 AM, p...@wrada.com wrote:
> Thanks for the reviews.
> 
> 1) regarding names.  I can shorten.  I really like having the units in the
> names, but can shorted to
> 
> hal_adc_refmv();
> hal_adc_bits();

OK.

I'm fine if we chose milivolts as our primary unit.  But if we believe
MV will always be sufficient, why include it in the name?  If we don't
think it will always be sufficient, we should have a generic call, i.e.
I think:

rc = hal_adc_ref(HAL_ADC_MV, );

is equally clear, and saves multiple functions for multiple unit types.

> 
> As far as convert.  To convert from adc output to molts requires the
> resolution and the reference voltage.  I agree though that
> This should be a helper and not a driver Api.  I’ll create a function
> 
> hal_adc_util_to_mv(int val, int ref, int res);
> 
>

Why not just hal_adc_convert (or convertmv), and don't make it a driver
function?

> As far as macros versus enums, I think either can do
> 
> Enum val {
> #ifdef SYSTEM_DEV_ENABLED_ADCS
>   SYSID_ADC_TEMP,
>   SYSID_ADC_VOLTAGE,
> 
> #endif
> ...
> };
> 
> I personally like enums because there is warnings when case statements
> don’t address them and there are not as many compile time errors.
> 

It looks to me like what you're proposing above is to have two sets of
defines.  Whereas if you made those '#defines' you'd have one set.

Anyhow, I don't feel too strongly on this one.  This definitely fits the
definition of an enum, so I can see the logic.

Sterling

First draft of Coding standards in develop branch

[Sterling Hughes]

Hi,

As we start to bring on new contributors, and operate as a project, its 
increasingly important that we document and agree upon coding standards. 
 I think we've done a good job of maintaining this consistency 
informally, but, now we need to vote and agree on project standards.


I've taken a first stab at this and committed it to the develop branch, 
folks can see it here:


https://github.com/apache/incubator-mynewt-core/blob/develop/CODING_STANDARDS.md

I think next steps are:

- If you have formatting fixes, or clarifications that don't change the 
contents, just go ahead and edit the document.


- If you disagree with something in the document, or think it should be 
changed in some way, respond back to this thread.


- If you have additions or rules that you don't think were captured, 
respond back to this thread, along with the proposed text.  If nobody 
objects, I'll just fold them into whatever other revisions we decide to 
make.


After we give this a round of discussion, I'll capture all the feedback 
and do a rev of the document.  If nobody has any issues with that rev, 
we can vote to officially adopt these coding standards.  I personally 
think this should be an up or down vote.


Well - OK, let the conversations begin :-)

Sterling

Re: How do you get newt to compile asm source in app folders?

[Sterling Hughes]

Hi Wayne,

On 4/23/16 1:55 PM, Wayne Keenan wrote:

Cool, although I'm sticking to 'latest' for the moment as I've gotten
carried away into being right in the middle of something...

Basically, I have a tiny reptilian hissing out 'Hello World!' to the
Newt UART console on the nrf52 just after Nimble's BLE advertising starts.
It just a very early hatchling/POC, but at some point I'd like to make
the jump from building a standalone/isolated Newt app to being able to
provide a Newt library (1),  and then further down the road perhaps
being able to provide another scripting language to sit alongside LAU in
newt (2).



cool!


Any pointers for the journey down that path would be greatly received.



re [1]: every project can be redistributed as a repository.  In order 
for newt to download a project, and install it, you need a 
repository.yml file in the master git branch.  The repository contains 
both the library, and your applications, so you can test your library 
and release it.  A good example of this is the Arduino Zero support that 
Runtime distributes separately from Mynewt:


https://github.com/runtimeinc/mynewt_arduino_zero/tree/develop

If you look at the develop branch here, you'll see there is a program 
arduino_test, which is a useful little shell app that allows you to 
set/get I/O on the Arduino Zero boards.


Somebody can either directly git clone this as a project, and compile 
the arduino test application-- or, they can include it remotely as a 
library by placing the following in their project.yml:


repository.mynewt_arduino_zero:
type: github
vers: 0-latest
user: runtimeinc
repo: mynewt_arduino_zero

The way newt resolves that, is it goes to the master branch of 
mynewt_arduino_zero, and pulls the repository.yml file: 
https://github.com/runtimeinc/mynewt_arduino_zero/blob/master/repository.yml


It then says, "oh, you want 0-latest, that resolves to a specific 
version 0.0.0, which resolves to a branch: 
mynewt_arduino_zero_0_0_0_tag."  If you wanted 0-dev it would resolve to 
0.0.1, and then develop.


Once you add this repository.yml file to your project, you can then 
redistribute it as newt.


In the build system, you can point to the individual packages within the 
repository to stitch together the dependencies.  You do that with a 
repository descriptor, so, for example with the project.yml above, you 
would reference the arduino zero bsp in a target by using:


$ newt target set my_target bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero

There are more tutorials on this here:

- http://mynewt.apache.org/os/tutorials/add_repos/
- http://mynewt.apache.org/os/tutorials/create_repo/

re [2]: I'm not sure I can help much, except to say: Awesome!  I'm a big 
fan of both Espruino and Micropython.  I personally like Javascript for 
these environments a bit more (smaller standard library makes it look 
more like the real thing), but its really great what both of those guys 
are doing, and I think hooking in a scripting language to Mynewt is 
excellent.


I'd start with getting the kernel (libs/os) mapped, and leaving their 
HALs intact.  Eventually it would be cool to see those engines broken 
out, so that they could be mapped into our HAL as well.  But that's 
kinda all I've got -- not sure if others have opinions here.



In the meantime there's quite a few HAL and BLE bits to wire/wrap up to
keep me busy.



Yeah. :-)

Sterling

Re: [VOTE] Release Apache Mynewt 0.8.0-incubating-rc1

[Sterling Hughes]

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


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

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



+1 - release this package.

Sterling

Re: [DISCUSS] Release Apache Mynewt 0.8.0-incubating-rc1

[Sterling Hughes]

Hi Justin,

I don't see the link?  B2 (the link I see) was voted on, and released. 
This is v0.8, full release...


Sterling

On 4/30/16 3:47 PM, Justin Mclean wrote:

Hi,

Looks like there’s a up public link up to build that has not been voted on [1]? 
If so this is against Apache policy and the second time this has happened. What 
can we do to to fix this/avoid this happening again in the future?

Justin

1. http://mynewt.apache.org/download/

Re: [DISCUSS] Release Apache Mynewt 0.8.0-incubating-rc1

[Sterling Hughes]

On 4/30/16 5:09 PM, Justin Mclean wrote:

Hi,


I don't see the link?  B2 (the link I see) was voted on, and released. This is 
v0.8, full release...


Sorry my mistake. I had expect the version number to not be the same as the 
previous release. Generally the version after 0.8.0 would be 0.8.1 (or similar).



yeah :)  we called v0.8-b2 actually v0.7.9 in the repository.yml file.

after v0.8 we should just start bumping up the minor until v1.0 -- it 
really made no sense to have a v0.8-beta designation, as anything prior 
to 1.0 is by definition beta.


sterling

Re: [DISCUSS] Release Apache Mynewt 0.8.0-incubating-rc1

[Sterling Hughes]

mynewt-core is a project, just like any project you create with newt new.

so, just git clone mynewt-core (or ungz the tarball), and then set the 
app & bsp you want to compile it for.  (blinky, bletiny, etc.)


i do most of my dev on mynewt-core itself, but when we release, its 
really meant to be included in other people's projects (and newt 
install/upgrade can manage it as a remote dependency.)


cheers,

sterling

On 4/30/16 5:49 PM, Justin Mclean wrote:

HI,

Perhaps a silly question but how do you compile mynewt core? There doesn’t seem 
to be any instructions in the package.

I’m also run into an issue with compiling blinky on OSX and was getting this:
Building target targets/my_blinky_sim
Compiling main.c
Error: In file included from main.c:19:0:
/Users/justinmclean/Downloads/ApacheMynewt/apache-blinky-0.8.0-incubating/repos/apache-mynewt-core/libs/os//include/os/os.h:23:20:
 fatal error: stdlib.h: No such file or directory
compilation terminated.

To solve just run this to reinstall the dev tools.
xcode-select --install

I had upgraded to El Capitan the other day and look like it needs a new version 
of the dev tools.

Thanks,
Justin

Re: First draft of Coding standards in develop branch

[Sterling Hughes]

On 4/26/16 9:22 AM, Christopher Collins wrote:

On Tue, Apr 26, 2016 at 09:06:37AM -0700, Sterling Hughes wrote:

I think we do need a naming convention here - I'm fine adopting H_*.
I'll point out that almost every POSIX or LIBC header I've ever seen
uses underscore, and I believe this is only reserved in C++ -- that
said, we need to be friendly to C++, and as you point out, we should
follow a defined behavior.


These identifiers are reserved in C as well.  From 7.1.3 of n1570:

 All identifiers that begin with an underscore and either an
 uppercase letter or another underscore are always reserved for for
 any use.

(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf)



Hrm, you're right.  There are a lot of POSIX headers that have undefined 
behavior. :-)


Sterling

Re: First draft of Coding standards in develop branch

[Sterling Hughes]

On 4/26/16 8:28 AM, Christopher Collins wrote:

On Sun, Apr 24, 2016 at 10:08:09AM -0700, Sterling Hughes wrote:

Hi,

As we start to bring on new contributors, and operate as a project, its
increasingly important that we document and agree upon coding standards.
   I think we've done a good job of maintaining this consistency
informally, but, now we need to vote and agree on project standards.

I've taken a first stab at this and committed it to the develop branch,
folks can see it here:

https://github.com/apache/incubator-mynewt-core/blob/develop/CODING_STANDARDS.md


Thanks for putting this together Sterling.  I think it looks great.  My
opinion is that a coding standards document should not be overly
prescriptive.  Everyone has his own set of coding pet peeves; I suggest
we try to keep those out of this document and keep it as short as
possible.  Otherwise, people won't adhere to the document, or they will
just hate writing code and they won't contribute as much.

For me, the important rules are:
 * Maximum line length
 * Brace placement
 * Typedefs
 * All-caps macros
 * Compiler extensions (e.g., packed structs).

The first three are already captured; I think the others should be
addressed.  I think macros should always be in all-caps for reasons that
everyone is probably familiar with. Unfortunately, I don't have a good
rule for when extensions are acceptable.



+1

I have never found a scenario where macros should be lower case.  I have 
found some where I thought it would make sense (e.g. min()), but in 
retrospect, MIN() or an inline function would have been just fine.



I would also like to see a note about when it is OK to stray from the
conventions.  There will be times (rarely) when adhering to the
standards document just doesn't make sense.  "Zero-tolerance" rules
always seem to pave the road to hell :).

Finally, there is one point in particular that I wanted to address:
include guards in header files.  From the document:

 * ```#ifdef``` aliasing, shall be in the following format, where
 the package name is "os" and the file name is "callout.h":

 ```no-highlight
 #ifndef _OS_CALLOUT_H
 #define _OS_CALLOUT_H

I am not sure I like this rule for the following two reasons:
 * A lot of the code base doesn't follow this particular naming
   convention.


A lot of it does :-)


 * Identifiers starting with underscore and capital letter are
   reserved to the implementation, so technically this opens the door
   to undefined behavior.

A leading capital E is also reserved by POSIX (e.g., EINVAL).  The
naming convention I use is:

 H_CALLOUT_

I would not consider this something to worry about, and I don't think we
need to include a specific naming convention in the document.  However,
insofar as we prescribe a naming convention, it should be one which
avoids undefined behavior.



I think we do need a naming convention here - I'm fine adopting H_*. 
I'll point out that almost every POSIX or LIBC header I've ever seen 
uses underscore, and I believe this is only reserved in C++ -- that 
said, we need to be friendly to C++, and as you point out, we should 
follow a defined behavior.


Sterling

Re: First draft of Coding standards in develop branch

[Sterling Hughes]

On 4/25/16 8:57 PM, will sanfilippo wrote:

Argh! I thought I had the stupid editor set to insert spaces for tabs. Dang! Oh 
well, at least you got the point :-)

* I would vote for macros all uppercase.
* I feel strongly about define alignment but not so much about alignment within 
structure definitions although I think I align things in structures generally.

Oh, some other good ones to discuss:
1) Should we allow initialization of local variables when they are defined. (my 
vote: no)


i agree, although some people may like to do this.  i don't like it.


2) Should all local variables be defined at the beginning of the function? (my 
vote: yes)




_definitely_.

sterling

Re: BLE Stack

[Sterling Hughes]

Hi Vitya,

On 5/19/16 5:42 AM, Vitya Gnatyuk wrote:

Hi! I earlier wrote you on github as gnatyukv. I forgot to ask a main
qustion. May your projects (from the apps folder) be compiled in Keil IDE?
How to do it? I have uVision V5.17 and Armcc compiler. I cannot compile
your code yet. Maybe another compiler (GCC) needed?



Unfortunately we don't support the armcc compiler yet.  You are correct, 
it needs GCC to compile.


A fair amount of the code uses GCC specific features, that said: it 
shouldn't be too hard to make it agnostic to compiler platform.  If 
you'd like to take on the project, I'd be happy to support you as you 
make the changes.


I think the easiest way to go would be to pick a few libraries, get them 
compiling with ARM's compiler, and then send a mail to the dev@ list 
with the changes we need to make (i.e. "DON'T explcitly used 
__attribute__((packed))") -- and then everyone else will pitch and help 
convert things over so the code cleanly compiles with both GCC and ARM.


Hope this helps.

Best,

Sterling

Re: Language Reference

[Sterling Hughes]

Hi David,

Compiler options are in the compiler directory:

$ more compiler/arm-none-eabi-m4/compiler.yml

compiler.path.cc: arm-none-eabi-gcc
compiler.path.archive: arm-none-eabi-ar
compiler.path.as: arm-none-eabi-gcc -x assembler-with-cpp
compiler.path.objdump: arm-none-eabi-objdump
compiler.path.objsize: arm-none-eabi-size
compiler.path.objcopy: arm-none-eabi-objcopy

compiler.flags.default: -mcpu=cortex-m4 -mthumb-interwork -mthumb -Wall 
-Werror -fno-exceptions -ffunction-sections -fdata-sections

compiler.flags.optimized: [compiler.flags.default, -Os -ggdb]
compiler.flags.debug: [compiler.flags.default, -O1 -ggdb]

compiler.ld.flags: -static -lgcc -Wl,--gc-sections
compiler.ld.resolve_circular_deps: true
compiler.ld.mapfile: true

If you look here, of special note are:

compiler.flags.default: -mcpu=cortex-m4 -mthumb-interwork -mthumb -Wall 
-Werror -fno-exceptions -ffunction-sections -fdata-sections

compiler.flags.optimized: [compiler.flags.default, -Os -ggdb]
compiler.flags.debug: [compiler.flags.default, -O1 -ggdb]

When you specify a "build_profile" in the target (e.g. debug or 
optimized), it will take the flags that correspond with that build 
profile.  By modifying this definition (or creating your own), you can 
modify the default compiler settings.


The compiler definition is specified by the board support package, so if 
you look in:


$ more hw/bsp/olimex_stm32-e407_devboard/pkg.yml

pkg.name: hw/bsp/olimex_stm32-e407_devboard
pkg.type: bsp
pkg.description: BSP definition for the Olimex STM32-E407 board.
pkg.author: "Apache Mynewt <dev@mynewt.incubator.apache.org>"
pkg.homepage: "http://mynewt.apache.org/;
pkg.keywords:
- olimex
- stm32
- e407

pkg.arch: cortex_m4
pkg.compiler: compiler/arm-none-eabi-m4
pkg.linkerscript: "olimex_stm32-e407_devboard.ld"
pkg.linkerscript.bootloader.OVERWRITE: "boot-olimex_stm32-e407_devboard.ld"
pkg.downloadscript: "olimex_stm32-e407_devboard_download.sh"
pkg.debugscript: "olimex_stm32-e407_devboard_debug.sh"
pkg.cflags: -DSTM32F407xx
pkg.deps:
- hw/mcu/stm/stm32f4xx
- libs/baselibc

You can see the pkg.compiler defined there -- if you wanted to have a 
custom compiler definition for your BSP, you could mod it there.


If you think the default options are wrong, we're happy to discuss 
changing them as well, just come up with a proposal for what you think 
would work better.


Best,

Sterling

On 5/23/16 10:33 AM, David G. Simmons wrote:

Apparently I’m not running with C99 options for my compiles, as the error 
thrown says it is only allowed with C99. I’m still trying to figure out the 
structure of a build so I can change build options, etc.

Thanks,
dg


On May 23, 2016, at 1:27 PM, David Baker <dba...@ambiqmicro.com> wrote:

Do you run with C99 options for your compiles? I thought this for(int x = 0; x 
< 8; x++) should have been valid too.  Is this a MISRA restriction?


-Original Message-
From: David G. Simmons [mailto:santa...@mac.com]
Sent: Monday, May 23, 2016 12:14 PM
To: dev@mynewt.incubator.apache.org; sterl...@apache.org
Subject: Re: Language Reference

Poking around in bsp.h I figured out that the LED pins are 72 - 79 on this 
board, so I #DEFINEd them all as LED_BLINK_PIN_x so I could blink them all 
round-robin, just as an exercise.

I then changed int g_led_pin to int g_led_pins[8];

but initializing them all via

int x = 0;
while(x++ < 8){
hal_gpio_init_out(g_led_pins[x], 1);
}

results in: main.c:58:26: error: iteration 7u invokes undefined behavior 
[-Werror=aggressive-loop-optimizations]
 hal_gpio_init_out(g_led_pins[x], 1);

which indicates that it is caused by aggressive optimization of the loop itself 
(apparently for(int x = 0; x < 8; x++) loop structure isn’t accepted).

Interestingly, when I just now changed it to:

int x;
for(x = 0; x < 8; x++){
hal_gpio_init_out(g_led_pins[x], 1); } It all worked fine. I now have 
blinky running a colorwheel. :-)

Lots to learn, I guess.

Thanks!
dg


On May 23, 2016, at 12:32 PM, Sterling Hughes <sterl...@apache.org> wrote:

Standard C stuff should be acceptable.  What's not working -- note: we do 
compile with -Wall -Werror as the default setting.

Sterling

On 5/23/16 9:27 AM, David G. Simmons wrote:


Another N00B question …

Is there a language reference for mynewt? I’m seeing that standard C
stuff is not acceptable, so I’m wondering if there is a language
reference for how to do stuff in mynewt. specifically things like
arrays, initializing arrays, for lops, etc.

I’m playing around with the blinky app on my new STM32F Discovery
board and finding some things just don’t work as I’d expect.

TIA,
dg
--
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://g

Re: Language Reference

[Sterling Hughes]

Standard C stuff should be acceptable.  What's not working -- note: we 
do compile with -Wall -Werror as the default setting.


Sterling

On 5/23/16 9:27 AM, David G. Simmons wrote:


Another N00B question …

Is there a language reference for mynewt? I’m seeing that standard C
stuff is not acceptable, so I’m wondering if there is a language
reference for how to do stuff in mynewt. specifically things like
arrays, initializing arrays, for lops, etc.

I’m playing around with the blinky app on my new STM32F Discovery board
and finding some things just don’t work as I’d expect.

TIA,
dg
--
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: [DISCUSS] A users@ mailing list for Apache Mynewt

[Sterling Hughes]

+1 on a users mailing list, and I think David described it perfectly 
below.


Originally, I was for all support being on dev@, as pointed out in other 
mails, it is good for the project/code for developers to hear directly 
from the users.  IMO The best way to make a project easy to use and work 
well, is to have developers do customer support: it appeals to both 
pride and laziness.


However, I think it can be intimidating to post to a dev@ list as a 
first time user, especially on something like an OS.  We want to make 
that as easy as possible to get new users in.  So, I'm for having a 
separate list, BUT I think anyone developing on the project should 
strongly consider joining that list and providing support.  I certainly 
will be.


Also, I like the new mailing list archive -- we should definitely link 
to these on the doc pages.


Cheers,

Sterling

On 5/20/16 7:55 AM, David G. Simmons wrote:

As a n00b, I’ll chime in here with my experience so far … Just my $0.02, so 
take it as you will. I’ve been involved in a few ‘new’ 
product/protocol/platform development efforts over the years though.

As a new user and (potential) developer, the lack of a ‘user’ list was (as 
another has previously stated) a bit intimidating. I’m not (yet) a mynewt 
developer, just a hacker trying to get stuff working. I finally bit the bullet 
and posted to the dev list and was obviously pleasantly surprised by both the 
speed and friendliness of the response. There is a LOT of value in having the 
folks actually developing the system see all the questions from the users. I 
know it can be a distraction from the ‘real’ work to get silly questions from 
new users, but in my experience, the success of a platform is in many ways 
highly dependent on the experience of new users. If someone new can’t start 
using the platform, then you wont’ have new users, and …

I found the archives, and attempted to go through them as best I could in order 
to find answers to questions I was having initially. I figured most of them out 
on my own, from repeated trips through the docs, etc., but the email archives 
could be much more helpful. The problem is that the mail archives are … so 
1998. Not searchable, only navigable by year/month, etc. Having a proper 
interface to the mail archives would make them much more useful to users. Even 
the mail-archive.com interface — which has search — would work nicely. Having a 
forum — along the lines of phpBB2, though those are notoriously hard to keep 
spammers out of — with an email-to-forum gateway would also be helpful.

Back to hacking …

dg





On May 19, 2016, at 4:42 PM, James Pace  wrote:

I’d personally like to see these separated. Many of the comments that are 
coming in are routine (though very informative) and do not inform the design or 
development of Apache Mynewt.

And, besides, it is likely that you will have “user” and “dev”  sourced to the 
same mailbox or mail filter!

On May 19, 2016, at 11:12, p...@wrada.com wrote:


I¹d prefer to keep them together for now.  As this is new, I think that
developers are going to learn a lot from the users issues or questions,
and vice versa.  I agree that this will get too much at some point, but
I¹m really getting a lot from seeing the user and developer issues
together.


On 5/19/16, 11:08 AM, "aditi hilbert"  wrote:


Hi,

With Mynewt attracting an increasing number of both users and developers
of various levels, it might make practical sense to have a users@ mailing
list separate from dev@ mailing list. That way support questions about
product usage, asks, needs etc can be separated from
developer/design/architecture discussions. Of course, there has to be
communication between the two groups to build truly useful and usable
features, but we can bring some organization to it with the separate
mailing lists. Please comment on the suggestion.

Let¹s keep this thread open through the weekend to gauge the general
response.

thanks,
aditi






--
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: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1

[Sterling Hughes]

+1 Binding.

Ship it!

On 5/20/16 10:07 AM, Christopher Collins wrote:

On Wed, May 18, 2016 at 11:26:50PM -0700, Christopher Collins wrote:

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


+1 (binding)

Thanks,
Chris

Re: [PATCH] bsp; Fix linker error for nrf51_arduino target

[Sterling Hughes]

> On May 20, 2016, at 11:12 PM, Łukasz Rymanowski 
>  wrote:
> 
> Thanks Johan,
> 
> yes actually I was counting on my first super tiny credit for this project :)
> Hopefully will contribute more in the future.
> 
> Lukasz
> 
> 

:-) thanks for the patch- and glad to hear that!  

Johan: point taken, will use git am next time..

Cheers 

Sterling 

Re: [PATCH] bsp; Fix linker error for nrf51_arduino target

[Sterling Hughes]

thanks - looks good, and applied.  dev should be up to date.

sterling

On 5/20/16 6:25 AM, Łukasz Rymanowski wrote:

This patch renames os_bsp_init to bsp_init to make nrf51_arduino
build.
---
  hw/bsp/nrf51-arduino_101/src/os_bsp.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/bsp/nrf51-arduino_101/src/os_bsp.c 
b/hw/bsp/nrf51-arduino_101/src/os_bsp.c
index b9d52e4..888519b 100644
--- a/hw/bsp/nrf51-arduino_101/src/os_bsp.c
+++ b/hw/bsp/nrf51-arduino_101/src/os_bsp.c
@@ -70,7 +70,7 @@ bsp_imgr_current_slot(void)
  }

  void
-os_bsp_init(void)
+bsp_init(void)
  {
  /*
   * XXX this reference is here to keep this function in.

Re: Mynewt Local BSP Instance Location

[Sterling Hughes]

Hi Kevin,

I was able to reproduce the issue, it looks like you didn't update the 
repository descriptor for the pkg.compiler -- that should point to a 
package in the @apache-mynewt-core repository as well.  If you do that, 
you should get past that error.  I was able to get your target to compile.


I've filed a bug in JIRA to capture some of the improvements we'll put 
into the next release:


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

As a fresh a user of Mynewt, if you can add any thoughts you have to the 
ticket (or thread), that would be helpful.  We'll make sure to consider 
them as we improve newt.


Cheers,

Sterling

On 5/11/16 10:12 AM, microBuilder.eu wrote:

This is slightly modified since it now points to the repo folder but the
structure and files are basically identical:

targets/adablink
 app=@apache-mynewt-core/apps/blinky
 bsp=@apache-mynewt-core/hw/bsp/blefriend32
 build_profile=debug
targets/bleper_nrf51
 app=@apache-mynewt-core/apps/bleprph
 bsp=@apache-mynewt-core/hw/bsp/blefriend32
 build_profile=debug
targets/nrf51_boot
 app=@apache-mynewt-core/apps/boot
 bsp=@apache-mynewt-core/hw/bsp/blefriend32
 build_profile=optimized

K.

On 11/05/16 17:49, Christopher Collins wrote:

Ouch... there is clearly a bug in the newt tool.  There should be no
problem with creating a BSP package in the local repo.  Could you send
the output of 'newt target show'?  I would like to see what specifically
triggered this crash.  I'll also look see if I have the same issues with
local BSPs.

Thanks,
Chris