Date   

Re: More apps sharing the same building system #nrf52840

Yasushi SHOJI
 

Hi,

On Wed, Apr 10, 2019 at 9:05 PM <gabrielef@cosmed.it> wrote:
The question is how to make more apps to share the same cmake building system ?
Do you mean by "apps" to create multiple images for multiple boards,
or multiple threads in one image?
Zephyr is not like Linux; meaning that you don't have multiple apps
running on a board. Rather, It runs an
image file containing "the app" with multiple threads. Each thread
has an entry point and acts like an
application. All source code is linked together to create a binary file.

I've failed by creating a second folder myprojects/app1 and adjusting the CMakeLists.txt accordingly.
It'd help us if you post your sample app but it sound more like CMake issue.
I don't know any good cmake tutorial but you can google for it and
find something like the following.
https://www.johnlamp.net/cmake-tutorial-4-libraries-and-subdirectories.html
--
yashi


STM32-Nucleo-F411RE SPI1 NSS pin pull-up

imre.deak@...
 
Edited

Hi,

I'm using the SPI1 bus in master mode on a STM32-Nucleo-F411RE board with the following small app:

https://github.com/ideak/zephyr-stm32-spi/blob/master/src/main.c

Things work fine, except I had to spend quite a lot of time to figure out why the NSS (chip select) line didn't work when using it in the hardware controlled mode (the HW asserts it whenever it transmits). The problem turned out to be that there wasn't either an internal or an external pull up resistor on the line (since I was only measuring it with a scope and there isn't any internal pull-up/down configured for the pin by Zephyr). So the line stayed effectively always in the low (asserted) state.

Configuring an internal pull-up for the pin solved the issue, according to the following patch:
https://github.com/ideak/zephyr/commit/57ee5f39dc86fb46415215e32e210f164ee88ffa

However I'm wondering if this is the right solution, since someone may want to install an external pull-up resistor instead and not configure any internal one. OTOH, for someone less experienced with SPI/Zephyr like me the seemingly disfunctional NSS line can be rather perplexing, so maybe the pin should still default to have a pull-up.

As a side-note after reset the pin is in the alternate function 0 mode (Jtag JTDI) and has a pull-up configured for it.
EDIT: The above is a red herring, the PA4 pin - which is what Zephyr uses for SPI1-NSS, and which the patch above changes - is in floating-input mode after reset, so there is no pull-up on it. I mixed it up with PA15, which has pull-up on it after reset (and which could be also used in the SPI1-NSS alternate function mode). My question still holds though about the ideal default state for PA4.

Any suggestions what the default should be?

Thanks,
Imre


Request for help in interfacing ENC28J60 to PCA10056 #nrf52840

giriprasad@...
 

Hi,

I am trying to interface ENC28J60 module to PCA10056(NRF52840). Below are my pin configurations:

=================    ===================================
NRF52840 PCA10056    ENC28J60 (pin numbers on the board)
=================    ===================================
P0_19                                     SCK
P0_21                                     SO
P0_20                                     SI
P0_03                                     CS
P0_04                                     INT
VDD                                    VCC
GND                                    GND
=================    ===================================


Also, I had cut and connected proper SBs on board to connect ENC28J60 board. After done with the connections part, configurations are done by using menuconfig in dhcpclient application and flashed the software. As a result, it is observed in the console that an IP Address has been generated for the board. But, when tried to ping to that IP, timeout was occurring. Please help us to solve this issue.

Thanks & Regards,
Giri Prasad N.


Re: Question about "Zephyr Modules"

Pushpal Sidhu
 

Hi,

On 5/9/19, Nashif, Anas <anas.nashif@intel.com> wrote:
Hi,
I would not compare west to bitbake, maybe to android repo.
The modules are going to be part of the zephyr project, so they will not
randomly disappear.
Gotcha. I just saw the "hal_st" and "hal_qmsi" repo's so that's good.

- Pushpal

Anas
<snip>


Re: Question about "Zephyr Modules"

Nashif, Anas
 

Hi,
I would not compare west to bitbake, maybe to android repo.
The modules are going to be part of the zephyr project, so they will not randomly disappear.

Anas

-----Original Message-----
From: Pushpal Sidhu [mailto:psidhu.devel@gmail.com]
Sent: Thursday, May 9, 2019 3:35 PM
To: Nashif, Anas <anas.nashif@intel.com>
Cc: devel <devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] Question about "Zephyr Modules"

Hi Anas,

On 5/9/19, Nashif, Anas <anas.nashif@intel.com> wrote:
Pushpal,

You will need to use west to get the modules, but you can still build
do everything else as usual.
QMSI is just the first of many PR that we follow.
Thank you for your response. I figured that we're moving towards these modules. I just wanted to verify that west is becoming an integral tool for working with Zephyr. It sounds very similar to bitbake.

Has the question of backups been answered? For example, if the source that a build relies on disappears, how can we continue to use it?

Will west be included with the SDK in the future? Or maybe not because looking at the documentation, west can actually be used to clone down Zephyr.

Thanks again!
- Pushpal

Anas

-----Original Message-----
From: devel@lists.zephyrproject.org
[mailto:devel@lists.zephyrproject.org]
On Behalf Of Pushpal Sidhu
Sent: Thursday, May 9, 2019 1:14 PM
To: devel <devel@lists.zephyrproject.org>
Subject: [Zephyr-devel] Question about "Zephyr Modules"

Hi All,

This commit caught my eye:
https://github.com/zephyrproject-rtos/zephyr/pull/16039

Does this mean that, if we use the qmsi hal going forward, we *must*
use west (I wonder why it wasn't called zest instead..) instead of the
older "cmake -DBOARD=xyz" and "make"?

This is really a general question for 'zephyr modules' as I haven't
familiarized myself with west.

Thanks,
- Pushpal




Re: Question about "Zephyr Modules"

Pushpal Sidhu
 

Hi Anas,

On 5/9/19, Nashif, Anas <anas.nashif@intel.com> wrote:
Pushpal,

You will need to use west to get the modules, but you can still build do
everything else as usual.
QMSI is just the first of many PR that we follow.
Thank you for your response. I figured that we're moving towards these
modules. I just wanted to verify that west is becoming an integral
tool for working with Zephyr. It sounds very similar to bitbake.

Has the question of backups been answered? For example, if the source
that a build relies on disappears, how can we continue to use it?

Will west be included with the SDK in the future? Or maybe not because
looking at the documentation, west can actually be used to clone down
Zephyr.

Thanks again!
- Pushpal

Anas

-----Original Message-----
From: devel@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org]
On Behalf Of Pushpal Sidhu
Sent: Thursday, May 9, 2019 1:14 PM
To: devel <devel@lists.zephyrproject.org>
Subject: [Zephyr-devel] Question about "Zephyr Modules"

Hi All,

This commit caught my eye:
https://github.com/zephyrproject-rtos/zephyr/pull/16039

Does this mean that, if we use the qmsi hal going forward, we *must* use
west (I wonder why it wasn't called zest instead..) instead of the older
"cmake -DBOARD=xyz" and "make"?

This is really a general question for 'zephyr modules' as I haven't
familiarized myself with west.

Thanks,
- Pushpal




Re: Question about "Zephyr Modules"

Nashif, Anas
 

Pushpal,

You will need to use west to get the modules, but you can still build do everything else as usual.
QMSI is just the first of many PR that we follow.

Anas

-----Original Message-----
From: devel@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org] On Behalf Of Pushpal Sidhu
Sent: Thursday, May 9, 2019 1:14 PM
To: devel <devel@lists.zephyrproject.org>
Subject: [Zephyr-devel] Question about "Zephyr Modules"

Hi All,

This commit caught my eye:
https://github.com/zephyrproject-rtos/zephyr/pull/16039

Does this mean that, if we use the qmsi hal going forward, we *must* use west (I wonder why it wasn't called zest instead..) instead of the older "cmake -DBOARD=xyz" and "make"?

This is really a general question for 'zephyr modules' as I haven't familiarized myself with west.

Thanks,
- Pushpal


Question about "Zephyr Modules"

Pushpal Sidhu
 

Hi All,

This commit caught my eye:
https://github.com/zephyrproject-rtos/zephyr/pull/16039

Does this mean that, if we use the qmsi hal going forward, we *must*
use west (I wonder why it wasn't called zest instead..) instead of the
older "cmake -DBOARD=xyz" and "make"?

This is really a general question for 'zephyr modules' as I haven't
familiarized myself with west.

Thanks,
- Pushpal


Upcoming Event: Zephyr Project: Dev Meeting - Thu, 05/09/2019 8:00am-9:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 9 May 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/993312203

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf


Updated Event: Zephyr Project: APIs #cal-invite

devel@lists.zephyrproject.org Calendar <devel@...>
 

Zephyr Project: APIs

When:
Tuesday, 7 May 2019
9:00am to 10:00am
(GMT-07:00) America/Los Angeles
Repeats: Weekly on Tuesday

Where:
https://zoom.us/j/177647878

Organizer:
devel@...

An RSVP is requested. Click here to RSVP

Description:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing


Upcoming Event: Zephyr Project: APIs - Tue, 05/07/2019 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 7 May 2019, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/177647878

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


Periodic publishing #bluetoothmesh #nrf52

paul.leguennec@...
 

Hello,

I have been trying to use the periodic publishing in mesh, but I don't really see how to use it correctly. I have read the Mesh Specification, and I already asked here for help on publishing, and somebody gave me an hint by telling me to use the BT_MESH_MODEL_PUB_DEFINE macro with an update callback, but I don't think I am doing this correctly.
Right now I have my callback :
/*Attempt of callback that would allow periodic publishing*/
static int vendor_cb_update(struct bt_mesh_model *model)
{
    struct net_buf_simple *msg = model->pub->msg;
    /*Build message for VND Model CB*/
    bt_mesh_model_msg_init(msg,BT_MESH_MODEL_OP_3(0x08,CID_ZEPHYR)); // init of the status msg handler
    return 0;
}

and I am using the macro like this :
BT_MESH_MODEL_PUB_DEFINE(vnd_pub,vendor_cb_update,3+3);

I have been able to publish a message by pushing a button, and I would like to use only periodic publishing for my project.
Does somebody already used periodic publishing and would be able to tell me what I am doing wrong ?

Many thanks,
Paul


GPIO API update

Piotr Mienkowski
 

Hi,

I started work on updating GPIO API and introducing PINCTRL API. The
initial proposal is described here:
https://github.com/zephyrproject-rtos/zephyr/issues/15611

Since the hardware implementation of GPIO and PINCTRL subsystem vary
widely between different vendors and even SoC families providing a
generic API becomes a relatively complex issue. I would like to deal
with it in a few stages:

- update GPIO API configuration options, e.g. defining pin pull-up, open
source configuration.

- extend GPIO API to support port operations

- add PINCTRL API

Issue #15611 deals only with the first part of the rework. It would be
great if some more developers could review it and leave their comments
on the issue page.

Thanks and regards,
Piotr


Re: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected

Marc Herbert
 

On Fri, Apr 26, 2019 at 02:49 AM, Paul Sokolovsky wrote:
Actually, fishing for that link, I see that a whole bunch of changes
was made to the CODEOWNERS file just recently:
https://github.com/zephyrproject-rtos/zephyr/commits/master/CODEOWNERS

Just imagine that any of those changes could break syntax a bit or
propagation of changes to it could glitch on Github side, leading to
the effect we see.
Good guess. Anas found the bug (commas) and fixed it at https://github.com/zephyrproject-rtos/zephyr/commit/af3f81ef04bccd0b959

Curious how Anas debugged this because I just found this user who put a lot of effort:
http://www.benjaminoakes.com/git/2018/08/10/Testing-changes-to-GitHub-CODEOWNERS/


2018-08-31
Dear [github] support,
 
I’ve discovered what I believe to be a bug in CODEOWNERS. In particular, a single line failing to parse [trailing # comment] causes the entire file to stop identifying codeowners. This is in contrast to .gitignore, in which a single line failing to parse simply causes that line to be skipped. [...] I verified this behavior by making a sandbox repository and making pull requests until I narrowed down when the bug occurred [...] This situation was exacerbated by a lack of error messages in the GitHub UI. Ideally, we’d have access to a linter or at least highlighting in GitHub that would call out invalid syntax. 
Github's answer:
 
Thanks for reaching out! This is currently expected behavior, but I can definitely understand why it would be unexpected. I’ll pass your feedback along to the team internally. I can’t say if or when a change will happen, but your feedback is in the right hands.

So apparently no "API" available, it would have been documented at https://help.github.com/en/articles/about-code-owners otherwise. No need to ask github either as the feedback is already "in the right hands".

Marc


Zephyr Project: Dev Meeting - Thu, 05/02/2019 8:00am-9:00am #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder:
Zephyr Project: Dev Meeting

When:
Thursday, 2 May 2019
8:00am to 9:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/993312203

Organizer:
devel@...

Description:
Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

An RSVP is requested. Click here to RSVP


MCUBoot can't find bootable image (nRF52)

Benjamin Lindqvist
 

Hey,

I've been trying to build the mcumgr/smp_svr sample on a nRF52840 DK
(pca10056) by following
https://docs.zephyrproject.org/latest/samples/subsys/mgmt/mcumgr/smp_svr/README.html,
using Zephyr v1.14.0 and MCUBoot v1.3.0.

I follow the instructions, everything gets built, signed and flashed
fine it seems, but MCUBoot can't find a bootable image. This is how I
signed the image:

./imgtool.py sign \
--key mcuboot/root-rsa-2048.pem \
--header-size 0x200 \
--align 8 \
--version 1.2 \
--slot-size 0x68000 \
$ZEPHYR_BIN_DIR/zephyr.hex \
$ZEPHYR_BIN_DIR/signed.hex

MCUBoot always gets stuck at

Remote debugging using localhost:2331
0x000004fa in main () at ../main.c:202
202 BOOT_LOG_ERR("Unable to find bootable image");

caused by boot_validate_slot(0, NULL) returning an error, in turn caused
by

if (boot_check_header_erased(slot) == 0 || (hdr->ih_flags & IMAGE_F_NON_BOOTABLE)) {

triggering. Has anyone verified the sample for the versions mentioned?


Re: Wrapping compiler builtins

Sigvart Hovland
 

I would say it’s an interest in such a pull request to enable more toolchains to build zephyr.

 

> Would you be interested in pull requests that add something like this to Zephyr? The goal would be to eliminate naked built-ins from the cross-platform parts of the code. The architecture-specific built-ins are much less of a problem, I think.

 


Re: Wrapping compiler builtins

Kumar Gala
 

On Apr 30, 2019, at 12:37 PM, Jakob Stoklund Olesen <jolesen@fb.com> wrote:

Hi,

I’m new to Zephyr. It’s an impressive project!

I’ve been compiling parts of Zephyr in different environments in order to run unit tests on macOS and using the native_posix board on a Linux machine. I hit some trivial portability issues with the Zephyr code, particularly:
• Macros like __used and __unused are already defined by a system header on macOS.
• Integer overflow built-ins like __builtin_add_overflow() were introduced in GCC 5.2, so they don’t build with GCC 4.8.

I see that header files like toolchain/xcc.h define these built-ins for compilers that don’t have them, but redefining built-ins this way has a couple problems:
• C identifiers starting with a double underscore are reserved for the implementation (compiler + standard libraries), so redefining them could cause problems with future compiler releases. See https://en.cppreference.com/w/c/language/identifier#Reserved_identifiers.
• The precise semantics of some built-ins can be impossible to replicate in compilers that don’t support them. For example __builtin_add_overflow() is generic over its argument types in a way that would be difficult to imitate even with C++ templates. Seehttps://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html.
• Some built-ins have unfortunate corner case behaviors that reflect their history more than good design. For example, __builtin_ctz(x) invokes undefined behavior when x=0 which can be surprising.
I think both 2) and 3) have the potential to cause subtle security issues that only show up on some platforms.

Other performance-conscious open source projects also use compiler built-ins, but deal with these problems by wrapping built-ins in inline functions. Two examples are
• Mozilla: https://hg.mozilla.org/mozilla-central/file/tip/mfbt/MathAlgorithms.h
• LLVM: https://llvm.org/doxygen/MathExtras_8h_source.html
These libraries of inline functions address the problems with naked built-ins by:
• Defining inline functions with normal names that aren’t reserved. The implementation uses compiler built-ins when available, so the generated machine code is normally identical after inlining.
• Defining functions with semantics that don’t extend the C language. For example, there would be separate xxx_add_overflow() functions for each integer type needed.
• Avoiding undefined behavior and surprising corner cases. For example CountTrailingZeroes32(0) is defined to return 32.

Would you be interested in pull requests that add something like this to Zephyr? The goal would be to eliminate naked built-ins from the cross-platform parts of the code. The architecture-specific built-ins are much less of a problem, I think.

Thanks,
Jakob
There is interest in this as we want to support various toolchains beyond GCC. So we need to look at cleaning this up. I’d suggest maybe working up a simple proof of concept PR as the best way to discuss this.

- k


Event: Zephyr Project: APIs #cal-invite

devel@lists.zephyrproject.org Calendar <devel@...>
 

Zephyr Project: APIs

When:
Tuesday, 7 May 2019
9:00am to 10:00am
(GMT-07:00) America/Los Angeles
Repeats: Weekly on Tuesday

Where:
https://zoom.us/j/177647878

Organizer:
devel@...

An RSVP is requested. Click here to RSVP

Description:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


Event: Zephyr Project: Dev Meeting #cal-invite

devel@lists.zephyrproject.org Calendar <devel@...>
 

Zephyr Project: Dev Meeting

When:
Thursday, 2 May 2019
8:00am to 9:00am
(GMT-07:00) America/Los Angeles
Repeats: Weekly on Thursday

Where:
https://zoom.us/j/993312203

Organizer:
tsc@...

An RSVP is requested. Click here to RSVP

Description:
Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

1721 - 1740 of 7679