The question is how to make more apps to share the same cmake building system ?

I've failed by creating a second folder myprojects/app1 and adjusting the CMakeLists.txt accordingly.

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

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

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

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

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

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

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.

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. 

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.

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

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

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