Date   

Bluetooth mesh using nrf52 pca10040 #bluetoothmesh #nrf52832

kunal.jagadish07@...
 

Hey, I am trying to establish a bluetooth mesh using the Raspberry Pi 3 (bluez meshctl) as the provisioner and the nrf52 boards as the nodes. The nodes have to periodically send sensor data (LPN) to the provisioner (Raspberry Pi) across the mesh. The mesh will consist of ~5k nodes. I want to extract the data and the rssi value from the transmitted packet on the Raspberry Pi. How would I go about with this? 


Re: i.MX 6/7 Flexcan driver Zephyr porting

Maureen Helm
 

Hi Aymeric,
There is a bare metal flexcan driver in ext/hal/nxp/imx/drivers that you can use as a starting point. You can create a shim to adapt it to the Zephyr CAN API, similar to what has been done for other NXP drivers.

For Ethernet, do you want to run that on the M4 Zephyr core or the A7 Linux core? It would be more challenging to get that working on the M4 core since we don't have a bare metal Ethernet driver to start with, and I don't know offhand if hardware allows that.

Maureen

-----Original Message-----
From: devel@... [mailto:devel@...] On Behalf Of Aymeric
Sent: Wednesday, February 13, 2019 8:31 AM
To: Zephyr-devel@...
Subject: [Zephyr-devel] i.MX 6/7 Flexcan driver Zephyr porting

Hi all,

I'm new to Zephyr's project, I tested some of the samples on a couples of boards.

For my project, I need a board on which Zephyr would support CAN & TCP/IP Stack.

I only found Zephyr CAN drivers for STM32 boards but they usually don't are equipped with Ethernet or at least are not supported.

So, my question is, is iMX 6/7 flexcan driver in a porting for Zephyr ?

My goal would be to use a NXP i.MX7 Colibri Board with a Evaluation Board, hardwarely, this board is CAN & Ethernet support.

My only other alternative would be to use a Stand-alone CAN controller but if I can avoid it, it would be nice.

Any advice would be appreciated.

Thanks,

Aymeric


BUGS (Zephyr v1.14.0-rc1) Feb 14 2019

Kumar Gala
 

257:bug

121:priority: low
97:priority: medium
6:priority: high

32:area: Networking
29:Coverity
16:area: Bluetooth
13:platform: nRF
12:area: Kernel
11:area: Logging
11:area: Drivers
11:area: ARM
10:area: Xtensa
8:platform: ESP32
8:area: Samples
7:platform: NXP
7:area: Shell
7:area: Documentation
6:area: Sockets
6:area: Memory Protection
5:area: USB
5:area: Toolchains
5:area: Power Management
5:area: POSIX
5:area: MISRA-C
4:platform: STM32
4:area: Watchdog
4:area: I2C
4:area: Device Tree
4:area: Build System
3:good first issue
3:area: west
3:area: UART
3:area: Timer
3:area: Security
3:area: PWM
3:area: NIOS2
3:area: Counter
3:API
2:area: native port
2:area: Tests
2:area: Testing
2:area: Sensors
2:area: Sanitycheck
2:area: SPI
2:area: Portability
2:area: Other
2:area: GPIO
2:area: Flash
2:area: File System
2:area: Conformance
2:area: C Library
2:area: Boards
2:area: ARC
2:EXT
1:to do
1:question
1:platform: SiLabs
1:platform: ATMEL
1:area: mcumgr
1:area: X86
1:area: Testing Suite
1:area: Pinmux
1:area: PCI
1:area: OpenThread
1:area: OTA
1:area: LWM2M
1:area: IPC
1:area: Flashing
1:area: Ethernet
1:area: Debugging
1:area: Crypto / RNG
1:area: Console
1:area: Configuration System
1:TSC
1:Security Review
1:RFC
1:LTS


Re: strange board DTS parsing error

Kumar Gala
 

Reg is specifying which chip select to use. In your dts snippet since you have a cs-gpio I assumed that there is a single CS and so reg should be 0 instead of 1.

- k

On Feb 12, 2019, at 10:05 PM, Li, Jun R <jun.r.li@...> wrote:

Hah, it works after reg is changed to <0>. Thank you, Kumar!

By the way, what does "reg=<0>" mean for the sensor bmi160 here?

Regards,
Jun


On 2/12/19, 19:36, "Kumar Gala" <kumar.gala@...> wrote:

I’m guessing this is because the reg should be set to 0 and not 1.

So it should be:

bmi160@0 {



reg = <0>;
...
};

- k

On Feb 12, 2019, at 6:11 PM, Li, Jun R <jun.r.li@...> wrote:

Hi all,

I’m trying to add a sensor board to a STM32F4 discovery board for a prototype, i.e., adding a BMI160 sensor to the SPI1 bus. To do that, I’ve modified the file
“boards/arm/stm32f4_disco/stm32f4_disco.dts” and added the following section:

+
+&spi1 {
+ cs-gpios = <&gpiob 5 0>;
+ status = "ok";
+
+ bmi160@1 {
+ compatible = "bosch,bmi160";
+ reg = <0x1>;
+ label = "bmi160";
+ spi-max-frequency = <640000>;
+ int-gpios = <&gpioa 4 0>;
+ status = "ok";
+ };
+};

I used samples/hello_world to validate my changes. However, when I built “hello_world” by specifying the board to “stm32f4_disco”, I got the following errors:

cmake -DBOARD=stm32f4_disco ..
Zephyr version: 1.14.0
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3.4")
-- Selected BOARD stm32f4_disco
-- Loading /home/my/zephyr/boards/arm/stm32f4_disco/stm32f4_disco.dts as base
-- Overlaying /home/my/zephyr/dts/common/common.dts
Traceback (most recent call last):
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 542, in <module>
main()
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 524, in main
generate_node_definitions()
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 471, in generate_node_definitions
extract_node_include_info(reduced, k, k, None)
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 300, in extract_node_include_info
node_compat, sub_node_address, c, v, names)
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 219, in extract_property
reg.extract(node_address, names, def_label, 1)
File "/home/my/zephyr/scripts/dts/extract/reg.py", line 49, in extract
extract_controller(node_address, "cs-gpios", cs_gpios, reg[0], def_label, "cs-gpio", True)
File "/home/my/zephyr/scripts/dts/extract/globals.py", line 373, in extract_controller
prop_array = [prop_array[index]]
IndexError: list index out of range
CMake Error at /home/my/zephyr/cmake/dts.cmake:145 (message):
command failed with return code: 1
Call Stack (most recent call first):
/home/my/zephyr/cmake/app/boilerplate.cmake:401 (include)
CMakeLists.txt:3 (include)

-- Configuring incomplete, errors occurred!

If I comment either the line “cs-gpios = <&gpiob 5 0>;” or the section “bmi160@1 { ...}” above, the cmake configuration will succeed. But keeping both will get the above errors. I have no idea why it generated the parsing error. I saw the board dts definition file “boards/arc/arduino_101_sss/arduino_101_sss.dts” also did the same thing but it doesn’t get this kind of error.

Thank you!

Jun Li



BUGS (Zephyr v1.14.0-rc1) Feb 13 2019

Kumar Gala
 

268:bug

126:priority: low
105:priority: medium
8:priority: high

39:Coverity

39:area: Networking
15:area: Bluetooth
13:area: Kernel
12:nRF
11:area: Logging
11:area: Drivers
11:area: ARM
10:area: Xtensa
9:area: LWM2M
9:NXP
8:area: Samples
8:area: Documentation
8:ESP32
7:area: Shell
7:area: Memory Protection
5:area: USB
5:area: Sockets
5:area: Power Management
5:area: POSIX
5:MISRA-C
4:west
4:area: Watchdog
4:area: Toolchains
4:area: I2C
4:area: Device Tree
4:area: Counter
4:area: Build System
4:STM32
3:good first issue
3:area: UART
3:area: Timer
3:area: Security
3:area: PWM
3:area: NIOS2
3:API
2:net_conformance
2:area: Tests
2:area: Testing
2:area: Sensors
2:area: Sanitycheck
2:area: SPI
2:area: Portability
2:area: Other
2:area: GPIO
2:area: Flash
2:area: File System
2:area: C Library
2:area: Boards
2:area: ARC
2:EXT
1:to do
1:question
1:area: native port
1:area: mcumgr
1:area: X86
1:area: Testing Suite
1:area: Pinmux
1:area: PCI
1:area: OTA
1:area: IPC
1:area: Ethernet
1:area: Debugging
1:area: Crypto / RNG
1:area: Console
1:area: Configuration System
1:TSC
1:SiLabs
1:Security Review
1:RFC
1:OpenThread
1:LTS
1:ATMEL


i.MX 6/7 Flexcan driver Zephyr porting

Aymeric
 

Hi all,

I'm new to Zephyr's project, I tested some of the samples on a couples of boards.

For my project, I need a board on which Zephyr would support CAN & TCP/IP Stack.

I only found Zephyr CAN drivers for STM32 boards but they usually don't are equipped with Ethernet or at least are not supported.

So, my question is, is iMX 6/7 flexcan driver in a porting for Zephyr ?

My goal would be to use a NXP i.MX7 Colibri Board with a Evaluation Board, hardwarely, this board is CAN & Ethernet support.

My only other alternative would be to use a Stand-alone CAN controller but if I can avoid it, it would be nice.

Any advice would be appreciated.

Thanks,

Aymeric


Re: strange board DTS parsing error

Li, Jun R
 

Hah, it works after reg is changed to <0>. Thank you, Kumar!

By the way, what does "reg=<0>" mean for the sensor bmi160 here?

Regards,
Jun


On 2/12/19, 19:36, "Kumar Gala" <kumar.gala@...> wrote:

I’m guessing this is because the reg should be set to 0 and not 1.

So it should be:

bmi160@0 {



reg = <0>;
...
};

- k

On Feb 12, 2019, at 6:11 PM, Li, Jun R <jun.r.li@...> wrote:
>
> Hi all,
>
> I’m trying to add a sensor board to a STM32F4 discovery board for a prototype, i.e., adding a BMI160 sensor to the SPI1 bus. To do that, I’ve modified the file
> “boards/arm/stm32f4_disco/stm32f4_disco.dts” and added the following section:
>
> +
> +&spi1 {
> + cs-gpios = <&gpiob 5 0>;
> + status = "ok";
> +
> + bmi160@1 {
> + compatible = "bosch,bmi160";
> + reg = <0x1>;
> + label = "bmi160";
> + spi-max-frequency = <640000>;
> + int-gpios = <&gpioa 4 0>;
> + status = "ok";
> + };
> +};
>
> I used samples/hello_world to validate my changes. However, when I built “hello_world” by specifying the board to “stm32f4_disco”, I got the following errors:
>
> cmake -DBOARD=stm32f4_disco ..
> Zephyr version: 1.14.0
> -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3.4")
> -- Selected BOARD stm32f4_disco
> -- Loading /home/my/zephyr/boards/arm/stm32f4_disco/stm32f4_disco.dts as base
> -- Overlaying /home/my/zephyr/dts/common/common.dts
> Traceback (most recent call last):
> File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 542, in <module>
> main()
> File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 524, in main
> generate_node_definitions()
> File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 471, in generate_node_definitions
> extract_node_include_info(reduced, k, k, None)
> File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 300, in extract_node_include_info
> node_compat, sub_node_address, c, v, names)
> File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 219, in extract_property
> reg.extract(node_address, names, def_label, 1)
> File "/home/my/zephyr/scripts/dts/extract/reg.py", line 49, in extract
> extract_controller(node_address, "cs-gpios", cs_gpios, reg[0], def_label, "cs-gpio", True)
> File "/home/my/zephyr/scripts/dts/extract/globals.py", line 373, in extract_controller
> prop_array = [prop_array[index]]
> IndexError: list index out of range
> CMake Error at /home/my/zephyr/cmake/dts.cmake:145 (message):
> command failed with return code: 1
> Call Stack (most recent call first):
> /home/my/zephyr/cmake/app/boilerplate.cmake:401 (include)
> CMakeLists.txt:3 (include)
>
> -- Configuring incomplete, errors occurred!
>
> If I comment either the line “cs-gpios = <&gpiob 5 0>;” or the section “bmi160@1 { ...}” above, the cmake configuration will succeed. But keeping both will get the above errors. I have no idea why it generated the parsing error. I saw the board dts definition file “boards/arc/arduino_101_sss/arduino_101_sss.dts” also did the same thing but it doesn’t get this kind of error.
>
> Thank you!
>
> Jun Li
>
>


Re: strange board DTS parsing error

Kumar Gala
 

I’m guessing this is because the reg should be set to 0 and not 1.

So it should be:

bmi160@0 {



reg = <0>;
...
};

- k

On Feb 12, 2019, at 6:11 PM, Li, Jun R <jun.r.li@...> wrote:

Hi all,

I’m trying to add a sensor board to a STM32F4 discovery board for a prototype, i.e., adding a BMI160 sensor to the SPI1 bus. To do that, I’ve modified the file
“boards/arm/stm32f4_disco/stm32f4_disco.dts” and added the following section:

+
+&spi1 {
+ cs-gpios = <&gpiob 5 0>;
+ status = "ok";
+
+ bmi160@1 {
+ compatible = "bosch,bmi160";
+ reg = <0x1>;
+ label = "bmi160";
+ spi-max-frequency = <640000>;
+ int-gpios = <&gpioa 4 0>;
+ status = "ok";
+ };
+};

I used samples/hello_world to validate my changes. However, when I built “hello_world” by specifying the board to “stm32f4_disco”, I got the following errors:

cmake -DBOARD=stm32f4_disco ..
Zephyr version: 1.14.0
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3.4")
-- Selected BOARD stm32f4_disco
-- Loading /home/my/zephyr/boards/arm/stm32f4_disco/stm32f4_disco.dts as base
-- Overlaying /home/my/zephyr/dts/common/common.dts
Traceback (most recent call last):
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 542, in <module>
main()
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 524, in main
generate_node_definitions()
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 471, in generate_node_definitions
extract_node_include_info(reduced, k, k, None)
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 300, in extract_node_include_info
node_compat, sub_node_address, c, v, names)
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 219, in extract_property
reg.extract(node_address, names, def_label, 1)
File "/home/my/zephyr/scripts/dts/extract/reg.py", line 49, in extract
extract_controller(node_address, "cs-gpios", cs_gpios, reg[0], def_label, "cs-gpio", True)
File "/home/my/zephyr/scripts/dts/extract/globals.py", line 373, in extract_controller
prop_array = [prop_array[index]]
IndexError: list index out of range
CMake Error at /home/my/zephyr/cmake/dts.cmake:145 (message):
command failed with return code: 1
Call Stack (most recent call first):
/home/my/zephyr/cmake/app/boilerplate.cmake:401 (include)
CMakeLists.txt:3 (include)

-- Configuring incomplete, errors occurred!

If I comment either the line “cs-gpios = <&gpiob 5 0>;” or the section “bmi160@1 { ...}” above, the cmake configuration will succeed. But keeping both will get the above errors. I have no idea why it generated the parsing error. I saw the board dts definition file “boards/arc/arduino_101_sss/arduino_101_sss.dts” also did the same thing but it doesn’t get this kind of error.

Thank you!

Jun Li


strange board DTS parsing error

Li, Jun R
 

Hi all,

 

I’m trying to add a sensor board to a STM32F4 discovery board for a prototype, i.e.,  adding a BMI160 sensor to the SPI1 bus. To do that, I’ve modified the file

“boards/arm/stm32f4_disco/stm32f4_disco.dts” and added the following section:

 

+

+&spi1 {

+       cs-gpios = <&gpiob 5 0>;

+       status = "ok";

+

+       bmi160@1 {

+                compatible = "bosch,bmi160";

+                reg = <0x1>;

+                label = "bmi160";

+                spi-max-frequency = <640000>;

+                int-gpios = <&gpioa 4 0>;

+                status = "ok";

+        };

+};

 

I used samples/hello_world to validate my changes. However, when I built “hello_world” by specifying the board to “stm32f4_disco”, I got the following errors:

 

cmake -DBOARD=stm32f4_disco ..

Zephyr version: 1.14.0

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3.4")

-- Selected BOARD stm32f4_disco

-- Loading /home/my/zephyr/boards/arm/stm32f4_disco/stm32f4_disco.dts as base

-- Overlaying /home/my/zephyr/dts/common/common.dts

Traceback (most recent call last):

  File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 542, in <module>

    main()

  File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 524, in main

    generate_node_definitions()

  File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 471, in generate_node_definitions

    extract_node_include_info(reduced, k, k, None)

  File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 300, in extract_node_include_info

    node_compat, sub_node_address, c, v, names)

  File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 219, in extract_property

    reg.extract(node_address, names, def_label, 1)

  File "/home/my/zephyr/scripts/dts/extract/reg.py", line 49, in extract

    extract_controller(node_address, "cs-gpios", cs_gpios, reg[0], def_label, "cs-gpio", True)

  File "/home/my/zephyr/scripts/dts/extract/globals.py", line 373, in extract_controller

    prop_array = [prop_array[index]]

IndexError: list index out of range

CMake Error at /home/my/zephyr/cmake/dts.cmake:145 (message):

  command failed with return code: 1

Call Stack (most recent call first):

  /home/my/zephyr/cmake/app/boilerplate.cmake:401 (include)

  CMakeLists.txt:3 (include)

 

-- Configuring incomplete, errors occurred!

 

If I comment either the line “cs-gpios = <&gpiob 5 0>;” or the section “bmi160@1 { ...}” above, the cmake configuration will succeed. But keeping both will get the above errors. I have no idea why it generated the parsing error. I saw the board dts definition file “boards/arc/arduino_101_sss/arduino_101_sss.dts” also did the same thing but it doesn’t get this kind of error.

 

Thank you!

Jun Li

 


Re: ZEPHYR_TOOLCHAIN_VARIANT=host in docs? (Was: Zephyr SDK 0.10.0-rc2 available)

Marti Bolivar <marti@...>
 

On Mon, Feb 11, 2019 at 12:42 PM Marc Herbert <marc.herbert@...> wrote:



On 8 Feb 2019, at 08:28, Nashif, Anas <anas.nashif@...> wrote:

Do we make Zephyr 1.14 release with the stable 0.9.5 SDK?
No, Zephyr release is not tied to a toolchain. The SDK was always a one stop for everything you need to build and use zephyr, but you should be able to use any toolchain.
… including no “toolchain" in some cases thanks to ZEPHYR_TOOLCHAIN_VARIANT=host

I noticed ZEPHYR_TOOLCHAIN_VARIANT=host doesn’t seem mentioned in the documentation (I found it in the source). Would a one-liner in the "Getting Started" page be acceptable? I can submit.
I am responsible for this oversight in the documentation. If you
wouldn't mind sending a fix I would be happy to review it.

Thanks.

https://docs.zephyrproject.org/latest/getting_started/index.html?highlight=zephyr_toolchain_variant
https://docs.zephyrproject.org/latest/search.html?q=zephyr_toolchain_variant

Marc





Re: New development boards added to 1.14 #nrf52832 #nrf52840

Carles Cufi
 

Hi Ryan,

 

I will take a look at the PRs and add reviewers.

Feel free to join the TSC call tomorrow to raise awareness and discuss. The release manager for this release is Kumar Gala from  Linaro.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#technical-steering-committee-tsc

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Ryan Erickson
Sent: 12 February 2019 17:06
To: devel@...
Subject: [Zephyr-devel] New development boards added to 1.14 #nrf52832 #nrf52840

 

Hello,

I have 2 PRs open to add two new development boards to Zephyr. I would like to see if it is possible to get them added before v1.14 is released.
https://github.com/zephyrproject-rtos/zephyr/pull/13274
https://github.com/zephyrproject-rtos/zephyr/pull/13325

Each of these boards are VERY closely based on Nordic dev boards so it should be very low risk to get them added.
Who do I need to contact to try and get these PRs tagged for inclusion in 1.14?

Thanks,

Ryan


New development boards added to 1.14 #nrf52832 #nrf52840

Ryan Erickson
 

Hello,

I have 2 PRs open to add two new development boards to Zephyr. I would like to see if it is possible to get them added before v1.14 is released.
https://github.com/zephyrproject-rtos/zephyr/pull/13274
https://github.com/zephyrproject-rtos/zephyr/pull/13325

Each of these boards are VERY closely based on Nordic dev boards so it should be very low risk to get them added.
Who do I need to contact to try and get these PRs tagged for inclusion in 1.14?

Thanks,

Ryan


BUGS (Zephyr v1.14.0-rc1) Feb 12 2019

Kumar Gala
 

Some Bug details:

268:bug

124:priority: low
109:priority: medium
6:priority: high

42:Coverity

41:area: Networking
15:area: Bluetooth
14:area: Drivers
13:nRF
12:area: Kernel
11:area: Logging
10:area: Xtensa
10:area: ARM
8:area: Samples
8:area: Documentation
8:NXP
8:ESP32
7:area: Shell
6:area: Sockets
5:area: USB
5:area: UART
5:area: Power Management
5:area: POSIX
5:area: Memory Protection
5:MISRA-C
4:area: Toolchains
4:area: I2C
4:area: Device Tree
4:area: Counter
4:area: Build System
3:west
3:net_conformance
3:good first issue
3:area: Watchdog
3:area: Timer
3:area: Security
3:area: PWM
3:area: NIOS2
3:area: GPIO
3:STM32
3:API
2:area: Tests
2:area: Testing
2:area: Sensors
2:area: SPI
2:area: Portability
2:area: Other
2:area: File System
2:area: C Library
2:area: Boards
2:area: ARC
2:EXT
1:to do
1:question
1:area: native port
1:area: mcumgr
1:area: X86
1:area: Testing Suite
1:area: Sanitycheck
1:area: Pinmux
1:area: PCI
1:area: OTA
1:area: LWM2M
1:area: IPC
1:area: Flash
1:area: Ethernet
1:area: Debugging
1:area: Crypto / RNG
1:area: Console
1:area: Configuration System
1:TSC
1:SiLabs
1:Security Review
1:RFC
1:OpenThread
1:LTS
1:ATMEL


Re: CMake comments to HTML? (PR #9947 CMake build architecture documentation)

Marc Herbert
 

Thanks Anas!

 

Correct no PR yet, sorry for the confusion. This is still at the early prototype stage however there's already a demo git commit - the one that produced the screenshot - linked from https://github.com/zephyrproject-rtos/zephyr/issues/9947 and it should work "out of the box" on Linux. Ideas, suggestions and any other kind of feedback from anyone somewhat familiar with CMake or Sphinx and brave enough to review a few TODOs, FIXMEs and other question marks would be great already, thanks in advance. Github supports commenting on volatile commits for implementation details but higher level discussions are probably best "centralized" in an issue: 9947 or some (new?) other?

 

Cheers,

 

Marc

 

 

From: "Nashif, Anas" <anas.nashif@...>
Date: Monday, 11 February 2019 at 16:50
To: Marc Herbert <marc.herbert@...>, "devel@..." <devel@...>
Cc: "Kinder, David B" <david.b.kinder@...>
Subject: RE: CMake comments to HTML? (PR #9947 CMake build architecture documentation)

 

I think this looks great.

 

9947 is not a PR, it is an enhancement issue, got me confused for a second. So it is an open enhancement issue with not PR associated with it, if you have something , send a PR please.

 

Anas

 

From: devel@... [mailto:devel@...] On Behalf Of Marc Herbert
Sent: Monday, February 11, 2019 7:45 PM
To: devel@...
Cc: Kinder, David B <david.b.kinder@...>
Subject: [Zephyr-devel] CMake comments to HTML? (PR #9947 CMake build architecture documentation)

 

I tried the “moderncmakedomain” sphinx extension to prototype extracting CMake comments into html and it seems to work, see screenshot and PR below.

 

 

Dave (cc:) seems to like it.

 

Just a quick hack for now, Linux only. Two questions:

- Is the approach generally acceptable? Notably: is sphinx-moderncmakedomain acceptable as an additional pip3 requirement?

- If yes then is Sebastian's PR #9947 the correct place for this? I asked him privately but he’s either off or busy. If yes then let’s discuss there and not on the mailing-list.

 

 

Cheers,

 

Marc

 




Begin forwarded message:

 

Subject: Re: [zephyrproject-rtos/zephyr] CMake build architecture documentation (#9947)

Date: 11 February 2019 at 16:21:45 GMT-8

 

 

This is what the above commit produces:


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

 


Re: CMake comments to HTML? (PR #9947 CMake build architecture documentation)

Nashif, Anas
 

I think this looks great.

 

9947 is not a PR, it is an enhancement issue, got me confused for a second. So it is an open enhancement issue with not PR associated with it, if you have something , send a PR please.

 

Anas

 

From: devel@... [mailto:devel@...] On Behalf Of Marc Herbert
Sent: Monday, February 11, 2019 7:45 PM
To: devel@...
Cc: Kinder, David B <david.b.kinder@...>
Subject: [Zephyr-devel] CMake comments to HTML? (PR #9947 CMake build architecture documentation)

 

I tried the “moderncmakedomain” sphinx extension to prototype extracting CMake comments into html and it seems to work, see screenshot and PR below.

 

 

Dave (cc:) seems to like it.

 

Just a quick hack for now, Linux only. Two questions:

- Is the approach generally acceptable? Notably: is sphinx-moderncmakedomain acceptable as an additional pip3 requirement?

- If yes then is Sebastian's PR #9947 the correct place for this? I asked him privately but he’s either off or busy. If yes then let’s discuss there and not on the mailing-list.

 

 

Cheers,

 

Marc

 



Begin forwarded message:

 

Subject: Re: [zephyrproject-rtos/zephyr] CMake build architecture documentation (#9947)

Date: 11 February 2019 at 16:21:45 GMT-8

 

 

This is what the above commit produces:


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

 


CMake comments to HTML? (PR #9947 CMake build architecture documentation)

Marc Herbert
 

I tried the “moderncmakedomain” sphinx extension to prototype extracting CMake comments into html and it seems to work, see screenshot and PR below.


Dave (cc:) seems to like it.

Just a quick hack for now, Linux only. Two questions:
- Is the approach generally acceptable? Notably: is sphinx-moderncmakedomain acceptable as an additional pip3 requirement?
- If yes then is Sebastian's PR #9947 the correct place for this? I asked him privately but he’s either off or busy. If yes then let’s discuss there and not on the mailing-list.


Cheers,

Marc


Begin forwarded message:

Subject: Re: [zephyrproject-rtos/zephyr] CMake build architecture documentation (#9947)
Date: 11 February 2019 at 16:21:45 GMT-8


This is what the above commit produces:


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.



BUGS (Zephyr v1.14.0-rc1) Feb 11 2019

Kumar Gala
 

All,

Wanted to provide some bug stats so we can hopefully drive the total number of bugs down to single digits for the LTS release:

Some Bug details:

265:bug

125:priority: low
112:priority: medium
5:priority: high

43:Coverity

41:area: Networking
14:area: Drivers
14:area: Bluetooth
12:area: Logging
11:area: Kernel
10:nRF
10:area: Xtensa
10:area: ARM
9:NXP
8:area: Samples
8:area: Documentation
6:area: Sockets
6:area: Shell
6:ESP32
5:area: Power Management
5:area: POSIX
5:area: Memory Protection
5:MISRA-C
4:area: USB
4:area: UART
4:area: Toolchains
4:area: NIOS2
4:area: I2C
4:area: Device Tree
4:area: Build System
3:west
3:net_conformance
3:good first issue
3:area: Timer
3:area: Security
3:area: PWM
3:area: GPIO
3:area: Counter
3:STM32
3:API
2:area: Tests
2:area: Testing
2:area: Sensors
2:area: SPI
2:area: Portability
2:area: Other
2:area: File System
2:area: C Library
2:area: Boards
2:area: ARC
2:EXT
1:to do
1:question
1:area: native port
1:area: mcumgr
1:area: X86
1:area: Watchdog
1:area: Testing Suite
1:area: Sanitycheck
1:area: Pinmux
1:area: PCI
1:area: OTA
1:area: LWM2M
1:area: IPC
1:area: Flash
1:area: Ethernet
1:area: Debugging
1:area: Crypto / RNG
1:area: Console
1:area: Configuration System
1:TSC
1:SiLabs
1:Security Review
1:RFC
1:OpenThread
1:LTS

- k


ZEPHYR_TOOLCHAIN_VARIANT=host in docs? (Was: Zephyr SDK 0.10.0-rc2 available)

Marc Herbert
 

On 8 Feb 2019, at 08:28, Nashif, Anas <anas.nashif@...> wrote:

Do we make Zephyr 1.14 release with the stable 0.9.5 SDK?
No, Zephyr release is not tied to a toolchain. The SDK was always a one stop for everything you need to build and use zephyr, but you should be able to use any toolchain.
… including no “toolchain" in some cases thanks to ZEPHYR_TOOLCHAIN_VARIANT=host

I noticed ZEPHYR_TOOLCHAIN_VARIANT=host doesn’t seem mentioned in the documentation (I found it in the source). Would a one-liner in the "Getting Started" page be acceptable? I can submit.

https://docs.zephyrproject.org/latest/getting_started/index.html?highlight=zephyr_toolchain_variant
https://docs.zephyrproject.org/latest/search.html?q=zephyr_toolchain_variant

Marc


Zephyr v1.14.0-rc1 Tagged

Kumar Gala
 

Hi all,

We have just tagged Zephyr 1.14.0-rc1.

All required features that have not been pushed out to 1.14 are now merged, and so we begin the stabilization phase that should run for around 4 weeks this time. We will now start working on filling in the existing skeleton for the release notes, and closing PRs that need to come into the release. A reminder that, starting with -rc1, we will only accept changes introducing bug fixes, documentation and test cases. Any additional features or enhancements will need to be approved by the TSC.

As this release is meant as our first LTS we will be going through a longer stabilization phase to work on reducing our bug counts. Please focus on bugs during this period. If you submit a PR please ensure that it has the ‘v1.14.0’ Milestone set and either ’Bug’ or ’TSC’ label set on it.

The final release is tentatively scheduled for the 5th of April.

The full release log can be found here:
https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.14.0-rc1

Thanks to everybody who contributed to this release!

Kumar


How to encrypt advertise packet with zephyr and nrf52832 ? #ble #nrf52832

icephyr
 
Edited

Hi guys, I'd like to encrypt the advertise packet since some secure fields in the payload. But I did not find any clue yet.

So anybody knows how to implement this feature with zephyr? Thank a lot if you guys can help on this issue.