Re: Version on statistics structures

[Kevin Townsend]

Generating a map file during 'create-image' makes a lot of sense.  I 
haven't tried without names enabled, but  a .json file would make life 
easier compared to digging around in an .elf file or something similar.



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


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


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


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


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


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

Re: Version on statistics structures

[Kevin Townsend]

On 04/10/16 21:01, Sterling Hughes wrote:
Also, unless people object I’m going to make the stats_name_map a 
const structure (so it can be located in .text), pack it, as the name 
map is rarely referenced, and it should save a bunch of space given 
the id is only 16-bits.

+1

Version on statistics structures

[Sterling Hughes]

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


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


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


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


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


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


Best,

Sterling

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

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

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

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

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

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

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

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

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

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

STATS_SECT_DECL(stats) g_stats_stats;

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

Re: Oct. board report for Mynewt

[Mike Ryan]

Not sure if there's any value in including it, but I was able to
successfuly deliver a product/project based on MyNewt back in July:

https://github.com/mikeryan/SlideQuacker

Oct. board report for Mynewt

[aditi hilbert]

Hi Mentors,

Here’s the first draft of Mynewt’s board report for Oct.
Please review it today. It is due by tomorrow.

thanks,
aditi

---
Mynewt 

Mynewt is a real-time operating system for constrained embedded systems like 
wearables, lightbulbs, locks and doorbells. It works on a variety of 32-bit 
MCUs (microcontrollers), including ARM Cortex-M and MIPS architectures. 

Mynewt has been incubating since 2015-10-20. 

Three most important issues to address in the move towards graduation: 

1. Make further point releases capable of producing a downloadable RTOS image 
with support for multiple peripherals and network connectivity with the goals 
of the 
first major (1.0) release in the last quarter of 2016 and continued 
demonstration of 
thorough understanding, repeatability, and maturity of process. 
2. Continue to develop and execute policies that enable project contributors to 
achieve 
self-governance 
3. Expand community - attract new project contributors and users with diverse
backgrounds, grow committer base 

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be 
aware of? 

None 

How has the community developed since the last report? 

1. Active mailing lists with increasing numbers of subscribers. 15 new 
subscribers 
on dev@ mailing list since last report.
2. Increased participation by 3rd parties through pull requests for new BSP 
support,
features, and test cases. Outreach continues via conferences, exhibits, 
one on one meetings, beta testers, GSoC participation. 
3. Vigorous discussions, feature proposals, and implementation suggestions on 
@dev mailing list. 

How has the project developed since the last report? 

1. Releases: No new releases since June 6th but work on several branches are 
being merged for first 1.0 beta release in October. The project has now closed 
100+ pull requests.
2. Planning: Issues including bug reports, features, and wish list captured and 
tracked in 
ASF JIRA by members of the community. Work continues against 125 tickets opened 
for 
1.0 releases (beta and GA). 
3. Effort towards self governance: 
- Voting successfully completed to grant committer status to one new candidate 
since
last report. 

Date of last release: 

2016-06-06 

When were the last committers or PMC members elected? 

2016-10-04

Signed-off-by: 

[ ](mynewt) Sterling Hughes 
[ ](mynewt) Jim Jagielski 
[ ](mynewt) Justin Mclean 
[ ](mynewt) Greg Stein 
[ ](mynewt) P. Taylor Goetz 

Re: MIPS port (WIP)

[Sterling Hughes]

Julian,

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


Also, if you’re taking further requests, I’d love to see a PIC32 
running Mynewt as well. :-)


Sterling

On 4 Oct 2016, at 8:00, Julian Ingram wrote:


Hello all,

I have just committed a work in progress MIPS port here: 
https://github.com/IMGJulian/incubator-mynewt-core/tree/julian_dev


I am currently working on some tests, and will make a pull request 
soon with a more polished version.


Thanks,

Julian Ingram
Software Design Engineer
MIPS Platforms
Imagination Technologies Limited
t: +44 (0)113 2429814
www.imgtec.com

MIPS port (WIP)

[Julian Ingram]

Hello all,

I have just committed a work in progress MIPS port here: 
https://github.com/IMGJulian/incubator-mynewt-core/tree/julian_dev

I am currently working on some tests, and will make a pull request soon with a 
more polished version.

Thanks,

Julian Ingram
Software Design Engineer
MIPS Platforms
Imagination Technologies Limited
t: +44 (0)113 2429814
www.imgtec.com