On Mon, 29 Oct 2018 22:08:55 +0000
"Cufi, Carles" <Carles.Cufi@...> wrote:

Hi Paul,

[]

For what is worth, I (relatively) regularly comment and post on
Reddit about Zephyr. On r/embedded to be precise, but also on other
subreddits.

Great to know, you must be <...> then ;-) (Well, nick is skipped for
privacy reasons).

1. Development channel on IRC
2. I believe there is/was something like #zephyr-bluetooth on IRC
too. I never understood why, but I heard there was.
3. Slack channel.
4. Reddit subreddit
... more

Not sure if I get this, but I think you are suggesting we combine
both IRC and Slack. While I don't think that's the greatest of
situations to find ourselves in, I would have no problem using both
(I already do in fact). But then we'd need the devs to also frequent
the Slack channel, otherwise it'd be a bit pointless.

Right, and besides that "potentially pointless" situation (or more
specifically, depending on the goodwill of developers), there 2 other
choices: don't change anything, let it work like it worked for decades,
people who need will find their way on IRC. Or, forcibly move everyone
elsewhere.

I'm curious which route will be taken. But I'm sure that whichever
will, it will be for the greater good of the project.

Anyway, while that was the more controversial point in Anas' email, I
guess the most *important* is upcoming PR/patch process changes. So, I
guess I'll wait for more info on that part from now on. (But I do hope
that more people will cast their "votes" of IRC vs non-IRC matter yet.)

Carles

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

On Mon, 29 Oct 2018 21:58:22 +0000
Marti Bolivar <marti@...> wrote:

[]

Slack is a proprietary de facto standard in this context, at
least in the west.

Love that argument. So, perhaps we shouldn't look for easy ways and
embrace diversity in general, and look for WeChat that you
mentioned or QQ?

This sentence is hard to parse, but I suspect you (and Flavio) have
both missed my point, which was that if you're talking about
"everyone's" favorite chat clients by raw number of users, IRC
integration is basically non-existent. So claiming that as a plus
seems bogus.

I personally never talked about "favorite chat clients" or something. I
just calmly use mine, based on the projects' requirements, and those
requirements for last 10-15 years were consistent - IRC (so yes, I
had to acquire my favorite IRC client, etc.). Now requirements seem to
change, so I'm just trying to understand why, and make sure that if
change is made, no improvement opportunities are missed or hasty
decisions are made, like trading "east" for "west", etc.

[]

The more dissemination we have, the better. Just randomly searched
for "zephyr rtos" (no hope for just "zephyr") on Reddit, and
disappointedly, #1 hit is still the post for 1.9 release I made a
year ago. If we can't make semi-regular posts on popular IT crowd
sites like Reddit, let's at least create a Slack channel. Or can do
both actually. Or all of them:

1. Development channel on IRC
2. I believe there is/was something like #zephyr-bluetooth on IRC
too. I never understood why, but I heard there was.
3. Slack channel.
4. Reddit subreddit
... more

So "do all the things"?

Yes, and weekly summaries of Zephyr changes too. Why not?

For one, I hope there won't be external directives where to go,
especially represented as a "community decision". (Note that I
personally happy to follow any project requirements, especially if
it's clear where they originate from and what are their purpose.)

but I think we
ought to be honest with ourselves that this is really what we are
arguing about.

[]

Since you deleted most of the rest of the context in this thread so
far, I'm not sure what including the above followed by "[]" means.

That's easy: "[]" is a common placeholder for deleted text; there was
a complaint that quoting of the thread was broken, moreover I don't
think that every participant of such threads should comment every
point of other participants, a couple of important is enough, or
discussion get unwieldy. Finally, I really appreciate your call to be
honest with ourselves of what we're arguing about, so I tried to say in
fair manner what I think about these matters.

Thanks,
Marti

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Hi Paul,

On Mon, 29 Oct 2018 20:11:04 +0000
"Marti Bolivar" <marti@...> wrote:

[]

Slack is a proprietary de facto standard in this context, at least in
the west.

Love that argument. So, perhaps we shouldn't look for easy ways and
embrace diversity in general, and look for WeChat that you mentioned or
QQ?

From Carles next mail:

IRC is not only a tool for core contributors, maintainers and TSC
members, but also users of the RTOS. The sentence “oh, but IRC still
*exists*” has come up too many times in the last few months while
introducing engineers to the Zephyr project.

That's actually very good comment. Trying to close my eyes and
make a reminiscence of that, following comes out of me: "There's an
idea to make a *support* channel on Slack for all the "IRC lives??"
people." Sounds great, and especially that there're people who want to
do support both on IRC and elsewhere.

The more dissemination we have, the better. Just randomly searched for
"zephyr rtos" (no hope for just "zephyr") on Reddit, and
disappointedly, #1 hit is still the post for 1.9 release I made a
year ago. If we can't make semi-regular posts on popular IT crowd sites
like Reddit, let's at least create a Slack channel. Or can do both
actually. Or all of them:

1. Development channel on IRC
2. I believe there is/was something like #zephyr-bluetooth on IRC too.
I never understood why, but I heard there was.
3. Slack channel.
4. Reddit subreddit
... more

but I think we
ought to be honest with ourselves that this is really what we are
arguing about.

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Hello Jake,

Am Montag, den 29.10.2018, 18:03 +0000 schrieb Kumar Gala:

On Oct 29, 2018, at 5:00 PM, Jake Baldwin <jake.a.baldwin@...

wrote:

The EFR32_SLWSTK6061A board is very similar to the
EFR32_SLWSTK6000B. The microcontroller uart0, led, and button pins
are exactly the same. Even though the microcontrollers are
different they share the same flash and RAM starting location the
same peripheral memory addresses. So I figured I would try to build
the example project for the 6061A and load it onto the 6000B. But
it didn't work.

...
gpioa is correctly listed at 0x4000a000 but the higher level group
starts at 0x4000A400 which is believe is incorrect.

Two questions: Does this look like an error? Has anyone loaded this
onto a 6061A and seen the hello world message print in a console?

Hopefully Christian can chime in if the latest code is working for
him or not.

I just tried samples/hello_world from the current master on the
efr32_slwstk6061a and it is working fine:

***** Booting Zephyr OS zephyr-v1.13.0-1384-gf2b9cc62bb *****
Hello World! efr32_slwstk6061a

Also samples/basic/button works as expected.

Since your board has a Mighty Gecko, it might be better to start from
https://github.com/zephyrproject-rtos/zephyr/pull/9042 instead of the
Flex Gecko, which is used on the EFR32_SLWSTK6061A.

Regards,
Christian

Hello Anas,

On Mon, 29 Oct 2018 16:51:29 +0000
"Nashif, Anas" <anas.nashif@...> wrote:

Hi,

The TSC had a full day F2F meeting with very good attendance and lots
of topics to discuss. Here is a list of some the most significant
decisions:

[]

2. To improve the review process we will introduce the
following changes:

Great!

a. Helper bots to help with tagging PRs and giving guidance to
experiences and new PR authors.

b. Categorization of PRs (Hotfix, Trivial, Maintainer,
Security, TSC) and setting minimal review times for a PR in each
category (more on that will be posted in the Wiki)

c. Address the lack of reviewers and slow process of getting
PRs reviewed in time. This is a major issue we have, we need more
reviewers and reviews. Do not have much details to share here, but we
are looking into introducing a system and workflow that would
encourage developers and contributors to review more. Stay tuned.

3. We will start a weekly PR backlog meeting (on IRC on
teleconference)

That's great! But what does "on IRC on teleconference" mean? Is it on
IRC or not?

to give community members the opportunity to address
concerns regarding their contributions and to raise awareness about
stale PRs and changes.

4. We are considering a new communication platform to replace

The moment I've read this line, I felt nice butterflies in my stomach.
Here it comes. Finally! The ugly zoom.us tool used for all Zephyr
meetings will be gone! That tool has ~ zero Linux browsers support. I
have to hack a URL just to be able into the meeting, and then I see
almost nothing - no participants list, no chat, no nothing. Sound
quality is also below the level of similar tools. This tool actively
discourages participation in Zephyr meetings for Linux users.

(Oh, I was suggested that there's a run-on-your-own-computer client,
but at the age of meltdowns that seems like a brave, if not crazy,
idea).

But instead...

IRC.

IRC! We're talking about replacing IRC. OMG. We need more proprietary
tools to get us into a nice cozy cave.

Candidates are Slack and gitter. This has not been decided yet,
if you have any feedback, please let us know.


More details in the upcoming weeks.

Anas

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

"Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@...> writes:

Thanks for the summary, Anas

4. We are considering a new communication platform to replace IRC. Candidates are Slack and gitter. This has not been decided yet, if you have any feedback, please let us know.

I'd like to ask what is the rationale behind IRC replacement, what is trying to be solved?

IRC is:
- easy to access for everyone from every platform
- well integrated into everyone's favourite messaging client
- does not depend on a single corporation (looking at you, Slack)

yeah, easy to script, clients are lightweight, ... Without a good reason
I'm totally in favor of keep using IRC.

Regards,
Flavio Ceolin

On Oct 29, 2018, at 5:00 PM, Jake Baldwin <jake.a.baldwin@...> wrote:

The EFR32_SLWSTK6061A board is very similar to the EFR32_SLWSTK6000B. The microcontroller uart0, led, and button pins are exactly the same. Even though the microcontrollers are different they share the same flash and RAM starting location the same peripheral memory addresses. So I figured I would try to build the example project for the 6061A and load it onto the 6000B. But it didn't work.

I followed the device tree source all the way down to zephyr/dts/arm/silabs/efr32fg1p.dtsi and found that the starting register for the gpio block is listed at 0x4000A400 not 0x4000A000 like it's supposed to be. Here's the excerpt:

gpio@4000a400 {
compatible = "silabs,efr32xg1-gpio";
reg = <0x4000a400 0xc00>;
interrupts = <9 2 17 2>;
interrupt-names = "GPIO_EVEN", "GPIO_ODD";
label = "GPIO";

ranges;
#address-cells = <1>;
#size-cells = <1>;

gpioa: gpio@4000a000 {
compatible = "silabs,efr32xg1-gpio-port";
reg = <0x4000a000 0x30>;
label = "GPIO_A";
gpio-controller;
#gpio-cells = <2>;
};
...
...


gpioa is correctly listed at 0x4000a000 but the higher level group starts at 0x4000A400 which is believe is incorrect.

Two questions: Does this look like an error? Has anyone loaded this onto a 6061A and seen the hello world message print in a console?

Hopefully Christian can chime in if the latest code is working for him or not.

Thanks,
Jake

So the 0x4000a400 is correct since its the common registers (GPIO_EXTIPSELL..GPIO_LOCK) to all port’s. There isn’t any code today that utilizes any of those registers in Zephyr so it shouldn’t be an issue.

One thing I’d suggest is maybe trying an older version of Zephyr to see if “hello world” works. Maybe we’ve broken something since the initial commit of the EFR32_SLWSTK6061A board code.

- k

On Oct 29, 2018, at 5:00 PM, Jake Baldwin <jake.a.baldwin@...> wrote:

The EFR32_SLWSTK6061A board is very similar to the EFR32_SLWSTK6000B. The microcontroller uart0, led, and button pins are exactly the same. Even though the microcontrollers are different they share the same flash and RAM starting location the same peripheral memory addresses. So I figured I would try to build the example project for the 6061A and load it onto the 6000B. But it didn't work.

I followed the device tree source all the way down to zephyr/dts/arm/silabs/efr32fg1p.dtsi and found that the starting register for the gpio block is listed at 0x4000A400 not 0x4000A000 like it's supposed to be. Here's the excerpt:

gpio@4000a400 {
compatible = "silabs,efr32xg1-gpio";
reg = <0x4000a400 0xc00>;
interrupts = <9 2 17 2>;
interrupt-names = "GPIO_EVEN", "GPIO_ODD";
label = "GPIO";

ranges;
#address-cells = <1>;
#size-cells = <1>;

gpioa: gpio@4000a000 {
compatible = "silabs,efr32xg1-gpio-port";
reg = <0x4000a000 0x30>;
label = "GPIO_A";
gpio-controller;
#gpio-cells = <2>;
};
...
...


gpioa is correctly listed at 0x4000a000 but the higher level group starts at 0x4000A400 which is believe is incorrect.

Two questions: Does this look like an error? Has anyone loaded this onto a 6061A and seen the hello world message print in a console?

Thanks,
Jake

Let me take look, I convert the EFR32 gpio driver over to device tree so its possible I made an error in an address. I didn’t have the hardware to test on.

- k

Hello,

On Mon, 29 Oct 2018 08:48:46 +0100
"Erwan Gouriou" <erwan.gouriou@...> wrote:

Making different names is good, but then I think one should be able to
identify quickly which is struct and which isn't,
What about k_struct_poll_signal or k_poll_signal_struct ?

Well, that should be simple: a noun is a struct, so k_poll_signal
remains a structure. A subroutine which performs action should contain
a verb. To avoid tautology, it may be k_poll_signal_set(). Or perhaps,
signals are raised? Then k_poll_signal_raise().

That's a basic idea which many projects follow, and which is mostly,
but not consistently, seems to be followed by Zephyr. As many other
things in Zephyr, such conventions would rather be formalized.

Flavio, one good way to approach questions like this is to do some
research/analysis and offer 3-4 alternative variants for people to
choose from (or base further alternatives on). Fairly speaking, I didn't
reply earlier in this thread, because I wanted to do such an analysis
myself, but as usual, it's backlogged by other tasks.

A variant presented above is just a "low-hanging" one. We could go
further, e.g.

2. Challenge the name "signal", it may be confusing.
3. Challenge the "_poll" infix part of the name, that's again
confusing due to noun/verb ambiguity.

Thanks,
Paul

On Thu, 25 Oct 2018 at 22:07, Flavio Ceolin <flavio.ceolin@...>
wrote:

Hi guys,

MISRA-C rule 5.7 says that a tag name shall be a unique identifier,
also reuse tag names is an undefined behavior recognized in C99
(Section 6.7.2.3).

It happens that we have in Zephyr both a struct and a function
called k_poll_signal (there may be others cases in the project),
the question is, what it is preferable, change the function to
something like, k_pll_signal_signal() or change the struct nam ? In
the latter, what is the suggestion ? Remembering that I'll follow
this pattern if necessary.


Regards,
Flavio Ceolin

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog