Date   

Re: [Zephyr-tsc] [Zephyr-devel] Highlights from the TSC meeting during ELCE

Marti Bolivar <marti@...>
 



On Mon, Oct 29, 2018, 9:45 PM Paul Sokolovsky <paul.sokolovsky@...> wrote:
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?

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.


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

So "do all the things"?


> 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.

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


Re: [Zephyr-tsc] [Zephyr-devel] Highlights from the TSC meeting during ELCE

Carles Cufi
 

Hi Paul,

-----Original Message-----
From: tsc@lists.zephyrproject.org <tsc@lists.zephyrproject.org> On
Behalf Of Paul Sokolovsky
Sent: 29 October 2018 22:45
To: Marti Bolivar <marti@foundries.io>
Cc: Flavio Ceolin <flavio.ceolin@intel.com>; Perez-Gonzalez, Inaky
<inaky.perez-gonzalez@intel.com>; Nashif, Anas <anas.nashif@intel.com>;
devel@lists.zephyrproject.org; tsc@lists.zephyrproject.org
Subject: Re: [Zephyr-tsc] [Zephyr-devel] Highlights from the TSC meeting
during ELCE

On Mon, 29 Oct 2018 20:11:04 +0000
"Marti Bolivar" <marti@foundries.io> 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:
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.


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.

Carles


Re: [Zephyr-tsc] [Zephyr-devel] Highlights from the TSC meeting during ELCE

Paul Sokolovsky
 

On Mon, 29 Oct 2018 20:11:04 +0000
"Marti Bolivar" <marti@foundries.io> 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


Re: [Zephyr-tsc] [Zephyr-devel] Highlights from the TSC meeting during ELCE

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


My replies with IPG>> prefixed below


From: tsc@... [tsc@...] on behalf of Marti Bolivar [marti@...]
Sent: Monday, October 29, 2018 1:11 PM
To: Ceolin, Flavio
Cc: Perez-Gonzalez, Inaky; Nashif, Anas; devel@...; tsc@...
Subject: Re: [Zephyr-tsc] [Zephyr-devel] Highlights from the TSC meeting during ELCE

Hi,

I'd like to discuss some counterpoints.

On Mon, Oct 29, 2018, 6:38 PM Flavio Ceolin <flavio.ceolin@...> wrote:
"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

In all honesty I think

s/platform/Linux distribution/

And I agree.

IRC is not "easy" across platforms in a modern sense of the word, unless you use irccloud (which, full disclosure, I do, after changing from ERC within emacs by way of various other clients starting with Ircle on pre-OS X Macs back in the day).

Note irccloud is not free software.

IPG >> I'll admit I haven't used windows for a long time, but a quick google:


IPG>> many of them open source; and I can tell you pidgin (the client I use in Linux) works in Windows supporting almost every single messaging protocol reasonably open (and some propietary ones).

> - well integrated into everyone's favourite messaging client

"Everyone's"?

IPG>> I'll be quite surprised a successful multi-protocol messaging client is written that doesn't support IRC

IRC clients that look good on a modern desktop (again, other than irccloud) are lacking. (Yup, that's an opinion.) Mobile support without irccloud is also lacking. 

IPG>> pidgin for Windows/Linux/Mac/Chrome, mutter for IRC on iOS  (can't talk to that because I don't IRC from my cellphone)

And it's not like irccloud is exactly a household name.

Taking "everyone" by raw numbers, we'd be looking for WhatsApp,  WeChat, etc. integration, and I don't think their clients can be called "well" integrated with IRC.

IPG>> each of those is a private/proprietary network (for example); I for one would not install WeChat in my cellphone after all the free publicity they've gained courtesy of the Chinese Government. Now, if we are talking being able to send notifications to those networks, yes, why not? but forcing any of those to be the central forum for open discussion? disagreed.



Re: [Zephyr-tsc] [Zephyr-devel] Highlights from the TSC meeting during ELCE

Marti Bolivar <marti@...>
 

On Mon, Oct 29, 2018, 8:41 PM Cufi, Carles <Carles.Cufi@...> wrote:

Adding to Martí’s points here.

 

Can’t seem to break lines with Outlook so I will need to use another color. Apologies for that, but I blame whoever introduced HTML to this thread.

 



My fault (?). I replied from mobile.


Re: [Zephyr-tsc] [Zephyr-devel] Highlights from the TSC meeting during ELCE

Carles Cufi
 

Adding to Martí’s points here.

 

Can’t seem to break lines with Outlook so I will need to use another color. Apologies for that, but I blame whoever introduced HTML to this thread.

 

From: tsc@... <tsc@...> On Behalf Of Marti Bolivar
Sent: 29 October 2018 21:11
To: Flavio Ceolin <flavio.ceolin@...>
Cc: Perez-Gonzalez, Inaky <inaky.perez-gonzalez@...>; Nashif, Anas <anas.nashif@...>; devel@...; tsc@...
Subject: Re: [Zephyr-tsc] [Zephyr-devel] Highlights from the TSC meeting during ELCE

 

Hi,

 

I'd like to discuss some counterpoints.

On Mon, Oct 29, 2018, 6:38 PM Flavio Ceolin <flavio.ceolin@...> wrote:

"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

 

In all honesty I think

 

s/platform/Linux distribution/

 

And I agree.

 

IRC is not "easy" across platforms in a modern sense of the word, unless you use irccloud (which, full disclosure, I do, after changing from ERC within emacs by way of various other clients starting with Ircle on pre-OS X Macs back in the day).

 

Note irccloud is not free software.

 

Not only that, but IRC doesn’t provide you with a permanent connection unless you pay for money in one way or another, unless you use something like matrix and that is not very pretty.

 

 

> - well integrated into everyone's favourite messaging client

 

"Everyone's"?

 

I think this statement also has some Linux bias. Zephyr is a Linux foundation project, but it's also important to be able to develop using Zephyr and collaborate with other users on all supported platforms, and convenience and familiarity do have some practical weight here.

 

IRC clients that look good on a modern desktop (again, other than irccloud) are lacking. (Yup, that's an opinion.) Mobile support without irccloud is also lacking. 

 

Again, I completely agree with Martí here. While HexChat is usable, it definitely does not fit the category of “favourite messaging client” for most people. Mobile support is a pretty fundamental feature these days, and our users do not currently have access to it unless they use irccloud or a similar service.

 

And it's not like irccloud is exactly a household name.

 

No, but to be fair, it is very reliable and dependable.

 

Taking "everyone" by raw numbers, we'd be looking for WhatsApp,  WeChat, etc. integration, and I don't think their clients can be called "well" integrated with IRC.

 

So the above statement seems suspect to me. 

 

That said, preferring open and battle-tested standards is usually a good idea in an open source project, at least so long as they get the job done well enough.

 

And as long as they provide the functionality we need (i.e. permanent connections) for free for users. Not to mention the advanced functionality available on Slack that simply will never make it into IRC.

 

 

> - does not depend on a single corporation (looking at you, Slack)

 

Slack is a proprietary de facto standard in this context, at least in the west. IRC is a venerable and interoperable open standard with usability issues and mindshare problems depending on who you're talking to. That seems to be the real crux of the matter here.

 

There's good arguments on either side of this debate, but I think we ought to be honest with ourselves that this is really what we are arguing about.

 

I think we should carefully consider what our users would like to use as well. 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.

Now, how to actually do that is not trivial, but I’m thinking perhaps a poll amongst users of some sort?

 



yeah, easy to script, clients are lightweight, ...

 

Full of spam (and, let's be frank, some of that spam is hate speech), it's 2018 and slack is lightweight enough for all the laptops we tend to use, lacks native support for anything that isn't plain text, ...

 

 

Without a good reason
I'm totally in favor of keep using IRC.

 

I hope the above is some fodder for discussion on why this is not a no-brainer decision.

 

I hope so too. While I personally have nothing against IRC and it pretty much does the job for me, not everyone wants to set up a proxy or pay for irccloud in order to get the functionality they need.

 

Thanks,

Marti

 


>
>
>

Regards,
Flavio Ceolin



Re: Highlights from the TSC meeting during ELCE

Marti Bolivar <marti@...>
 

Hi,

I'd like to discuss some counterpoints.

On Mon, Oct 29, 2018, 6:38 PM Flavio Ceolin <flavio.ceolin@...> wrote:
"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

In all honesty I think

s/platform/Linux distribution/

And I agree.

IRC is not "easy" across platforms in a modern sense of the word, unless you use irccloud (which, full disclosure, I do, after changing from ERC within emacs by way of various other clients starting with Ircle on pre-OS X Macs back in the day).

Note irccloud is not free software.

> - well integrated into everyone's favourite messaging client

"Everyone's"?

I think this statement also has some Linux bias. Zephyr is a Linux foundation project, but it's also important to be able to develop using Zephyr and collaborate with other users on all supported platforms, and convenience and familiarity do have some practical weight here.

IRC clients that look good on a modern desktop (again, other than irccloud) are lacking. (Yup, that's an opinion.) Mobile support without irccloud is also lacking. 

And it's not like irccloud is exactly a household name.

Taking "everyone" by raw numbers, we'd be looking for WhatsApp,  WeChat, etc. integration, and I don't think their clients can be called "well" integrated with IRC.

So the above statement seems suspect to me. 

That said, preferring open and battle-tested standards is usually a good idea in an open source project, at least so long as they get the job done well enough.


> - does not depend on a single corporation (looking at you, Slack)

Slack is a proprietary de facto standard in this context, at least in the west. IRC is a venerable and interoperable open standard with usability issues and mindshare problems depending on who you're talking to. That seems to be the real crux of the matter here.

There's good arguments on either side of this debate, but I think we ought to be honest with ourselves that this is really what we are arguing about.



yeah, easy to script, clients are lightweight, ...

Full of spam (and, let's be frank, some of that spam is hate speech), it's 2018 and slack is lightweight enough for all the laptops we tend to use, lacks native support for anything that isn't plain text, ...


Without a good reason
I'm totally in favor of keep using IRC.

I hope the above is some fodder for discussion on why this is not a no-brainer decision.

Thanks,
Marti


>
>
>

Regards,
Flavio Ceolin




Re: Does the EFR32_slwstk6061a port work?

Christian Taedcke
 

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@gmail.com
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


Re: [Zephyr-tsc] Highlights from the TSC meeting during ELCE

Paul Sokolovsky
 

Hello Anas,

On Mon, 29 Oct 2018 16:51:29 +0000
"Nashif, Anas" <anas.nashif@intel.com> 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


Re: Highlights from the TSC meeting during ELCE

Flavio Ceolin
 

"Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com> 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


Re: Highlights from the TSC meeting during ELCE

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

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)


Re: Does the EFR32_slwstk6061a port work?

Kumar Gala
 

On Oct 29, 2018, at 5:00 PM, Jake Baldwin <jake.a.baldwin@gmail.com> 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


Re: Does the EFR32_slwstk6061a port work?

Kumar Gala
 

On Oct 29, 2018, at 5:00 PM, Jake Baldwin <jake.a.baldwin@gmail.com> 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


Does the EFR32_slwstk6061a port work?

jake.a.baldwin@...
 

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


Highlights from the TSC meeting during ELCE

Nashif, Anas
 

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:

 

1.       Due to the significance of the next release, Zephyr 1.14 release date will be pushed into next year. Development of 1.14 will continue into next year and merge window will close on January 31st followed by approx. 8 weeks of stabilization. The final release of 1.14 is scheduled at the end of March 2019 (March 28th). This will give us time to finalize many of the currently under heavy development features and will give us enough time to stabilize and release a stable 1.14. One of the important items on the list for 1.14 is API stabilization and tagging APIs as stable, this include both kernel, device driver and subsystem APIs.

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

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) 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 IRC. 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


Re: [Question] zephyr file transfer via BLE

우승우 <du5102@...>
 

Hi This is seungwoo

 

I will contact you with further questions.

 

AP(zephyr) <-> nrf52810(zephyr)  interface UART

 

sample/Bluetooth

 

Or is there any code that can control nrf52810 on the AP?

 

Thanks you

From: 우승우 [mailto:du5102@...]
Sent: Monday, October 29, 2018 3:03 PM
To: 'Cufi, Carles' <Carles.Cufi@...>; 'devel@...' <devel@...>
Subject: RE: [Zephyr-devel] [Question] zephyr file transfer via BLE

 

Hi This is seungwoo

 

Thank you very much for your reply.

 

I have two more questions.

 

1.     nrf52810 pin setting

-      The nrf52810 pin can be set flexibly.

-      In other words, you can set the CTS RTS TX RX pin of the UART to be flexible.

-      nrf52810 Is the pin setting in zephyr code?

-      If yes, can I set up a guide?

-      How can I disable CTS and RTS in UART?

 

2.     nrf52810 binary flash

-      I know how to write stacks and applications to the chip at the Nordic site.

-      However, zephyr does not write the stack and application provided by Nordic.

-      Is this correct?

-      In other words, do I have to write nrf52810 separately to the zephyr build binary?

 

Thanks you

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Thursday, October 18, 2018 5:15 PM
To:
우승우 <du5102@...>; devel@...
Subject: Re: [Zephyr-devel] [Question] zephyr file transfer via BLE

 

Hi there,

 

I believe mcumgr will allow you to do what you need.

Check the smp server sample here: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/subsys/mgmt/mcumgr/smp_svr

And the corresponding Android libraries here: https://github.com/runtimeco/mcumgr-android

 

Carles

 

From: <devel@...> on behalf of 우승우 <du5102@...>
Date: Thursday, 18 October 2018 at 09:35
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] [Question] zephyr file transfer via BLE

 

Hi, This is seungwoo

 

I have a question

 

If you look at the site below, I can transfer BLE file using Nordic chip.

https://devzone.nordicsemi.com/f/nordic-q-a/33093/transfer-big-file-over-ble

 

nrf52-ble-image-transfer-demo çè Android-Image-Transfer-Demo   // file transfer

 

I am trying to develop a device with BLE functionality using nrf52810 in zephyr OS.

 

Like nrf52-ble-image-transfer-demo, Can I use zephyr with an application that can transfer files with Android?

 

Or I would like to ask if there is a case in which Zephyr tried to implement file transmission via BLE.

 

Thanks you


Re: [Question] zephyr file transfer via BLE

우승우 <du5102@...>
 

Hi This is seungwoo

 

Thank you very much for your reply.

 

I have two more questions.

 

1.     nrf52810 pin setting

-      The nrf52810 pin can be set flexibly.

-      In other words, you can set the CTS RTS TX RX pin of the UART to be flexible.

-      nrf52810 Is the pin setting in zephyr code?

-      If yes, can I set up a guide?

-      How can I disable CTS and RTS in UART?

 

2.     nrf52810 binary flash

-      I know how to write stacks and applications to the chip at the Nordic site.

-      However, zephyr does not write the stack and application provided by Nordic.

-      Is this correct?

-      In other words, do I have to write nrf52810 separately to the zephyr build binary?

 

Thanks you

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Thursday, October 18, 2018 5:15 PM
To:
우승우 <du5102@...>; devel@...
Subject: Re: [Zephyr-devel] [Question] zephyr file transfer via BLE

 

Hi there,

 

I believe mcumgr will allow you to do what you need.

Check the smp server sample here: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/subsys/mgmt/mcumgr/smp_svr

And the corresponding Android libraries here: https://github.com/runtimeco/mcumgr-android

 

Carles

 

From: <devel@...> on behalf of 우승우 <du5102@...>
Date: Thursday, 18 October 2018 at 09:35
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] [Question] zephyr file transfer via BLE

 

Hi, This is seungwoo

 

I have a question

 

If you look at the site below, I can transfer BLE file using Nordic chip.

https://devzone.nordicsemi.com/f/nordic-q-a/33093/transfer-big-file-over-ble

 

nrf52-ble-image-transfer-demo çè Android-Image-Transfer-Demo   // file transfer

 

I am trying to develop a device with BLE functionality using nrf52810 in zephyr OS.

 

Like nrf52-ble-image-transfer-demo, Can I use zephyr with an application that can transfer files with Android?

 

Or I would like to ask if there is a case in which Zephyr tried to implement file transmission via BLE.

 

Thanks you


Re: [RFC] k_poll_signal name and MISRA

Paul Sokolovsky
 

Hello,

On Mon, 29 Oct 2018 08:48:46 +0100
"Erwan Gouriou" <erwan.gouriou@linaro.org> 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@intel.com>
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


Re: two iface in one device

"K.I.R.A.
 

Actually, I only need do one time initialization that is for CP startup. In CP, STA and softap will be running after initializing. 
But now, I define two devices for STA and softap that are different models for app. In init function, I have to check if CP has been initialized by STA or softap.

Best Regards,
Bub
---Original---
From: "\"K.I.R.A."<38900484@...>
Date: Mon, Oct 29, 2018 16:20 PM
To: "devel"<devel@...>;"Jukka Rissanen"<jukka.rissanen@...>;
Subject: Re: [Zephyr-devel] two iface in one device

Hi Jukka,

Thanks for your response.
It's not offloading driver. It's out of tree in development.

Best Regards,
Bub Wei
---Original---
From: "Jukka Rissanen"<jukka.rissanen@...>
Date: Mon, Oct 29, 2018 16:01 PM
To: "devel"<devel@...>;"\"K.I.R.A."<38900484@...>;
Subject: Re: [Zephyr-devel] two iface in one device

Hi Bub,

are you talking about wifi offloading device or some out-of-tree wifi
device?

The NET_DEVICE_OFFLOAD_INIT() would need to be changed a bit to create
more than one network interface for a given device if you have
offloading wifi driver.

There exists already ETH_NET_DEVICE_INIT() for ethernet which supports
more than one network interface (for VLAN support) for a given device.
You could see how it is doing things to create more than one network
interface for a given device.


Cheers,
Jukka


On Mon, 2018-10-29 at 14:58 +0800, "K.I.R.A. wrote:
> Hi ,
> I would like to define two net ifaces in one device.
> Wi-Fi STA and softap are two types of ifaces at app layer, but only
> one device at driver layer is enough,that is only one NET_DEVICE_INIT
> invoked.
>
> Do you have any idea?
>
> Best Regards,
> Bub


Re: two iface in one device

"K.I.R.A.
 

Hi Jukka,

Thanks for your response.
It's not offloading driver. It's out of tree in development.

Best Regards,
Bub Wei
---Original---
From: "Jukka Rissanen"<jukka.rissanen@...>
Date: Mon, Oct 29, 2018 16:01 PM
To: "devel"<devel@...>;"\"K.I.R.A."<38900484@...>;
Subject: Re: [Zephyr-devel] two iface in one device

Hi Bub,

are you talking about wifi offloading device or some out-of-tree wifi
device?

The NET_DEVICE_OFFLOAD_INIT() would need to be changed a bit to create
more than one network interface for a given device if you have
offloading wifi driver.

There exists already ETH_NET_DEVICE_INIT() for ethernet which supports
more than one network interface (for VLAN support) for a given device.
You could see how it is doing things to create more than one network
interface for a given device.


Cheers,
Jukka


On Mon, 2018-10-29 at 14:58 +0800, "K.I.R.A. wrote:
> Hi ,
> I would like to define two net ifaces in one device.
> Wi-Fi STA and softap are two types of ifaces at app layer, but only
> one device at driver layer is enough,that is only one NET_DEVICE_INIT
> invoked.
>
> Do you have any idea?
>
> Best Regards,
> Bub

3021 - 3040 of 8330