Date   

Zephyr Project Newsletter Q1 2019

Zephyr Project
 

Welcome to the Zephyr Project Newsletter! As the Zephyr community continues to expand and innovate we've added this quarterly update to the growing list of resources and tools available to our ecosystem to stay connected. In this first edition we are excited to bring you updates on what's in store for Zephyr OS in 2019, provide a glimpse into some of the work currently underway in the community and share ways you can get involved in the Zephyr Project. 

 

About the Zephyr Project
Get Zephyr OS

A Look Ahead to 2019: Zephyr Project Update

 

As a vendor neutral open source project we embrace transparency and responsiveness to the needs of the community. Based on feedback from our contributor community, Technical Steering Committee (TSC) and the Governing Board, the Zephyr Project has a number of exciting technical initiatives, announcements and events planned for 2019. All of which are based on our mission to build a best in breed real-time operating system (RTOS) for resource constrained environments built with functional safety and security in mind. This year watch for:

  • Zephyr OS 1.14 with Long-Term Support (LTS)
  • Functional Safety Certifications
  • Products Powered by Zephyr OS

For more information about the Zephyr Project's 2019 plans see Governing Board Chair Amy Occhialino's (Intelblog post discussing her goals for the project in 2019. 

To hear more from TSC Chairperson Anas Nashif (Intel) about the plans for Zephyr OS in 2019 and the focus on functional safety please view his presentation from OpenIoT Summit EU 2018. 

Events and Meetings

Zephyr Project at Embedded World 2019


The Zephyr Project is exhibiting at Embedded World 2019! Be sure to visit the Zephyr Project booth in Hall 4: Stand no. 4-170 to see technical demonstrations, learn about the latest products powered by Zephyr and meet the community behind the technology. Please see the Zephyr Blog for full information on the Zephyr presence at the show.

For the full list of events where the Zephyr Community will be present, please see our Events Page. To get your event listed on our website please contact the Zephyr Project.

Zephyr 1.14 with LTS is Coming Soon


The Zephyr Project is currently working towards its first long-term support (LTS) release of Zephyr OS in April 2019. Zephyr OS 1.14 will be supported for 2 years and is intended to give product makers and developers new features and functionality with added stability and regression risk reduction. To view the progress of Zephyr OS 1.14 visit our GitHub page.

If you would like to contribute to Zephyr OS 1.14 please consider fixing bugs, adding documentation or signing up to help maintain the subsystems, API's and drivers that matter to you by joining the TSC's weekly open calls.

Following this release the Zephyr Project will return to its traditional 12 week release cadence.
  
Get the Latest Release Now

Products Powered by Zephyr OS


Each week, new products powered by Zephyr OS are entering the market and providing unique and innovative examples of how this open source RTOS is making an impact. Product makers are increasingly choosing Zephyr OS because of the benefits it provides. Take a look at just a few examples of recent product launches using Zephyr OS. To get your Zephyr OS powered product or company listed please contact the Zephyr Project Marketing Team. 
 

Adero

Adero is a system of Bluetooth-enabled tags that communicate with one another and you. The system comes together in the Adero app where you can build your smart bags, track your tagged things, and create reminders to keep them all together. Read more here

Papyr by Electronut Labs

Powered by the Zephyr OS and Nordic’s nRF52840 SoC, Papyr is an ultra low power connected epaper display. It supports both Bluetooth LE (BLE5, BLE Mesh) and 802.15.4 (Thread, Zigbee) connectivity, and can be controlled via a mobile app. Read More about Papyr here

Mark 2 by ProGlove

This 'smart wearable' addresses critical barcode scanning problems and ensures greater efficiency, ergonomics, quality and process reliability. MARK 2 is designed for use in production, logistics and retail. Read more here. 

Zephyr Project includes a fully-qualified and production-ready Bluetooth LE stack


Thanks to leadership from Zephyr Project Platinum Member Nordic Semiconductor and Adero, the Zephyr Project now includes the world’s first open-source, fully-qualified, and production-ready Bluetooth LE stack. Nordic's qualification of the Bluetooth LE stack in Zephyr enables end-product makers  to launch Bluetooth products using the native Bluetooth LE support in the Zephyr RTOS. While Zephyr is not the only RTOS to include an open source Bluetooth LE Host or Link Layer, the Zephyr Bluetooth LE stack is the only one with all required components qualified and available as open source. A complete, qualified Bluetooth LE stack (consisting of a Host, Link Layer, and Physical layer) is needed to list an end product using Bluetooth technology. (Refer to the Zephyr Host QDID: 119517 and Link Layer QDID: 101395.)

Zephyr Project now supports over 150 boards!


View supported boards here. To add your board to the list please review the porting guide and contribution guide for more details. 
 

Zephyr Community Spotlight: Maureen Helm


The depth of technical expertise and dedication of the community is one of the many areas where Zephyr Project shines. In each newsletter Zephyr Project will showcase members of our TSC to highlight their contributions to the ecosystem and share their thoughts on key initiatives underway in the community. This edition we are proud to spotlight Maureen Helm, MCU Software Architect at NXP Semiconductors and Zephyr Project Maintainer, 
Maureen Helm (NXP) discussing vendor HALs in Zephyr OS at Embedded Linux Conference Europe.
 

Describe your role in the Zephyr Project and how you became involved?


I represent NXP in the TSC and maintain several areas of the tree, including the Arm architecture, sensor subsystem, and NXP SoCs, boards, and drivers. I got involved in the Zephyr Project early on when NXP (Freescale, at the time) was evaluating whether to join as a founding member. Although this was my first foray into collaborative open source, I was quickly sold, having personally experienced the pain of developing and maintaining an in-house proprietary RTOS.
 

Looking forward, what features or functionality are you the most excited about seeing/working on in Zephyr OS in 2019?


I’m looking forward to the continued expansion of connectivity features such as BLE and Zigbee, new security features with the introduction of Arm v8m devices, and richer development tools enabled by the new “west” meta-tool.


As a maintainer, what does your day to day participation in the project look like?


I aim to review pull requests in the morning, 1) to make sure it gets done every day, and 2) to take advantage of when the European community is still online. I then try to reserve the afternoon for development work and bug fixing. Meetings and other interruptions inevitably get in the way, but as a general rule it helps me to keep pull requests moving and still make time for writing code.
 

What are some of the most important qualities for a successful maintainer?


It’s important to give specific, actionable feedback, ask questions, and explain why you’re requesting changes. If you can’t articulate why you don’t like something and how it should be changed, then reconsider your feedback. This is, in a way, similar to writing good commit messages, because if you can’t articulate why you’re changing something, then maybe you shouldn’t be changing it.
 

What advice do you have for Zephyr Project contributors who may be considering becoming a maintainer?


Start joining the weekly TSC meeting, interact with the community on Slack/IRC and the mailing list, and start reviewing code. You don’t need to be a maintainer or employed by a member company to participate!
 

Is there anything else you would like to add?


I’m thrilled to see how far the Zephyr Project has come since it launched three years ago. We started with just four boards and a handful of contributors, and have grown to over 150 boards, 439 contributors, and 1000 forks! Thank you!

Get Involved


Zephyr Project is a diverse and inclusive community dedicated to building a vendor neutral ecosystem around Zephyr OS. We welcome contributions of all types as we build a truly open source RTOS to meet the needs of developers and users inventing, building and connecting the Internet of Things. Join us.
Join the Slack Channel
Contribute to Zephyr OS
Contact Us
Copyright © 2019 Zephyr Project, All rights reserved.

Our mailing address is:
1 Letterman Drive
Building D, Suite D4700
San Francisco, CA 94129
Phone/Fax: +1 415 723 9709
https://www.linuxfoundation.org/

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

 






This email was sent to devel@...
why did I get this?    unsubscribe from this list    update subscription preferences
Zephyr Project · 1 Letterman Drive · Building D, Suite D4700 · San Francisco, CA 94129 · USA

Email Marketing Powered by Mailchimp


LE pair disconnected

Tommy Lin (林志聰) <Tommy.Lin@...>
 

Hi Ryan Erickson,

We use zephyr source code(samples/bluetooth/hci_uart) , and type following commands:

After then , we can find out device(named “2019bt”) in our phone , and we can pair it.

But “2019bt” will be disconnected after about two second at connected.

Could you give us some suggestions

Thank  You.

 


Re: Mesh Provisioning Publisher - Setting & Binding in application #bluetoothmesh #zephyrbluetoothmesh

Johan Hedberg
 

Hi Billy,

On 26 Feb 2019, at 9.47, William Fish <@WilliamFish> wrote:
I'm new to this and struggling with BLE Mesh provisioning and need help, I am using Micro-bit (nrf51) which struggle to provision via BlueZ meshctl as they have such little memory hence i am attempting to configure the mesh within the application.

All appears okay with subscriptions and I can send unsolicited massages () but i haven't managed to configure a model to publish. When i run the following I get a -16 error (EBUSY 16 /* Mount device busy */)
If I were to guess, you’re calling the configuration client APIs without waiting for the responses (passing NULL for the response parameters, like the status) and some previous call has consumed all segmented message sending contexts (CONFIG_BT_MESH_TX_SEG_MSG_COUNT). If that’s the case you’ll either need to wait for the previous operation to complete, or increase these contexts. If you enabled logging (CONFIG_BT_DEBUG_LOG=y) you should also see an error message related to the reason why EBUSY is returned. I realise this may not be feasible however, due to the limited amount of memory on the micro:bit.

Johan


Re: Seeing and running what CI does (was: CODEOWNERS check in CI)

Marc Herbert
 

Hi,

 

As a funny coincidence I experienced three (!) CI issues relevant to this discussion today:

 

1. Some one-line "typo" fix failed to link some C code for a totally unrelated reason. Shippable seems to be the only CI element that provides complete logs. So I could instantly find the error in the logs and the next second someone on Slack pointed me at the candidate (and unrelated) fix. Searching github issues for "zephyr_write" also finds the candidate fix instantly, yay! [*]

 

2. As the opposite experience, I also got for another work in progress / hack / draft PR:

     Documentation build with 'make htmldocs' failed.

... and that's it; no logs or error message whatsoever, just this line. I have some guesses of what fails in CI while everything works for me (it is a documentation _hack_) but zero information on what exactly or how.

 

3. In the same draft PR as 2. I "forgot" a license header in a temporary file.  While it does not provide the command and log, the zephyrbot told me in very nice terms what was wrong. What's still confusing however is why the zephyr-ci-tools/scripts/check_compliance.py [-m Licence] script which I did run before pushing keeps telling me everything is fine and didn't save me the round trip time (and embarrassment). A typo would also cost (another) round-trip. This script really looks like the check zephyrbot runs but... it's apparently not or not quite?

 

 

Any layer of indirection in CI creates distance between developers and CI and makes developers care less about failures that don't affect them directly. Developers are not "consumers" and the vast majority seems to prefer having too much information than too little and solve problems by themselves but if the only option they have is not to care about some failures then they don't.

 

There may be reasons for not all CI details to be available and/or easy to reproduce but they don't apply to stuff like building docs or license checks or other simple sanitycheck.

 

 

1. https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/35577

2. & 3. https://github.com/zephyrproject-rtos/zephyr/pull/13805

 

[*] "yay!"... except it's not clear why tests run by Shippable are not deterministic: https://github.com/zephyrproject-rtos/zephyr/pull/13803 randconfig maybe?  I digress.

 

 

Marc

 

 

From: Marc Herbert <marc.herbert@...>
Date: Monday, 25 February 2019 at 22:28
To: "Nashif, Anas" <anas.nashif@...>, Björn Stenberg <bjorn@...>, "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] Seeing and running what CI does (was: CODEOWNERS check in CI)

 

Hi,

 

A couple things I find confusing:

- There's only the ("beautified") output but not the commands that produced them as is typical in CI, so no obvious indication of what to do to test the next git push and make sure it will actually fix the issues before pushing again.

- The comments with the output are typically some distance away from the red/green "traffic lights" with unrelated stuff in between

- The "Details" buttons on the other hand *are* in the traffic lights and seem really designed to point at the output, I think most people expect them to but they point at the documentation instead.

 

> you do not have to look at the actual CI log which might be verbose and misleading

 

Well (most of) the actual CI log is or should be what one gets anyway when running the sanitycheck / compliance.py / etc. scripts locally so if that output is confusing then users will just submit patches to make it better (as I just did) and keep everything consistent.

 

The less difference and distance between users and CI, the better.

 

> The actual output is always available in a comment posted by zephyrbot in the same PR. The comment is updated for every run

 

It's interesting that this comment preserves some review history unlike the aggressive way the "traffic lights" in particular and github in general rewrite and bury review history. So this is Good but unfortunately inconsistent with (Bad) github so a bit confusing again. For instance it's difficult to relate the history of this comment to the corresponding git pushes and commits.

 

> We are planning at some point to use the Checks API from GH which would make things more clear.

 

Do you know some other (unrelated) project(s) to look at that already use this API?

 

Marc

 

 

From: "Nashif, Anas" <anas.nashif@...>
Date: Monday, 25 February 2019 at 17:18
To: Marc Herbert <marc.herbert@...>, Björn Stenberg <bjorn@...>, "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] Seeing and running what CI does (was: CODEOWNERS check in CI)

 

Status is actually available as a comment in the PR. We are planning at some point to use the Checks API from GH which would make things more clear.

The scripts now provide the output so you do not have to look at the actual CI log which might be verbose and misleading. If any information is missing in the comments posted by CI, please let us know.

 

Anas

 

From: <devel@...> on behalf of Marc Herbert <marc.herbert@...>
Date: Monday, 25 February 2019 at 17:28
To: Björn Stenberg <bjorn@...>, "devel@..." <devel@...>
Subject: [Zephyr-devel] Seeing and running what CI does (was: CODEOWNERS check in CI)

 

Hi Björn,

 

I asked this question on Slack some time back and Anas answered it's not possible (yet?) for various reasons, one of them related to github accounts and security.

 

Fortunately something even more useful is already possible: running the checks yourself. Just run this compliance_script.py script:

https://github.com/zephyrproject-rtos/ci-tools/tree/master/scripts

https://github.com/zephyrproject-rtos/ci-tools/pulls

 

I know run this script *before* uploading anything to github as it obviously saves round trips and time.

You also need the "sanitycheck" script in the other, main repo.

I think sanitycheck is mentioned in the online documentation and the check_compliance about to be.

 

On a related CI topic, here's why the code coverage report is very often bogus:

https://github.com/codecov/codecov-bash/issues/83 thumbs up to "vote" for it

 

Cheers,

 

Marc

 

 

From: <devel@...> on behalf of Stenberg <bjorn@...>
Date: Monday, 25 February 2019 at 00:09
To: "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] CODEOWNERS check in CI

 

Can we please make the "Details" links for these checks show the actual output of the check command, rather than the current generic information about why the check exists?

 

--

 


BUGS (Zephyr v1.14.0-rc1) Feb 26 2019

Kumar Gala
 

256:bug

121:priority: medium
103:priority: low
8:priority: high

22:Coverity
21:platform: NXP
18:area: Networking
17:area: Bluetooth
14:platform: nRF
14:area: Logging
13:area: MISRA-C
12:area: Drivers
11:area: Tests
11:area: Kernel
10:area: ARM
8:platform: ESP32
8:area: Xtensa
8:area: Memory Protection
7:area: Watchdog
7:area: Documentation
6:area: Shell
6:area: Samples
6:area: ARC
5:area: USB
5:area: Sockets
5:area: I2C
4:area: Toolchains
4:area: Testing
4:area: Power Management
4:area: File System
3:area: west
3:area: UART
3:area: Timer
3:area: PWM
3:area: POSIX
3:area: NIOS2
3:area: Device Tree
3:area: Counter
3:API
2:platform: STM32
2:good first issue
2:area: Security
2:area: Sanitycheck
2:area: SPI
2:area: Portability
2:area: Other
2:area: GPIO
2:area: Display
2:area: Conformance
2:area: Boards
1:to do
1:platform: ATMEL
1:area: mcumgr
1:area: Testing Suite
1:area: PCI
1:area: OpenThread
1:area: OTA
1:area: Memory Management
1:area: LWM2M
1:area: Kconfig
1:area: IPC
1:area: Flash
1:area: Ethernet
1:area: Debugging
1:area: Crypto / RNG
1:area: Console
1:area: Configuration System
1:area: C Library
1:area: Build System
1:LTS
1:EXT


Mesh Provisioning Publisher - Setting & Binding in application #bluetoothmesh #zephyrbluetoothmesh

William Fish
 

Hi,
I'm new to this and struggling with BLE Mesh provisioning and need help, I am using Micro-bit (nrf51) which struggle to provision via BlueZ meshctl as they have such little memory hence i am attempting to configure the mesh within the application.

All appears okay with subscriptions and I can send unsolicited massages () but i haven't managed to configure a model to publish. When i run the following I get a -16 error (EBUSY 16    /* Mount device busy */)

Any help appreciated.

Billy..
    /* Add Sensor Server model Publisher */
    err = bt_mesh_cfg_mod_pub_set(net_idx, addr, addr,
                    BT_MESH_MODEL_ID_SENSOR_CLI, &pub, NULL);       


Re: CODEOWNERS check in CI

Björn Stenberg
 

Oh! I somehow missed that. Thanks, that's good enough for me.

--
Björn


On Tue, Feb 26, 2019 at 2:16 AM Nashif, Anas <anas.nashif@...> wrote:

The actual output is always available in a comment posted by zephyrbot in the same PR. The comment is updated for every run. Is this what you are looking for?

 

Anas

 

From: <devel@...> on behalf of Björn Stenberg <bjorn@...>
Date: Monday, 25 February 2019 at 09:09
To: "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] CODEOWNERS check in CI

 

Can we please make the "Details" links for these checks show the actual output of the check command, rather than the current generic information about why the check exists?

 

--

Björn

 

 

On Sun, Feb 24, 2019 at 1:57 PM Nashif, Anas <anas.nashif@...> wrote:

Hi,

Recently we enabled a new CI check that verifies if newly added files are covered in the CODEOWNERS file.

 

For more information about the CODEOWNERS file please check https://help.github.com/en/articles/about-code-owners.

 

Whenever you are adding new files (new board, new driver, etc.) please add an entry in the CODEOWNERS file. This will mean that in the future you will be added as a reviewer when changes are submitted against those files and it is a way for others to know who is the maintainer of certain components without having to use `git blame` or other means.

 

If you think you are not the right owner of some files and you are just extending a component, please let us know (in the PR itself, on slack or per email) and we will advise what to add.

 

In the case where multiple names are associated with one or more files, the first name (github handle) is the maintainer/owner and additional names are co-maintainers/co-owners.

 

We are in the process of adding this to the documentation, so stay tuned for more information.

 

 

Regards,

Anas

 

 

 


Re: Seeing and running what CI does (was: CODEOWNERS check in CI)

Marc Herbert
 

Hi,

 

A couple things I find confusing:

- There's only the ("beautified") output but not the commands that produced them as is typical in CI, so no obvious indication of what to do to test the next git push and make sure it will actually fix the issues before pushing again.

- The comments with the output are typically some distance away from the red/green "traffic lights" with unrelated stuff in between

- The "Details" buttons on the other hand *are* in the traffic lights and seem really designed to point at the output, I think most people expect them to but they point at the documentation instead.

 

> you do not have to look at the actual CI log which might be verbose and misleading

 

Well (most of) the actual CI log is or should be what one gets anyway when running the sanitycheck / compliance.py / etc. scripts locally so if that output is confusing then users will just submit patches to make it better (as I just did) and keep everything consistent.

 

The less difference and distance between users and CI, the better.

 

> The actual output is always available in a comment posted by zephyrbot in the same PR. The comment is updated for every run

 

It's interesting that this comment preserves some review history unlike the aggressive way the "traffic lights" in particular and github in general rewrite and bury review history. So this is Good but unfortunately inconsistent with (Bad) github so a bit confusing again. For instance it's difficult to relate the history of this comment to the corresponding git pushes and commits.

 

> We are planning at some point to use the Checks API from GH which would make things more clear.

 

Do you know some other (unrelated) project(s) to look at that already use this API?

 

Marc

 

 

From: "Nashif, Anas" <anas.nashif@...>
Date: Monday, 25 February 2019 at 17:18
To: Marc Herbert <marc.herbert@...>, Björn Stenberg <bjorn@...>, "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] Seeing and running what CI does (was: CODEOWNERS check in CI)

 

Status is actually available as a comment in the PR. We are planning at some point to use the Checks API from GH which would make things more clear.

The scripts now provide the output so you do not have to look at the actual CI log which might be verbose and misleading. If any information is missing in the comments posted by CI, please let us know.

 

Anas

 

From: <devel@...> on behalf of Marc Herbert <marc.herbert@...>
Date: Monday, 25 February 2019 at 17:28
To: Björn Stenberg <bjorn@...>, "devel@..." <devel@...>
Subject: [Zephyr-devel] Seeing and running what CI does (was: CODEOWNERS check in CI)

 

Hi Björn,

 

I asked this question on Slack some time back and Anas answered it's not possible (yet?) for various reasons, one of them related to github accounts and security.

 

Fortunately something even more useful is already possible: running the checks yourself. Just run this compliance_script.py script:

https://github.com/zephyrproject-rtos/ci-tools/tree/master/scripts

https://github.com/zephyrproject-rtos/ci-tools/pulls

 

I know run this script *before* uploading anything to github as it obviously saves round trips and time.

You also need the "sanitycheck" script in the other, main repo.

I think sanitycheck is mentioned in the online documentation and the check_compliance about to be.

 

On a related CI topic, here's why the code coverage report is very often bogus:

https://github.com/codecov/codecov-bash/issues/83 thumbs up to "vote" for it

 

Cheers,

 

Marc

 

 

From: <devel@...> on behalf of Stenberg <bjorn@...>
Date: Monday, 25 February 2019 at 00:09
To: "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] CODEOWNERS check in CI

 

Can we please make the "Details" links for these checks show the actual output of the check command, rather than the current generic information about why the check exists?

 

--

 


Re: Seeing and running what CI does (was: CODEOWNERS check in CI)

Nashif, Anas
 

Status is actually available as a comment in the PR. We are planning at some point to use the Checks API from GH which would make things more clear.

The scripts now provide the output so you do not have to look at the actual CI log which might be verbose and misleading. If any information is missing in the comments posted by CI, please let us know.

 

Anas

 

From: <devel@...> on behalf of Marc Herbert <marc.herbert@...>
Date: Monday, 25 February 2019 at 17:28
To: Björn Stenberg <bjorn@...>, "devel@..." <devel@...>
Subject: [Zephyr-devel] Seeing and running what CI does (was: CODEOWNERS check in CI)

 

Hi Björn,

 

I asked this question on Slack some time back and Anas answered it's not possible (yet?) for various reasons, one of them related to github accounts and security.

 

Fortunately something even more useful is already possible: running the checks yourself. Just run this compliance_script.py script:

https://github.com/zephyrproject-rtos/ci-tools/tree/master/scripts

https://github.com/zephyrproject-rtos/ci-tools/pulls

 

I know run this script *before* uploading anything to github as it obviously saves round trips and time.

You also need the "sanitycheck" script in the other, main repo.

I think sanitycheck is mentioned in the online documentation and the check_compliance about to be.

 

On a related CI topic, here's why the code coverage report is very often bogus:

https://github.com/codecov/codecov-bash/issues/83 thumbs up to "vote" for it

 

Cheers,

 

Marc

 

 

From: <devel@...> on behalf of Stenberg <bjorn@...>
Date: Monday, 25 February 2019 at 00:09
To: "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] CODEOWNERS check in CI

 

Can we please make the "Details" links for these checks show the actual output of the check command, rather than the current generic information about why the check exists?

 

--

 


Re: CODEOWNERS check in CI

Nashif, Anas
 

The actual output is always available in a comment posted by zephyrbot in the same PR. The comment is updated for every run. Is this what you are looking for?

 

Anas

 

From: <devel@...> on behalf of Björn Stenberg <bjorn@...>
Date: Monday, 25 February 2019 at 09:09
To: "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] CODEOWNERS check in CI

 

Can we please make the "Details" links for these checks show the actual output of the check command, rather than the current generic information about why the check exists?

 

--

Björn

 

 

On Sun, Feb 24, 2019 at 1:57 PM Nashif, Anas <anas.nashif@...> wrote:

Hi,

Recently we enabled a new CI check that verifies if newly added files are covered in the CODEOWNERS file.

 

For more information about the CODEOWNERS file please check https://help.github.com/en/articles/about-code-owners.

 

Whenever you are adding new files (new board, new driver, etc.) please add an entry in the CODEOWNERS file. This will mean that in the future you will be added as a reviewer when changes are submitted against those files and it is a way for others to know who is the maintainer of certain components without having to use `git blame` or other means.

 

If you think you are not the right owner of some files and you are just extending a component, please let us know (in the PR itself, on slack or per email) and we will advise what to add.

 

In the case where multiple names are associated with one or more files, the first name (github handle) is the maintainer/owner and additional names are co-maintainers/co-owners.

 

We are in the process of adding this to the documentation, so stay tuned for more information.

 

 

Regards,

Anas

 

 

 


Seeing and running what CI does (was: CODEOWNERS check in CI)

Marc Herbert
 

Hi Björn,

 

I asked this question on Slack some time back and Anas answered it's not possible (yet?) for various reasons, one of them related to github accounts and security.

 

Fortunately something even more useful is already possible: running the checks yourself. Just run this compliance_script.py script:

https://github.com/zephyrproject-rtos/ci-tools/tree/master/scripts

https://github.com/zephyrproject-rtos/ci-tools/pulls

 

I know run this script *before* uploading anything to github as it obviously saves round trips and time.

You also need the "sanitycheck" script in the other, main repo.

I think sanitycheck is mentioned in the online documentation and the check_compliance about to be.

 

On a related CI topic, here's why the code coverage report is very often bogus:

https://github.com/codecov/codecov-bash/issues/83 thumbs up to "vote" for it

 

Cheers,

 

Marc

 

 

From: <devel@...> on behalf of Stenberg <bjorn@...>
Date: Monday, 25 February 2019 at 00:09
To: "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] CODEOWNERS check in CI

 

Can we please make the "Details" links for these checks show the actual output of the check command, rather than the current generic information about why the check exists?

 

--

 


Re: Arduino interface definition for Nordic development kits

Erwan Gouriou
 

Hi Aaron,


My question is that, do I need to add Arduino interface definition to each of the Nordic development kit's DTS files?

This is indeed the expected way to do it.
Don't forget to also add "arduino_i2c" in boards' yaml files.

Cheers
Erwan


Re: CODEOWNERS check in CI

Björn Stenberg
 

Can we please make the "Details" links for these checks show the actual output of the check command, rather than the current generic information about why the check exists?

--
Björn


On Sun, Feb 24, 2019 at 1:57 PM Nashif, Anas <anas.nashif@...> wrote:

Hi,

Recently we enabled a new CI check that verifies if newly added files are covered in the CODEOWNERS file.

 

For more information about the CODEOWNERS file please check https://help.github.com/en/articles/about-code-owners.

 

Whenever you are adding new files (new board, new driver, etc.) please add an entry in the CODEOWNERS file. This will mean that in the future you will be added as a reviewer when changes are submitted against those files and it is a way for others to know who is the maintainer of certain components without having to use `git blame` or other means.

 

If you think you are not the right owner of some files and you are just extending a component, please let us know (in the PR itself, on slack or per email) and we will advise what to add.

 

In the case where multiple names are associated with one or more files, the first name (github handle) is the maintainer/owner and additional names are co-maintainers/co-owners.

 

We are in the process of adding this to the documentation, so stay tuned for more information.

 

 

Regards,

Anas

 

 

 


CODEOWNERS check in CI

Nashif, Anas
 

Hi,

Recently we enabled a new CI check that verifies if newly added files are covered in the CODEOWNERS file.

 

For more information about the CODEOWNERS file please check https://help.github.com/en/articles/about-code-owners.

 

Whenever you are adding new files (new board, new driver, etc.) please add an entry in the CODEOWNERS file. This will mean that in the future you will be added as a reviewer when changes are submitted against those files and it is a way for others to know who is the maintainer of certain components without having to use `git blame` or other means.

 

If you think you are not the right owner of some files and you are just extending a component, please let us know (in the PR itself, on slack or per email) and we will advise what to add.

 

In the case where multiple names are associated with one or more files, the first name (github handle) is the maintainer/owner and additional names are co-maintainers/co-owners.

 

We are in the process of adding this to the documentation, so stay tuned for more information.

 

 

Regards,

Anas

 

 

 


Arduino interface definition for Nordic development kits

Aaron Xu
 

Hi,

When I try to compile "samples\shields\x_nucleo_iks01a1\" for my Nordic dev. kits(pca10040 and pca10056), occurred this error:

Error: nrf52840_pca10056.dts.pre.tmp:437.1-13 Label or path arduino_i2c not found
FATAL ERROR: Syntax error parsing input tree
...
Call Stack (most recent call first):
...
-- Configuring incomplete, errors occurred!

I noticed that the Arduino interface, like default i2c and so on, not been included in the Nordic dev. kits, either pca10040 or pca10056. So I add this patch to nrf52_pca10040.dts under "zephyr\boards\arm\nrf52_pca10040":

@@ -97,7 +97,7 @@
        cts-pin = <7>;
 };
-&i2c0 {
+arduino_i2c: &i2c0 {
        status = "ok";
        sda-pin = <26>;
        scl-pin = <27>;
 
And it works.

My question is that, do I need to add Arduino interface definition to each of the Nordic development kit's DTS files?


Re: Shippable report coverage test failure

Thea Aldrich
 

Hi Aaron,
Thanks so much for reaching out regarding PR #13658. A comment has been added directly to the PR. Please feel free to reach out if you have any questions. 

Thank you for your contribution to the Zephyr Project! 

Best,
Thea Aldrich

On Fri, Feb 22, 2019 at 2:59 AM Aaron Xu <overheat1984@...> wrote:
Hello,
Please help me check this PR:

I am not quite understanding those coverage item meaning, but I believe this patch will solve issue #13658, at least on my boards those I have.

Please give me some advice.

Thanks,


Shippable report coverage test failure

Aaron Xu
 

Hello,
Please help me check this PR:

I am not quite understanding those coverage item meaning, but I believe this patch will solve issue #13658, at least on my boards those I have.

Please give me some advice.

Thanks,


Zephyr SDK 0.10.0-rc3 available

Nashif, Anas
 

Hi,

Latest version of the SDK can be found here:

 

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.10.0-rc3

 

Please download and try things out and report any issues.

 

Changes since the last release:

 

·       Fixed multilib toolchains for x86 and nios2

·       Updated to newlib 3.1.0

·       qemu: Enable x86_64 target

·       Fixed newlib build for xtensa

 

Thanks to Kumar Gala for the great work fixing many of the issues and keeping things up to date.

 

Anas


Re: Long-Term Bluetooth Mesh Reliability

Martin <ma@...>
 

Hi Johan,
thanks - that's good to know for sure. No luck unfortunately, my
device is still not responding after some time. I have set
CONFIG_DEBUG=y and from my understanding the application seems to run
into an usage fault, which is not printed on UART unfortunately. If
you are interested, I have attached myself to bug #12726 which seems
to be about the same thing.

Best,
Martin

Am So., 17. Feb. 2019 um 15:59 Uhr schrieb Hedberg, Johan
<@jhe>:


Hi Martin,

On 17 Feb 2019, at 14.07, Martin <ma@...> wrote:
I am wondering if someone has already made experiments regarding the
long-term reliability of Bluetooth Mesh in Zephyr OS?

The reason why I am asking is this: I am on the latest master and I
use a Mesh setup consisting of ~10 devices (PCA10040 + PCA10059) with
an adjusted samples/boards/nrf52/mesh which additionally sends
heartbeat messages and at the same time blinks an LED (realized by a
timer that submits a work item which lights it, waits and switches it
off again). What I have been observing is the following: Devices that
only send a hertbeat message every 10 seconds run quite stable for
some days, but need to be power-cycled at some point in time (no
heartbeat messages, no LED blinking). Devices with higher load (e.g.
relay enabled, deliberately sending a higher amount of mesh messages)
are not responding within hours (no messages whatsoever, no LED
blinking). Even when taking pressure out of the mesh (not deliberately
sending messages anymore), they do not come back to life before I
power-cycle them.

Does someone possibly have an explanation for the issues I am
encountering or some tips regarding what I can try to tweak? I am
still trying to debug this issue but right now my results are not
meaningful expect that no new output appears in the serial console as
soon as the devices stop responding. On an older revision, I
presumably was hit by #12726 (paused execution and saw that next
pointer of queue was pointing to the current element), but could not
reproduce that I am still hit by it with the latest master.
I’m not aware of any such issues (long term usage instability), at least not in the Bluetooth/Mesh code itself, however you might want to retest together with #13431 which was merged yesterday, in case the cause of your issues is a stack overflow.

Johan


BUGS (Zephyr v1.14.0-rc1) Feb 21 2019

Kumar Gala
 

255:bug

137:priority: medium
110:priority: low
8:priority: high

25:Coverity
20:area: Networking
17:area: Bluetooth
15:area: MISRA-C
14:platform: nRF
13:area: Logging
12:area: Kernel
11:platform: NXP
11:area: Drivers
10:area: ARM
9:platform: ESP32
9:area: Xtensa
8:area: Documentation
7:area: Watchdog
7:area: Shell
7:area: Samples
7:area: Memory Protection
6:area: Sockets
5:area: USB
5:area: Toolchains
5:area: I2C
4:area: Power Management
4:area: POSIX
4:area: File System
3:area: west
3:area: UART
3:area: Timer
3:area: Tests
3:area: PWM
3:area: NIOS2
3:area: Device Tree
3:area: Counter
3:API
2:platform: STM32
2:good first issue
2:area: X86
2:area: Testing
2:area: Security
2:area: Sanitycheck
2:area: SPI
2:area: Portability
2:area: Other
2:area: GPIO
2:area: Conformance
2:area: C Library
2:area: Boards
2:area: ARC
1:to do
1:platform: SiLabs
1:platform: ATMEL
1:area: mcumgr
1:area: Testing Suite
1:area: PCI
1:area: OpenThread
1:area: OTA
1:area: LWM2M
1:area: Kconfig
1:area: IPC
1:area: Flash
1:area: Ethernet
1:area: Display
1:area: Debugging
1:area: Crypto / RNG
1:area: Console
1:area: Configuration System
1:area: Build System
1:Security Review
1:LTS
1:EXT