Date   

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


Re: [RFC] k_poll_signal name and MISRA

alexander.wachter@...
 

On Montag, 29. Oktober 2018 08:48:46 CET 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 ?
What about k_poll_signal_instance ?

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
--
Alexander Wachter

Graz, University Of Technology
Student of Telematik
(Information and Computer Engineering)


Re: two iface in one device

Jukka Rissanen
 

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: [RFC] k_poll_signal name and MISRA

Erwan Gouriou
 

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 ?

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




two iface in one device

"K.I.R.A.
 

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: Get remaining thread stack space

Raj Gundi
 

Thanks Carles. I made CONFIG_INIT_STACKS=y and used stack_unused_space_get to get what I wanted.

 

Regards,

Raj

 

From: devel@... [mailto:devel@...] On Behalf Of Cufi, Carles
Sent: Sunday, October 28, 2018 3:10 PM
To: Gundi, Rajavardhan <rajavardhan.gundi@...>; devel@...
Subject: Re: [Zephyr-devel] Get remaining thread stack space

 

Hi,

 

Enable CONFIG_INIT_STACKS=y and then use the STACK_ANALYZE() macro.

 

Carles

 

From: <devel@...> on behalf of Raj Gundi <rajavardhan.gundi@...>
Date: Sunday, 28 October 2018 at 08:47
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] Get remaining thread stack space

 

Hi,

 

Is there a way to get the remaining stack space of a thread in Zephyr? For e.g. if a thread is configured to use a max stack space of 512 bytes, is there a way to find out the actual stack used by the thread? If the actual stack space used is 200 bytes, the unutilized space would be 312 bytes.

 

Regards,

Raj

 


Re: Get remaining thread stack space

Carles Cufi
 

Hi,

 

Enable CONFIG_INIT_STACKS=y and then use the STACK_ANALYZE() macro.

 

Carles

 

From: <devel@...> on behalf of Raj Gundi <rajavardhan.gundi@...>
Date: Sunday, 28 October 2018 at 08:47
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] Get remaining thread stack space

 

Hi,

 

Is there a way to get the remaining stack space of a thread in Zephyr? For e.g. if a thread is configured to use a max stack space of 512 bytes, is there a way to find out the actual stack used by the thread? If the actual stack space used is 200 bytes, the unutilized space would be 312 bytes.

 

Regards,

Raj

 


Get remaining thread stack space

Raj Gundi
 

Hi,

 

Is there a way to get the remaining stack space of a thread in Zephyr? For e.g. if a thread is configured to use a max stack space of 512 bytes, is there a way to find out the actual stack used by the thread? If the actual stack space used is 200 bytes, the unutilized space would be 312 bytes.

 

Regards,

Raj

 


Re: [RFC] k_poll_signal name and MISRA

Flavio Ceolin
 

I think this was just a typo __
Yep, just a typo :)


On 25/10/2018, 21:39, "devel@lists.zephyrproject.org on behalf of Abderrezak Mekkaoui" <devel@lists.zephyrproject.org on behalf of ab.mekka@gmail.com> wrote:

Hi Flavio,

First thing that came to my mind when I saw k_pll is a PLL. Hopefully
there is a better abbreviation for poll than pll.
Regards
Abderrezak Mekkaoui

On 10/25/2018 4:06 PM, 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
>
>
>







Re: EMULATOR BOARD QEMU

Amir Camillo <amircam@...>
 

Thank you! 

Em sex, 26 de out de 2018 às 03:10, Andrei Emeltchenko <andrei.emeltchenko.news@...> escreveu:

Hi,

On Thu, Oct 25, 2018 at 05:42:06PM -0300, Amir Camillo wrote:
>    I want to learn how to use sephyr, I am not finding the steps to emulate
>    the boards in qemu, I would like to know how to emulate the ZEPHYR IN A
>    QEMU EMULATOR. 

https://docs.zephyrproject.org/latest/boards/x86/qemu_x86/doc/board.html

cd $ZEPHYR_BASE/samples/synchronization
mkdir build && cd build

# Use cmake to configure a Ninja-based build system:
cmake -GNinja -DBOARD=qemu_x86 ..

# Now run ninja on the generated build system:
ninja run

Best regards
Andrei Emeltchenko



--

2741 - 2760 of 8041