Date   

Re: Can't perform "cmake -GNinja -DBOARD=bbc_microbit .."

Carles Cufi
 

Hi Kai,

 

Thanks for confirming this solves the issue.

Note that the installation path does *not* need to be called “gnuarmemb” since Zephyr simply uses the location set in GNUARMEMB_TOOLCHAIN_PATH. That said, using paths with spaces might break the scripts so c:\gnuarmemb makes a lot of sense.

 

Thanks,

 

Carles

 

From: Kai Ren <kren@...>
Date: Wednesday, 15 August 2018 at 15:57
To: "Cufi, Carles" <Carles.Cufi@...>, "zephyr-devel@..." <zephyr-devel@...>
Cc: vikrant8051 <vikrant8051@...>, Johan Hedberg <johan.hedberg@...>
Subject: RE: Can't perform "cmake -GNinja -DBOARD=bbc_microbit .."

 

Hello Carles,

 

This sample is just created by myself, I git clone from my private repo, not Zephyr public repo.

 

Just solved this problem that:

·         Install gnu arm embedded to c:\gnuarmemb

·         set ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb

·         set GNUARMEMB_TOOLCHAIN_PATH=c:\gnuarmemb

·         switch the source code to latest commit.

 

Thanks for the help!

 

Regards,

Kai

 

From: Cufi, Carles <Carles.Cufi@...>
Sent: Wednesday, August 15, 2018 5:12 PM
To: Kai Ren <kren@...>; zephyr-devel@...
Cc: vikrant8051 <vikrant8051@...>; Johan Hedberg <johan.hedberg@...>
Subject: RE: Can't perform "cmake -GNinja -DBOARD=bbc_microbit .."

 

Hi Kai,

 

I don’t think that sample exists: samples/microbit/generic_onoff_svr.

Maybe you have updated your Zephyr tree and that sample has been moved or renamed? Unless of course this is your own sample that is not part of Zephyr.

 

Furthermore, please follow the instructions in this email to switch to the new naming conventions for GNU Arm Embedded:

https://lists.zephyrproject.org/g/users/topic/gcc_arm_embedded_is_now_gnu/24238396

 

I just tested building the hello_world  and bluetooth/mesh_demo samples for bbc_microbit on Windows 10 with the latest master had no issues.

 

Regards,

 

Carles

 

 

 

From: devel@... <devel@...> On Behalf Of Kai Ren
Sent: 15 August 2018 10:40
To: zephyr-devel@...
Subject: [Zephyr-devel] Can't perform "cmake -GNinja -DBOARD=bbc_microbit .."

 

Hello,

I had set the dev environment up on my Windows computer by “Option 1: Windows Command Prompt”, but suddenly, it can NOT work, below is the error log, when I type cmake -GNinja -DBOARD=bbc_microbit .. , there are some errors, how can I solve this problem?

 

 

C:\Users\xxxxxx\zephyr\samples\microbit\generic_onoff_svr\build>cmake -GNinja -DBOARD=bbc_microbit ..

CMake Deprecation Warning at C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):

  The OLD behavior for policy CMP0000 will be removed from a future version

  of CMake.

 

  The cmake-policies(7) manual explains that the OLD behaviors of all

  policies are deprecated and that a policy should be set to OLD only under

  specific short-term circumstances.  Projects should be ported to the NEW

  behavior and not rely on setting a policy to OLD.

Call Stack (most recent call first):

  CMakeLists.txt:3 (include)

 

 

-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")

-- Selected BOARD bbc_microbit

Zephyr version: 1.12.0

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:33: warning: BT (defined at subsys/bluetooth/Kconfig:10) set more than once. Old value: "y", new value: "y".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:46: warning: BT_CTLR_LE_PING (defined at subsys/bluetooth/controller/Kconfig:150) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:47: warning: BT_CTLR_DATA_LENGTH (defined at subsys/bluetooth/controller/Kconfig:182) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:48: warning: BT_CTLR_PHY (defined at subsys/bluetooth/controller/Kconfig:199) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:49: warning: BT_CTLR_CHAN_SEL_2 (defined at subsys/bluetooth/controller/Kconfig:208) set more than once. Old value: "n"Parsing Kconfig tree in C:/Users/xxxxxx/zephyr//Kconfig

Using C:/Users/xxxxxx/zephyr/boards/arm/bbc_microbit/bbc_microbit_defconfig as base

Merging C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf

, new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:50: warning: BT_CTLR_MIN_USED_CHAN (defined at subsys/bluetooth/controller/Kconfig:215) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:51: warning: BT_CTLR_ADV_EXT (defined at subsys/bluetooth/controller/Kconfig:222) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:52: warning: BT_CTLR_PRIVACY (defined at subsys/bluetooth/controller/Kconfig:156) set more than once. Old value: "n", new value: "n".

warning: MICROBIT_DISPLAY (defined at drivers/display/Kconfig.microbit:9) was assigned the value "y" but got the value "n" -- check dependencies

warning: BT_L2CAP_RX_MTU (defined at subsys/bluetooth/host/Kconfig:163) was assigned the value "69" but got the value "" -- check dependencies

warning: BT_CTLR_LE_ENC (defined at subsys/bluetooth/controller/Kconfig:136) was assigned the value "n" but got the value "y" -- check dependencies

warning: BT_CTLR_DATA_LENGTH_MAX (defined at subsys/bluetooth/controller/Kconfig:189) was assigned the value "27" but got the value "" -- check dependencies

CMake Error at C:/Users/xxxxxx/zephyr/cmake/toolchain.cmake:35 (include):

  include could not find load file:

 

    C:/Users/xxxxxx/zephyr//cmake/toolchain/gnuarmemb.cmake

Call Stack (most recent call first):

  C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:242 (include)

  CMakeLists.txt:3 (include)

 

 

CMake Error at C:/Users/xxxxxx/zephyr/cmake/toolchain.cmake:53 (file):

  file MD5 requires a file name and output variable

Call Stack (most recent call first):

  C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:242 (include)

  CMakeLists.txt:3 (include)

 

 

fatal: No names found, cannot describe anything.

-- Generating zephyr/include/generated/generated_dts_board.h

CMake Error at C:/Users/xxxxxx/zephyr/cmake/dts.cmake:69 (message):

  command failed with return code: The system cannot find the file specified

Call Stack (most recent call first):

  C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:268 (include)

  CMakeLists.txt:3 (include)

 

 

-- Configuring incomplete, errors occurred!

 

 

Regards,

Kai

 


Re: Can't perform "cmake -GNinja -DBOARD=bbc_microbit .."

Kai Ren
 

Hello Carles,

 

This sample is just created by myself, I git clone from my private repo, not Zephyr public repo.

 

Just solved this problem that:

  • Install gnu arm embedded to c:\gnuarmemb

·        set ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb

·        set GNUARMEMB_TOOLCHAIN_PATH=c:\gnuarmemb

  • switch the source code to latest commit.

 

Thanks for the help!

 

Regards,

Kai

 

From: Cufi, Carles <Carles.Cufi@...>
Sent: Wednesday, August 15, 2018 5:12 PM
To: Kai Ren <kren@...>; zephyr-devel@...
Cc: vikrant8051 <vikrant8051@...>; Johan Hedberg <johan.hedberg@...>
Subject: RE: Can't perform "cmake -GNinja -DBOARD=bbc_microbit .."

 

Hi Kai,

 

I don’t think that sample exists: samples/microbit/generic_onoff_svr.

Maybe you have updated your Zephyr tree and that sample has been moved or renamed? Unless of course this is your own sample that is not part of Zephyr.

 

Furthermore, please follow the instructions in this email to switch to the new naming conventions for GNU Arm Embedded:

https://lists.zephyrproject.org/g/users/topic/gcc_arm_embedded_is_now_gnu/24238396

 

I just tested building the hello_world  and bluetooth/mesh_demo samples for bbc_microbit on Windows 10 with the latest master had no issues.

 

Regards,

 

Carles

 

 

 

From: devel@... <devel@...> On Behalf Of Kai Ren
Sent: 15 August 2018 10:40
To: zephyr-devel@...
Subject: [Zephyr-devel] Can't perform "cmake -GNinja -DBOARD=bbc_microbit .."

 

Hello,

I had set the dev environment up on my Windows computer by “Option 1: Windows Command Prompt”, but suddenly, it can NOT work, below is the error log, when I type cmake -GNinja -DBOARD=bbc_microbit .. , there are some errors, how can I solve this problem?

 

 

C:\Users\xxxxxx\zephyr\samples\microbit\generic_onoff_svr\build>cmake -GNinja -DBOARD=bbc_microbit ..

CMake Deprecation Warning at C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):

  The OLD behavior for policy CMP0000 will be removed from a future version

  of CMake.

 

  The cmake-policies(7) manual explains that the OLD behaviors of all

  policies are deprecated and that a policy should be set to OLD only under

  specific short-term circumstances.  Projects should be ported to the NEW

  behavior and not rely on setting a policy to OLD.

Call Stack (most recent call first):

  CMakeLists.txt:3 (include)

 

 

-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")

-- Selected BOARD bbc_microbit

Zephyr version: 1.12.0

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:33: warning: BT (defined at subsys/bluetooth/Kconfig:10) set more than once. Old value: "y", new value: "y".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:46: warning: BT_CTLR_LE_PING (defined at subsys/bluetooth/controller/Kconfig:150) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:47: warning: BT_CTLR_DATA_LENGTH (defined at subsys/bluetooth/controller/Kconfig:182) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:48: warning: BT_CTLR_PHY (defined at subsys/bluetooth/controller/Kconfig:199) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:49: warning: BT_CTLR_CHAN_SEL_2 (defined at subsys/bluetooth/controller/Kconfig:208) set more than once. Old value: "n"Parsing Kconfig tree in C:/Users/xxxxxx/zephyr//Kconfig

Using C:/Users/xxxxxx/zephyr/boards/arm/bbc_microbit/bbc_microbit_defconfig as base

Merging C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf

, new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:50: warning: BT_CTLR_MIN_USED_CHAN (defined at subsys/bluetooth/controller/Kconfig:215) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:51: warning: BT_CTLR_ADV_EXT (defined at subsys/bluetooth/controller/Kconfig:222) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:52: warning: BT_CTLR_PRIVACY (defined at subsys/bluetooth/controller/Kconfig:156) set more than once. Old value: "n", new value: "n".

warning: MICROBIT_DISPLAY (defined at drivers/display/Kconfig.microbit:9) was assigned the value "y" but got the value "n" -- check dependencies

warning: BT_L2CAP_RX_MTU (defined at subsys/bluetooth/host/Kconfig:163) was assigned the value "69" but got the value "" -- check dependencies

warning: BT_CTLR_LE_ENC (defined at subsys/bluetooth/controller/Kconfig:136) was assigned the value "n" but got the value "y" -- check dependencies

warning: BT_CTLR_DATA_LENGTH_MAX (defined at subsys/bluetooth/controller/Kconfig:189) was assigned the value "27" but got the value "" -- check dependencies

CMake Error at C:/Users/xxxxxx/zephyr/cmake/toolchain.cmake:35 (include):

  include could not find load file:

 

    C:/Users/xxxxxx/zephyr//cmake/toolchain/gnuarmemb.cmake

Call Stack (most recent call first):

  C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:242 (include)

  CMakeLists.txt:3 (include)

 

 

CMake Error at C:/Users/xxxxxx/zephyr/cmake/toolchain.cmake:53 (file):

  file MD5 requires a file name and output variable

Call Stack (most recent call first):

  C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:242 (include)

  CMakeLists.txt:3 (include)

 

 

fatal: No names found, cannot describe anything.

-- Generating zephyr/include/generated/generated_dts_board.h

CMake Error at C:/Users/xxxxxx/zephyr/cmake/dts.cmake:69 (message):

  command failed with return code: The system cannot find the file specified

Call Stack (most recent call first):

  C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:268 (include)

  CMakeLists.txt:3 (include)

 

 

-- Configuring incomplete, errors occurred!

 

 

Regards,

Kai

 


Breaking change to app build scripts

Sebastian Boe
 

Hi all,

to silence the 'policy CMP000' warning[0] we have decided to
require that all 'app' CMakeLists.txt build scripts invoke the
function 'cmake_minimum_required'.

This requirement is a breaking change, not updating will result
in an error[1]. To resolve the error this line must
be added to the top of the 'app' CMakeLists.txt file:

cmake_minimum_required(VERSION 3.8.2)

E.g. to update the 'hello_world' sample one could execute:

sed -i '1s;^;cmake_minimum_required(VERSION 3.8.2)\n;' $ZEPHYR_BASE/samples/hello_world/CMakeLists.txt

See PR https://github.com/zephyrproject-rtos/zephyr/pull/9186 for more details.

[0] The warning shown when cmake >= 3.9 is used.
CMake Deprecation Warning at boilerplate.cmake:38 (cmake_policy):
The OLD behavior for policy CMP0000 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
CMakeLists.txt:2 (include)

[1] The error shown if no 'cmake_minimum_required' line is present.
CMake Error in CMakeLists.txt:
No cmake_minimum_required command is present. A line of code such as

cmake_minimum_required(VERSION 3.12)

should be added at the top of the file. The version specified may be lower
if you wish to support older CMake versions for this project. For more
information run "cmake --help-policy CMP0000".


Re: Can't perform "cmake -GNinja -DBOARD=bbc_microbit .."

Carles Cufi
 

Hi Kai,

 

I don’t think that sample exists: samples/microbit/generic_onoff_svr.

Maybe you have updated your Zephyr tree and that sample has been moved or renamed? Unless of course this is your own sample that is not part of Zephyr.

 

Furthermore, please follow the instructions in this email to switch to the new naming conventions for GNU Arm Embedded:

https://lists.zephyrproject.org/g/users/topic/gcc_arm_embedded_is_now_gnu/24238396

 

I just tested building the hello_world  and bluetooth/mesh_demo samples for bbc_microbit on Windows 10 with the latest master had no issues.

 

Regards,

 

Carles

 

 

 

From: devel@... <devel@...> On Behalf Of Kai Ren
Sent: 15 August 2018 10:40
To: zephyr-devel@...
Subject: [Zephyr-devel] Can't perform "cmake -GNinja -DBOARD=bbc_microbit .."

 

Hello,

I had set the dev environment up on my Windows computer by “Option 1: Windows Command Prompt”, but suddenly, it can NOT work, below is the error log, when I type cmake -GNinja -DBOARD=bbc_microbit .. , there are some errors, how can I solve this problem?

 

 

C:\Users\xxxxxx\zephyr\samples\microbit\generic_onoff_svr\build>cmake -GNinja -DBOARD=bbc_microbit ..

CMake Deprecation Warning at C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):

  The OLD behavior for policy CMP0000 will be removed from a future version

  of CMake.

 

  The cmake-policies(7) manual explains that the OLD behaviors of all

  policies are deprecated and that a policy should be set to OLD only under

  specific short-term circumstances.  Projects should be ported to the NEW

  behavior and not rely on setting a policy to OLD.

Call Stack (most recent call first):

  CMakeLists.txt:3 (include)

 

 

-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")

-- Selected BOARD bbc_microbit

Zephyr version: 1.12.0

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:33: warning: BT (defined at subsys/bluetooth/Kconfig:10) set more than once. Old value: "y", new value: "y".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:46: warning: BT_CTLR_LE_PING (defined at subsys/bluetooth/controller/Kconfig:150) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:47: warning: BT_CTLR_DATA_LENGTH (defined at subsys/bluetooth/controller/Kconfig:182) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:48: warning: BT_CTLR_PHY (defined at subsys/bluetooth/controller/Kconfig:199) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:49: warning: BT_CTLR_CHAN_SEL_2 (defined at subsys/bluetooth/controller/Kconfig:208) set more than once. Old value: "n"Parsing Kconfig tree in C:/Users/xxxxxx/zephyr//Kconfig

Using C:/Users/xxxxxx/zephyr/boards/arm/bbc_microbit/bbc_microbit_defconfig as base

Merging C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf

, new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:50: warning: BT_CTLR_MIN_USED_CHAN (defined at subsys/bluetooth/controller/Kconfig:215) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:51: warning: BT_CTLR_ADV_EXT (defined at subsys/bluetooth/controller/Kconfig:222) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:52: warning: BT_CTLR_PRIVACY (defined at subsys/bluetooth/controller/Kconfig:156) set more than once. Old value: "n", new value: "n".

warning: MICROBIT_DISPLAY (defined at drivers/display/Kconfig.microbit:9) was assigned the value "y" but got the value "n" -- check dependencies

warning: BT_L2CAP_RX_MTU (defined at subsys/bluetooth/host/Kconfig:163) was assigned the value "69" but got the value "" -- check dependencies

warning: BT_CTLR_LE_ENC (defined at subsys/bluetooth/controller/Kconfig:136) was assigned the value "n" but got the value "y" -- check dependencies

warning: BT_CTLR_DATA_LENGTH_MAX (defined at subsys/bluetooth/controller/Kconfig:189) was assigned the value "27" but got the value "" -- check dependencies

CMake Error at C:/Users/xxxxxx/zephyr/cmake/toolchain.cmake:35 (include):

  include could not find load file:

 

    C:/Users/xxxxxx/zephyr//cmake/toolchain/gnuarmemb.cmake

Call Stack (most recent call first):

  C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:242 (include)

  CMakeLists.txt:3 (include)

 

 

CMake Error at C:/Users/xxxxxx/zephyr/cmake/toolchain.cmake:53 (file):

  file MD5 requires a file name and output variable

Call Stack (most recent call first):

  C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:242 (include)

  CMakeLists.txt:3 (include)

 

 

fatal: No names found, cannot describe anything.

-- Generating zephyr/include/generated/generated_dts_board.h

CMake Error at C:/Users/xxxxxx/zephyr/cmake/dts.cmake:69 (message):

  command failed with return code: The system cannot find the file specified

Call Stack (most recent call first):

  C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:268 (include)

  CMakeLists.txt:3 (include)

 

 

-- Configuring incomplete, errors occurred!

 

 

Regards,

Kai

 


Re: Can't perform "cmake -GNinja -DBOARD=bbc_microbit .."

Sebastian Boe
 

I suspect a mismatch between the env vars and the zephyr version.

The build system is failing to find

zephyr/cmake/toolchain.cmake

which is a fairly new file

sebo@mach:~/zephyr$ git log cmake/toolchain/gnuarmemb.cmake | head
git log cmake/toolchain/gnuarmemb.cmake | head
commit 957262e37d716985912cc9deb929293badd6d845
Author: Carles Cufi <carles.cufi@...>
Date: Fri Aug 3 17:11:23 2018 +0200

build: Replace GCC ARM Embedded with GNU Arm Embedded

The old GCC ARM Embedded website on launchpad
(https://launchpad.net/gcc-arm-embedded) has been superseeded by the new
GNU Arm Embedded one
(https://developer.arm.com/open-source/gnu-toolchain/gnu-rm).


so perhaps your env vars have been updated, but the git revision is old. Meaning
that the env vars are pointing to a feature that doesn't exist on that git revision.

Either update zephyr to at least 957262e37d716985912cc9deb929293badd6d845
or downgrade the env vars by setting ZEPHYR_TOOLCHAIN_VARIANT=gccarmemb
________________________________________
From: devel@... <devel@...> on behalf of Kai Ren <kren@...>
Sent: Wednesday, 15 August 2018 10:40:23 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] Can't perform "cmake -GNinja -DBOARD=bbc_microbit .."

Hello,
I had set the dev environment up on my Windows computer by “Option 1: Windows Command Prompt”, but suddenly, it can NOT work, below is the error log, when I type cmake -GNinja -DBOARD=bbc_microbit .. , there are some errors, how can I solve this problem?


C:\Users\xxxxxx\zephyr\samples\microbit\generic_onoff_svr\build>cmake -GNinja -DBOARD=bbc_microbit ..
CMake Deprecation Warning at C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):
The OLD behavior for policy CMP0000 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
CMakeLists.txt:3 (include)


-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")
-- Selected BOARD bbc_microbit
Zephyr version: 1.12.0
C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:33: warning: BT (defined at subsys/bluetooth/Kconfig:10) set more than once. Old value: "y", new value: "y".
C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:46: warning: BT_CTLR_LE_PING (defined at subsys/bluetooth/controller/Kconfig:150) set more than once. Old value: "n", new value: "n".
C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:47: warning: BT_CTLR_DATA_LENGTH (defined at subsys/bluetooth/controller/Kconfig:182) set more than once. Old value: "n", new value: "n".
C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:48: warning: BT_CTLR_PHY (defined at subsys/bluetooth/controller/Kconfig:199) set more than once. Old value: "n", new value: "n".
C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:49: warning: BT_CTLR_CHAN_SEL_2 (defined at subsys/bluetooth/controller/Kconfig:208) set more than once. Old value: "n"Parsing Kconfig tree in C:/Users/xxxxxx/zephyr//Kconfig
Using C:/Users/xxxxxx/zephyr/boards/arm/bbc_microbit/bbc_microbit_defconfig as base
Merging C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf
, new value: "n".
C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:50: warning: BT_CTLR_MIN_USED_CHAN (defined at subsys/bluetooth/controller/Kconfig:215) set more than once. Old value: "n", new value: "n".
C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:51: warning: BT_CTLR_ADV_EXT (defined at subsys/bluetooth/controller/Kconfig:222) set more than once. Old value: "n", new value: "n".
C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:52: warning: BT_CTLR_PRIVACY (defined at subsys/bluetooth/controller/Kconfig:156) set more than once. Old value: "n", new value: "n".
warning: MICROBIT_DISPLAY (defined at drivers/display/Kconfig.microbit:9) was assigned the value "y" but got the value "n" -- check dependencies
warning: BT_L2CAP_RX_MTU (defined at subsys/bluetooth/host/Kconfig:163) was assigned the value "69" but got the value "" -- check dependencies
warning: BT_CTLR_LE_ENC (defined at subsys/bluetooth/controller/Kconfig:136) was assigned the value "n" but got the value "y" -- check dependencies
warning: BT_CTLR_DATA_LENGTH_MAX (defined at subsys/bluetooth/controller/Kconfig:189) was assigned the value "27" but got the value "" -- check dependencies
CMake Error at C:/Users/xxxxxx/zephyr/cmake/toolchain.cmake:35 (include):
include could not find load file:

C:/Users/xxxxxx/zephyr//cmake/toolchain/gnuarmemb.cmake
Call Stack (most recent call first):
C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:242 (include)
CMakeLists.txt:3 (include)


CMake Error at C:/Users/xxxxxx/zephyr/cmake/toolchain.cmake:53 (file):
file MD5 requires a file name and output variable
Call Stack (most recent call first):
C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:242 (include)
CMakeLists.txt:3 (include)


fatal: No names found, cannot describe anything.
-- Generating zephyr/include/generated/generated_dts_board.h
CMake Error at C:/Users/xxxxxx/zephyr/cmake/dts.cmake:69 (message):
command failed with return code: The system cannot find the file specified
Call Stack (most recent call first):
C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:268 (include)
CMakeLists.txt:3 (include)


-- Configuring incomplete, errors occurred!


Regards,
Kai


Can't perform "cmake -GNinja -DBOARD=bbc_microbit .."

Kai Ren
 

Hello,

I had set the dev environment up on my Windows computer by “Option 1: Windows Command Prompt”, but suddenly, it can NOT work, below is the error log, when I type cmake -GNinja -DBOARD=bbc_microbit .. , there are some errors, how can I solve this problem?

 

 

C:\Users\xxxxxx\zephyr\samples\microbit\generic_onoff_svr\build>cmake -GNinja -DBOARD=bbc_microbit ..

CMake Deprecation Warning at C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):

  The OLD behavior for policy CMP0000 will be removed from a future version

  of CMake.

 

  The cmake-policies(7) manual explains that the OLD behaviors of all

  policies are deprecated and that a policy should be set to OLD only under

  specific short-term circumstances.  Projects should be ported to the NEW

  behavior and not rely on setting a policy to OLD.

Call Stack (most recent call first):

  CMakeLists.txt:3 (include)

 

 

-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")

-- Selected BOARD bbc_microbit

Zephyr version: 1.12.0

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:33: warning: BT (defined at subsys/bluetooth/Kconfig:10) set more than once. Old value: "y", new value: "y".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:46: warning: BT_CTLR_LE_PING (defined at subsys/bluetooth/controller/Kconfig:150) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:47: warning: BT_CTLR_DATA_LENGTH (defined at subsys/bluetooth/controller/Kconfig:182) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:48: warning: BT_CTLR_PHY (defined at subsys/bluetooth/controller/Kconfig:199) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:49: warning: BT_CTLR_CHAN_SEL_2 (defined at subsys/bluetooth/controller/Kconfig:208) set more than once. Old value: "n"Parsing Kconfig tree in C:/Users/xxxxxx/zephyr//Kconfig

Using C:/Users/xxxxxx/zephyr/boards/arm/bbc_microbit/bbc_microbit_defconfig as base

Merging C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf

, new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:50: warning: BT_CTLR_MIN_USED_CHAN (defined at subsys/bluetooth/controller/Kconfig:215) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:51: warning: BT_CTLR_ADV_EXT (defined at subsys/bluetooth/controller/Kconfig:222) set more than once. Old value: "n", new value: "n".

C:/Users/xxxxxx/zephyr/samples/microbit/generic_onoff_svr/prj_bbc_microbit.conf:52: warning: BT_CTLR_PRIVACY (defined at subsys/bluetooth/controller/Kconfig:156) set more than once. Old value: "n", new value: "n".

warning: MICROBIT_DISPLAY (defined at drivers/display/Kconfig.microbit:9) was assigned the value "y" but got the value "n" -- check dependencies

warning: BT_L2CAP_RX_MTU (defined at subsys/bluetooth/host/Kconfig:163) was assigned the value "69" but got the value "" -- check dependencies

warning: BT_CTLR_LE_ENC (defined at subsys/bluetooth/controller/Kconfig:136) was assigned the value "n" but got the value "y" -- check dependencies

warning: BT_CTLR_DATA_LENGTH_MAX (defined at subsys/bluetooth/controller/Kconfig:189) was assigned the value "27" but got the value "" -- check dependencies

CMake Error at C:/Users/xxxxxx/zephyr/cmake/toolchain.cmake:35 (include):

  include could not find load file:

 

    C:/Users/xxxxxx/zephyr//cmake/toolchain/gnuarmemb.cmake

Call Stack (most recent call first):

  C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:242 (include)

  CMakeLists.txt:3 (include)

 

 

CMake Error at C:/Users/xxxxxx/zephyr/cmake/toolchain.cmake:53 (file):

  file MD5 requires a file name and output variable

Call Stack (most recent call first):

  C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:242 (include)

  CMakeLists.txt:3 (include)

 

 

fatal: No names found, cannot describe anything.

-- Generating zephyr/include/generated/generated_dts_board.h

CMake Error at C:/Users/xxxxxx/zephyr/cmake/dts.cmake:69 (message):

  command failed with return code: The system cannot find the file specified

Call Stack (most recent call first):

  C:/Users/xxxxxx/zephyr/cmake/app/boilerplate.cmake:268 (include)

  CMakeLists.txt:3 (include)

 

 

-- Configuring incomplete, errors occurred!

 

 

Regards,

Kai

 


Development cycle of Zephyr 1.13 is coming to an end

Nashif, Anas
 

Hi,

We are slowly approaching the end of the development cycle for Zephyr 1.13. Based on the current status of things we will be closing the merge window for new features end of this week.

 

Please help with the review process of pending pull requests to accelerate the review and merge process of features and changes that need to go into the next release.

 

Thanks you very much for your contributions.

 

Anas

 


Re: how to configre the default baudrate of hci_uart sample? #ble #nrf52832#hci_uart #ble #nrf52832#hci_uart #ble

Chettimada, Vinayak Kariappa
 

Update the nrf52_pca10040.overlay file. For your custom board, place a new file <custom_board>.overlay file in your application folder with the desired DT settings/overrides.

 

https://github.com/zephyrproject-rtos/zephyr/blob/4b9d9809807397a8d9a9257801e9154c8c3d03d3/samples/bluetooth/hci_uart/nrf52_pca10040.overlay#L3

 

 

-Vinayak

 

From: devel@... [mailto:devel@...] On Behalf Of sxzxchen@...
Sent: Tuesday, August 14, 2018 9:13 AM
To: devel@...
Subject: [Zephyr-devel] how to configre the default baudrate of hci_uart sample? #ble #nrf52832#hci_uart #ble #nrf52832#hci_uart

 

Hi guys,

    The default baudrate of zephyr hci_uart sample on nordic 52832 is 1Mbits. I'd like to configure it to 115200. Is there anyone who knows how to configure it in defconfig dts or some config file else ?

   Thanks! 


how to configre the default baudrate of hci_uart sample? #ble #nrf52832#hci_uart #ble #nrf52832#hci_uart #ble

icephyr
 

Hi guys,

    The default baudrate of zephyr hci_uart sample on nordic 52832 is 1Mbits. I'd like to configure it to 115200. Is there anyone who knows how to configure it in defconfig dts or some config file else ?

   Thanks! 


Re: How to update Zephyr kernel to the newest version #gettingstartedguide

Sebastian Boe
 

Alternatively ...

sebo@mach:~/$ cd $ZEPHYR_BASE
sebo@mach:~/zephyr$ git fetch --all
sebo@mach:~/zephyr$ git tag --list
sebo@mach:~/zephyr$ git checkout zephyr-v1.12.0

If you get an error during checkout you might have made changes to Zephyr, at which point you have no choice but to learn enough git to be able to manage your out-of-tree patches.
________________________________________
From: devel@... <devel@...> on behalf of miem@... <miem@...>
Sent: Monday, 13 August 2018 3:44:31 PM
To: devel@...
Subject: [Zephyr-devel] How to update Zephyr kernel to the newest version #gettingstartedguide

Hi,

How can I update my local zephyr project (that I have cloned from Github before) to the latest (or a defined) version?

Regards,
Mina


Re: How to update Zephyr kernel to the newest version #gettingstartedguide

Chettimada, Vinayak Kariappa
 

Hi,

 

If you have changes or commits, then

 

# git pull –rebase origin

 

Or if no changes and want to have a near fresh clone then,

 

# git fetch –all -p

# git reset –hard origin/master

 

Regards,

Vinayak

 

PS: this is something I do!

 

From: devel@... [mailto:devel@...] On Behalf Of miem@...
Sent: Monday, August 13, 2018 3:45 PM
To: devel@...
Subject: [Zephyr-devel] How to update Zephyr kernel to the newest version #gettingstartedguide

 

Hi, 

How can I update my local zephyr project (that I have cloned from Github before) to the latest (or a defined) version?

Regards,
Mina


How to update Zephyr kernel to the newest version #gettingstartedguide

miem@...
 

Hi, 

How can I update my local zephyr project (that I have cloned from Github before) to the latest (or a defined) version?

Regards,
Mina


Re: zephyr HCI UART on nRF52832 - HCI interface bring up fails #ble #nrf52832#hci_uart #ble

icephyr
 

Thanks guys,I resloved this problem already.The usb2uart chip cannot cover baudrate of 1000000,when I configured baudrate of hci_uart to 115200,it worked fine.

发自我的华为手机


Re: zephyr HCI UART on nRF52832 - HCI interface bring up fails #ble #nrf52832#hci_uart #ble

Chettimada, Vinayak Kariappa
 

This is your custom board, please verify that all UART lines, Tx, Rx, RTS, and CTS are wired correctly to your converter, correct buad rate and hardware flow control is used.

 

From: devel@... [mailto:devel@...] On Behalf Of sxzxchen@...
Sent: Sunday, August 12, 2018 2:21 PM
To: devel@...
Subject: [Zephyr-devel] zephyr HCI UART on nRF52832 - HCI interface bring up fails #ble #nrf52832#hci_uart

 

I have filed an issue related to HCI UART sample from zephyr running on nrf52832. I compiled the hci_uart sample successfully, but I am not able to use the UART interface through an external USB-UART converter (CP2102 ). I btattach the dev/ttyUSBx and monitor the communication with btmon on the linux host,It indicates that the 52832 chip running hci_uart sample does not respond to the Linux host who sends hci reset command to it.Is anyone met this problem before  Any device on debugging and resolving this problem will be highly appreciated,thanks. 


zephyr HCI UART on nRF52832 - HCI interface bring up fails #ble #nrf52832#hci_uart #ble

icephyr
 

I have filed an issue related to HCI UART sample from zephyr running on nrf52832. I compiled the hci_uart sample successfully, but I am not able to use the UART interface through an external USB-UART converter (CP2102 ). I btattach the dev/ttyUSBx and monitor the communication with btmon on the linux host,It indicates that the 52832 chip running hci_uart sample does not respond to the Linux host who sends hci reset command to it.Is anyone met this problem before ? Any device on debugging and resolving this problem will be highly appreciated,thanks. 


Segger SystemView sample

Diego Sueiro
 

Hello,

I'm having problems when trying to use the SystemView for both frdm_k64f and colibri_imx7d_m4 boards. I followed these instructions and sometimes the SystemView crashes, or reports it was failed to connect to the target, or that the RTT Control Block Address was not found or it starts recording but no event is detected.
I can see in the zephyr console output it printing the RTT block address and tried to use it when start recording, but no success.

Environment:
Host: Ubuntu 16.04.4 LTS
J-Link Commander: V6.32d (frdm_k64f SWD interface with J-Link OpenSDA 2 firmware and colibri_imx7d_m4 JTAG interface with J-Link EDU)
Systemview: V2.52a


I even opened a thread in the Segger support forum reporting the crash and they said that it is working without any issues on Ubuntu with embOS application on a Cortex-M4 target device.

I'm just wondering if this sample app is currently working in the master branch.

PS.: I can debug Zephyr apps step-by-step on both boards, and I can see that apparently sysview_thread is sending out data and the SDA_LED in the frdm_64k is blinking.

Cheers,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/


ppp protocol and usb stack

Shlomi Vaknin
 

Hello!

This week I was introduced to the zephyr project. My team work on mcu with rtos and port all the third party libraries ourselves. For this reason, zephyr seems to be a very good choice to us. I was wondered if ppp protocol and usb stack (host mainly) would be supported in future releases. I did not find them in the roadmap.

Thanks a lot!

Regards,
Shlomi


Re: SAME70 GPIO latency

Jiří Kubias
 

Hi,
I measuring the time via oscilloscope - then the time measurement is independent on zephyr time. The printk is just for info. 

Best regards,
Jiri Kubias

2018-08-09 20:31 GMT+02:00 punit vara <punitvara@...>:

Hi Jiri,

Welcome to awesome zephyr community. 

On Thu, Aug 9, 2018 at 11:46 PM Jiří Kubias <jiri.kubias@...> wrote:

Hi,
Im new to Zephyr and Im trying to measure the GPIO handler latency. I have modified the samples/basic/button example to toggle LED pin when the handler rises. The test is to measure the time between input pin change and output pin change. I have measured maximal value about 3us and typical about 2.6us. The processor is SAME70 @ 300MHz so 3us is 900 instructions - why it took so long? It should be in tenth of ns.  Do I have correct approach or am I doing something wrong?  I have checked the sensor drivers and they are using the same workflow. 
 

The handler code is 

void button_pressed(struct device *gpiob, struct gpio_callback *cb, u32_t pins) 
{
   gpio_pin_write(dev, LED, cnt % 2);
   cnt++;
   printk("Button pressed at %d\n", k_cycle_get_32()); 

k_cycle_get_32() prints cycles.

Use k_uptime_get(). Follow this to measure time : http://docs.zephyrproject.org/kernel/timing/clocks.html 


}

Best regards,
Jiri Kubias

_._,_._, 
._,_
- PV 
._,_pk




--
===================================================
Ing. Jiri Kubias
 
e-mail: jiri.kubias@...
mobile: 775 593 956
===================================================


Re: SAME70 GPIO latency

punit vara <punitvara@...>
 

Hi Jiri,

Welcome to awesome zephyr community. 

On Thu, Aug 9, 2018 at 11:46 PM Jiří Kubias <jiri.kubias@...> wrote:

Hi,
Im new to Zephyr and Im trying to measure the GPIO handler latency. I have modified the samples/basic/button example to toggle LED pin when the handler rises. The test is to measure the time between input pin change and output pin change. I have measured maximal value about 3us and typical about 2.6us. The processor is SAME70 @ 300MHz so 3us is 900 instructions - why it took so long? It should be in tenth of ns.  Do I have correct approach or am I doing something wrong?  I have checked the sensor drivers and they are using the same workflow. 
 

The handler code is 

void button_pressed(struct device *gpiob, struct gpio_callback *cb, u32_t pins) 
{
   gpio_pin_write(dev, LED, cnt % 2);
   cnt++;
   printk("Button pressed at %d\n", k_cycle_get_32()); 

k_cycle_get_32() prints cycles.

Use k_uptime_get(). Follow this to measure time : http://docs.zephyrproject.org/kernel/timing/clocks.html 


}

Best regards,
Jiri Kubias

_._,_._, 
._,_
- PV 
._,_pk


SAME70 GPIO latency

Jiří Kubias
 

Hi,
Im new to Zephyr and Im trying to measure the GPIO handler latency. I have modified the samples/basic/button example to toggle LED pin when the handler rises. The test is to measure the time between input pin change and output pin change. I have measured maximal value about 3us and typical about 2.6us. The processor is SAME70 @ 300MHz so 3us is 900 instructions - why it took so long? It should be in tenth of ns.  Do I have correct approach or am I doing something wrong?  I have checked the sensor drivers and they are using the same workflow. 
 

The handler code is 

void button_pressed(struct device *gpiob, struct gpio_callback *cb, u32_t pins) 
{
   gpio_pin_write(dev, LED, cnt % 2);
   cnt++;
   printk("Button pressed at %d\n", k_cycle_get_32()); 
}

Best regards,
Jiri Kubias