Date   

Zephyr Toolchain Working Group - Thu, 04/02/2020 #cal-notice

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Zephyr Toolchain Working Group

When:
Thursday, 2 April 2020
7:00am to 8:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/967549258

Description:
Zephyr Working Group is inviting you to a scheduled Zoom meeting.

 

Topic:  Zephyr Toolchain Working Group

Time: Mar 19, 2020 07:00 AM Pacific Time (US and Canada)

        Every 2 weeks on Thu, until Jul 23, 2020, 10 occurrence(s)

        Mar 19, 2020 07:00 AM

        Apr 2, 2020 07:00 AM

        Apr 16, 2020 07:00 AM

        Apr 30, 2020 07:00 AM

        May 14, 2020 07:00 AM

        May 28, 2020 07:00 AM

        Jun 11, 2020 07:00 AM

        Jun 25, 2020 07:00 AM

        Jul 9, 2020 07:00 AM

        Jul 23, 2020 07:00 AM

Please download and import the following iCalendar (.ics) files to your calendar system.

Weekly: https://zoom.us/meeting/tJIqcu2hrD4id0z59MlGQgtjfduqRH_iTA/ics?icsToken=98tyKuCuqT4uE9aQuF39e7cqA97lbN-1i3UesPYEsRPCMidHaAXyI_NwGo12JPmB

 

Join Zoom Meeting

https://zoom.us/j/967549258

 

Meeting ID: 967 549 258

 

One tap mobile

+16699006833,,967549258# US (San Jose)

+16465588656,,967549258# US (New York)

 

Dial by your location

        +1 669 900 6833 US (San Jose)

        +1 646 558 8656 US (New York)

        855 880 1246 US Toll-free

        877 369 0926 US Toll-free

        +1 647 558 0588 Canada

        855 703 8985 Canada Toll-free

Meeting ID: 967 549 258

Find your local number: https://zoom.us/u/abfRKTHWtN

 


Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r


Upcoming Event: Zephyr Toolchain Working Group - Thu, 04/02/2020 7:00am-8:00am #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Toolchain Working Group

When: Thursday, 2 April 2020, 7:00am to 8:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/967549258

View Event

Organizer: Maureen Helm

Description: Zephyr Working Group is inviting you to a scheduled Zoom meeting.

 

Topic:  Zephyr Toolchain Working Group

Time: Mar 19, 2020 07:00 AM Pacific Time (US and Canada)

        Every 2 weeks on Thu, until Jul 23, 2020, 10 occurrence(s)

        Mar 19, 2020 07:00 AM

        Apr 2, 2020 07:00 AM

        Apr 16, 2020 07:00 AM

        Apr 30, 2020 07:00 AM

        May 14, 2020 07:00 AM

        May 28, 2020 07:00 AM

        Jun 11, 2020 07:00 AM

        Jun 25, 2020 07:00 AM

        Jul 9, 2020 07:00 AM

        Jul 23, 2020 07:00 AM

Please download and import the following iCalendar (.ics) files to your calendar system.

Weekly: https://zoom.us/meeting/tJIqcu2hrD4id0z59MlGQgtjfduqRH_iTA/ics?icsToken=98tyKuCuqT4uE9aQuF39e7cqA97lbN-1i3UesPYEsRPCMidHaAXyI_NwGo12JPmB

 

Join Zoom Meeting

https://zoom.us/j/967549258

 

Meeting ID: 967 549 258

 

One tap mobile

+16699006833,,967549258# US (San Jose)

+16465588656,,967549258# US (New York)

 

Dial by your location

        +1 669 900 6833 US (San Jose)

        +1 646 558 8656 US (New York)

        855 880 1246 US Toll-free

        877 369 0926 US Toll-free

        +1 647 558 0588 Canada

        855 703 8985 Canada Toll-free

Meeting ID: 967 549 258

Find your local number: https://zoom.us/u/abfRKTHWtN

 


Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r


Dev-Review Meeting Agenda Apr 2

Kumar Gala
 

Here’s the agenda topics for this week:

* Review PR’s tagged with dev-review
* Driver Model???
* Use of DTS Alias v Chosen for device selection
* Any topics anyone else has

- k


Zephyr Toolchain Working Group Meeting – 2 April 2020

Rasmussen, Torsten
 

Hi,

 

For today’s meeting let’s follow up on last meeting action items and get a status update.

 

Where:
https://zoom.us/j/967549258

 

 

 

Agenda

  • Updates:
    • Wayne: PR22668: Anything new ?
    • Thomas: IAR: Get basic hello world compiling, (linking with GCC) : Status ?
    • Torsten: Toolchain abstraction: Issue:#16031, Status

 

  • AP: Last meeting:
    • Clean-up offset.h to make it easier to support more compilers
    • Exploration work on CI Toolchain test cases: Wayne
    • Everyone: Give feedback on PR#22688, and issue: #5517: Status ?
    • Toolchain abstraction: Issue:#16031, look at current work, and explore possibilities of improvements: Torsten.

 

  • Short term goals, way forward
    • Dedicated toolchain test cases.
      •  
    • Label PR for automatic execution of CI Toolchain test cases

 

          

 

Feel free to send a mail, if you would like additional topics to be discussed.

 

Best regards

 

Torsten T. Rasmussen           

 

Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

 

           

 

 


Upcoming Event: Zephyr Project: APIs - Tue, 03/31/2020 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 31 March 2020, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/177647878

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing


Re: hci_usb example compatible with native Windows 10 BLE stack? #hci

Carles Cufi
 

I see the same issue, I also suspect that Windows requires a dual-mode controller. See my comment here:

 

https://github.com/zephyrproject-rtos/zephyr/issues/23866#issuecomment-606690829

 

Carles

 

From: devel@... <devel@...> On Behalf Of Simon.Iversen via Lists.Zephyrproject.Org
Sent: 31 March 2020 15:16
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] hci_usb example compatible with native Windows 10 BLE stack? #hci

 

Has anyone tested the hci_usb sample with windows 10 and its native BLE stack?  On my end, it won't accept the controller. A reason might be that it lacks classic Bluetooth. can anyone confirm this, and why it doesn't work?

Best regards,
Simon


Re: hci_usb example compatible with native Windows 10 BLE stack? #hci

Lawrence King
 

Hi Simon:

 

Which revision of Zephyr are you using? On Zephyr v2.1.0 I had no problems, but with Zephyr 2.2.0 I am having problems. I have filed a bug for this: https://github.com/zephyrproject-rtos/zephyr/issues/23866

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: devel@... <devel@...> On Behalf Of Simon.Iversen@...
Sent: Tuesday, March 31, 2020 9:16 AM
To: devel@...
Subject: [Zephyr-devel] hci_usb example compatible with native Windows 10 BLE stack? #hci

 

Has anyone tested the hci_usb sample with windows 10 and its native BLE stack?  On my end, it won't accept the controller. A reason might be that it lacks classic Bluetooth. can anyone confirm this, and why it doesn't work?

Best regards,
Simon


API meeting: agenda

Carles Cufi
 

Hi all,

Note: Today we go back to our usual 9AM PDT / 18h CET.

Today's topics:

- Template to document a driver implementation: discussion as to what it should include

- API Terminology refinements
- PR https://github.com/zephyrproject-rtos/zephyr/pull/23867

- onoff service refactor conclusion
- PR https://github.com/zephyrproject-rtos/zephyr/pull/23601

- async notify service redesign conclusion
- PR https://github.com/zephyrproject-rtos/zephyr/pull/23898

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


hci_usb example compatible with native Windows 10 BLE stack? #hci

Simon.Iversen@...
 

Has anyone tested the hci_usb sample with windows 10 and its native BLE stack?  On my end, it won't accept the controller. A reason might be that it lacks classic Bluetooth. can anyone confirm this, and why it doesn't work?

Best regards,
Simon


Re: Development Issue on LPC55S69

Lawrence King
 

HI Vince,

 

There is no ‘official’ SPI specification, it is a defacto standard, and chip manufacturers can implement it any way they want. Generally most peripherals don’t care what level the data pin is at when the SSEL signal is not active. Your traces don’t show the SSEL signal but I would expect it is high except when transferring data.

 

If you look at the datasheet for the LPC55S69 https://www.nxp.com/docs/en/data-sheet/LPC55S6x.pdf on page 89 of 128 you can see the SPI timing diagram. As you can see the MOSI signal can be either high or low during the IDLE time. Hence, I would say that what you are seeing is exactly what is expected. Why did you expect MOSI to be at a fixed level between transactions?

 

 

If you really need MOSI to be high (or low) during the idle time then I suspect that you will need to modify the diver, and change the MOSI from SPI to GPIO at the end of the transaction and programmatically drive the GPIO high (or low).

 

I also found an interesting article about an NXP SPI interface and analysis of which state MOSI ended up in after each transaction. I suspect you can work out the rules for the LPC55S69 by trying the same experiments. https://michaeltien8901.github.io/stm32/2019/01/06/STM32F072-MOSI-Idle-State.html

 

Sorry I can’t help you with the other issues in this thread.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Vince Wu (吳家瑋) <Vince.Wu@...>
Sent: Tuesday, March 31, 2020 3:10 AM
To: Lawrence King <lawrence.king@...>; devel@...
Cc: Kevin Chu (
朱國偉) <Kevin.Chu@...>; Clone KL Liao (廖崑霳) <CloneKL.Liao@...>; Wu, Hubert <Hubert.Wu@...>
Subject: RE: [Zephyr-devel] Development Issue on LPC55S69

 

Hi Lawrence,

 

Sorry for unclear description.

What I mean is the voltage of MOSI signal in idle state doesn’t remain in high voltage.

For example, the following picture shows it begin from high voltage but end with low voltage.

However, I think the correct behavior is that MOSI should go back to high voltage after data transmission is finished.

 

Is this normal?

Thanks.

 

Best regards,

Vince

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Monday, March 30, 2020 9:30 PM
To: Vince Wu (
吳家瑋) <Vince.Wu@...>; devel@...
Cc: Kevin Chu (
朱國偉) <Kevin.Chu@...>; Clone KL Liao (廖崑霳) <CloneKL.Liao@...>; Wu, Hubert <Hubert.Wu@...>
Subject: RE: [Zephyr-devel] Development Issue on LPC55S69

 

Hi Vince:

 

2) I am not sure what you mean when you say “the voltage on the MOSI signal is unstable”. The Oscilloscope traces below look fine, however, the probes on your oscilloscope have not been properly compensated hence you see the ‘tilt’ on the signals instead of nice square waves. Take a look at this article to understand why and how to compensate your probes. https://www.circuitspecialists.com/blog/oscilloscope-probe-compensation-adjustment/

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: devel@... <devel@...> On Behalf Of Vince Wu (???)
Sent: Monday, March 30, 2020 12:46 AM
To: devel@...
Cc: Kevin Chu (
朱國偉) <Kevin.Chu@...>; Clone KL Liao (廖崑霳) <CloneKL.Liao@...>; Wu, Hubert <Hubert.Wu@...>
Subject: [Zephyr-devel] Development Issue on LPC55S69

 

Hi,

 

We have some issues on developing LPC55S69 based on Zephyr OS.

 

  1. EVB can’t run FW successfully if I do operation for double type variable.

I found the FW with this problem will link some more libraries as follows, maybe it cause the problem.

 

  1. The voltage of MOSI signal for SPI interface in idle state is unstable.

The following 4 situations happen:

  1. Start from high voltage and end with high voltage
  2. Start from high voltage and end with low voltage
  3. Start from low voltage and end with high voltage
  4. Start from low voltage and end with high voltage

For example:

 

  1. No counter driver.

If I open the counter drivers option in menuconfig, it will build fail.

  1. Bug in GPIO driver, gpio_mcux_lpc.c.

Original source will assign incorrect ISR for the assigned pin.

 

Please help to answer these problems, thanks.

 

Best regards,

 

Vince Wu

Project Lead

Moxa Connectivity Project Development

Fl. 4, No. 135, Lane 235, Baoqiao Rd.

Xindian Dist., New Taipei City, Taiwan, R.O.C.

Tel : +886-2-89191230 ext.1187

vince.wu@...

Moxa_Logo_2013.jpg
This email and any attached files may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this email. Any unauthorized duplication, utilization, disclosure, or distribution of the material in this email and its attached files is strictly forbidden.

 


Re: Development Issue on LPC55S69

Vince Wu (吳家瑋) <Vince.Wu@...>
 

Hi Lawrence,

 

Sorry for unclear description.

What I mean is the voltage of MOSI signal in idle state doesn’t remain in high voltage.

For example, the following picture shows it begin from high voltage but end with low voltage.

However, I think the correct behavior is that MOSI should go back to high voltage after data transmission is finished.

 

Is this normal?

Thanks.

 

Best regards,

Vince

 

From: Lawrence King [mailto:lawrence.king@...]
Sent: Monday, March 30, 2020 9:30 PM
To: Vince Wu (
吳家瑋) <Vince.Wu@...>; devel@...
Cc: Kevin Chu (
朱國偉) <Kevin.Chu@...>; Clone KL Liao (廖崑霳) <CloneKL.Liao@...>; Wu, Hubert <Hubert.Wu@...>
Subject: RE: [Zephyr-devel] Development Issue on LPC55S69

 

Hi Vince:

 

2) I am not sure what you mean when you say “the voltage on the MOSI signal is unstable”. The Oscilloscope traces below look fine, however, the probes on your oscilloscope have not been properly compensated hence you see the ‘tilt’ on the signals instead of nice square waves. Take a look at this article to understand why and how to compensate your probes. https://www.circuitspecialists.com/blog/oscilloscope-probe-compensation-adjustment/

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: devel@... <devel@...> On Behalf Of Vince Wu (???)
Sent: Monday, March 30, 2020 12:46 AM
To: devel@...
Cc: Kevin Chu (
朱國偉) <Kevin.Chu@...>; Clone KL Liao (廖崑霳) <CloneKL.Liao@...>; Wu, Hubert <Hubert.Wu@...>
Subject: [Zephyr-devel] Development Issue on LPC55S69

 

Hi,

 

We have some issues on developing LPC55S69 based on Zephyr OS.

 

1.      EVB can’t run FW successfully if I do operation for double type variable.

I found the FW with this problem will link some more libraries as follows, maybe it cause the problem.

 

2.      The voltage of MOSI signal for SPI interface in idle state is unstable.

The following 4 situations happen:

  1. Start from high voltage and end with high voltage
  2. Start from high voltage and end with low voltage
  3. Start from low voltage and end with high voltage
  4. Start from low voltage and end with high voltage

For example:

 

3.      No counter driver.

If I open the counter drivers option in menuconfig, it will build fail.

4.      Bug in GPIO driver, gpio_mcux_lpc.c.

Original source will assign incorrect ISR for the assigned pin.

 

Please help to answer these problems, thanks.

 

Best regards,

 

Vince Wu

Project Lead

Moxa Connectivity Project Development

Fl. 4, No. 135, Lane 235, Baoqiao Rd.

Xindian Dist., New Taipei City, Taiwan, R.O.C.

Tel : +886-2-89191230 ext.1187

vince.wu@...

Moxa_Logo_2013.jpg
This email and any attached files may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this email. Any unauthorized duplication, utilization, disclosure, or distribution of the material in this email and its attached files is strictly forbidden.

 


Re: [Zephyr-announce] Zephyr CMake package / find_package(Zephyr)

Carles Cufi
 

You need to be inside a zephyr tree (or pointing to it with ZEPHYR_BASE) that has #23054 merged in, so the latest upstream master will do. zephyr-export is implemented in the zephyr tree, not in west (i.e., it's an extension command).

-----Original Message-----
From: devel@... <devel@...> On
Behalf Of Kumar Gala via Lists.Zephyrproject.Org
Sent: 30 March 2020 16:19
To: Rasmussen, Torsten <Torsten.Rasmussen@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] [Zephyr-announce] Zephyr CMake package /
find_package(Zephyr)

What version of west has 'zephyr-export’??

[galak@spiff zephyr]$ west -V
West version: v0.7.2
[galak@spiff zephyr]$ west zephyr-export
usage: west [-h] [-z ZEPHYR_BASE] [-v] [-V] <command> ...
west: error: argument <command>: invalid choice: 'zephyr-export' (choose
from 'init', 'update', 'list', 'manifest', 'diff', 'status', 'forall',
'help', 'config', 'topdir', 'selfupdate', 'completion', 'boards',
'build', 'sign', 'flash', 'debug', 'debugserver', 'attach’)- k

- k

On Mar 30, 2020, at 8:31 AM, Rasmussen, Torsten
<Torsten.Rasmussen@...> wrote:

Hi All,

A new way of including boilerplate code has been introduced with this
PR https://github.com/zephyrproject-rtos/zephyr/pull/23054

This means a simple Zephyr application now looks as:
# Find Zephyr. This also loads Zephyr's build system.
cmake_minimum_required(VERSION 3.13.1) find_package(Zephyr HINTS
$ENV{ZEPHYR_BASE})
project(my_zephyr_app)

This means that developers no longer need to set ZEPHYR_BASE in their
environment, but can let CMake find the Zephyr base using
find_package().

For this to work, it is necessary to execute a new west command: `west
zephyr-export` This command only needs to be executed once, for
example after a `west init`

All samples in Zephyr repository has been updated to use:
find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

To all downstream user having own Zephyr-based applications, you may
switch to the new find_package() method.

Note: this new feature is fully compatible with the old
`include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake)` design, but
if you keep using the old design, then it is still required to `source
zephyr-env.sh` or execute `zephyr-env.cmd`.

Using the new `find_package()` remove the need to `source zephyr-
env.sh`.

It is still possible to set the environment variable ZEPHYR_BASE, and
doing so will overwrite the CMake package search functionality in
Zephyr.

For more information on the new desgin, re-read the getting started
guide (as the latest docs has not yet been build, this is a ):
https://docs.zephyrproject.org/latest/getting_started/index.html
https://docs.zephyrproject.org/latest/guides/zephyr_cmake_package.html


Best regards

Torsten



FW: Zephyr CMake package / find_package(Zephyr)

Carles Cufi
 

 

 

From: announce@... <announce@...> On Behalf Of Rasmussen, Torsten via Lists.Zephyrproject.Org
Sent: 30 March 2020 15:32
To: announce@...
Cc: announce@...
Subject: [Zephyr-announce] Zephyr CMake package / find_package(Zephyr)

 

Hi All,

 

A new way of including boilerplate code has been introduced with this PR https://github.com/zephyrproject-rtos/zephyr/pull/23054

 

This means a simple Zephyr application now looks as:

# Find Zephyr. This also loads Zephyr's build system.

cmake_minimum_required(VERSION 3.13.1)

find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

project(my_zephyr_app)

 

This means that developers no longer need to set ZEPHYR_BASE in their environment, but can let CMake find the Zephyr base using find_package().

 

For this to work, it is necessary to execute a new west command: `west zephyr-export`

This command only needs to be executed once, for example after a `west init`

 

All samples in Zephyr repository has been updated to use: find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

 

To all downstream user having own Zephyr-based applications, you may switch to the new find_package() method.

 

Note: this new feature is fully compatible with the old `include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake)` design,

but if you keep using the old design, then it is still required to `source zephyr-env.sh` or execute `zephyr-env.cmd`.

 

Using the new `find_package()` remove the need to `source zephyr-env.sh`.

 

It is still possible to set the environment variable ZEPHYR_BASE, and doing so will overwrite the CMake package search functionality in Zephyr.

 

For more information on the new desgin, re-read the getting started guide (as the latest docs has not yet been build, this is a ):

https://docs.zephyrproject.org/latest/getting_started/index.html

https://docs.zephyrproject.org/latest/guides/zephyr_cmake_package.html

 

 

Best regards

 

Torsten

 


Re: [Zephyr-announce] Zephyr CMake package / find_package(Zephyr)

Kumar Gala
 

What version of west has 'zephyr-export’??

[galak@spiff zephyr]$ west -V
West version: v0.7.2
[galak@spiff zephyr]$ west zephyr-export
usage: west [-h] [-z ZEPHYR_BASE] [-v] [-V] <command> ...
west: error: argument <command>: invalid choice: 'zephyr-export' (choose from 'init', 'update', 'list', 'manifest', 'diff', 'status', 'forall', 'help', 'config', 'topdir', 'selfupdate', 'completion', 'boards', 'build', 'sign', 'flash', 'debug', 'debugserver', 'attach’)- k

- k

On Mar 30, 2020, at 8:31 AM, Rasmussen, Torsten <Torsten.Rasmussen@...> wrote:

Hi All,

A new way of including boilerplate code has been introduced with this PR https://github.com/zephyrproject-rtos/zephyr/pull/23054

This means a simple Zephyr application now looks as:
# Find Zephyr. This also loads Zephyr's build system.
cmake_minimum_required(VERSION 3.13.1)
find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})
project(my_zephyr_app)

This means that developers no longer need to set ZEPHYR_BASE in their environment, but can let CMake find the Zephyr base using find_package().

For this to work, it is necessary to execute a new west command: `west zephyr-export`
This command only needs to be executed once, for example after a `west init`

All samples in Zephyr repository has been updated to use: find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

To all downstream user having own Zephyr-based applications, you may switch to the new find_package() method.

Note: this new feature is fully compatible with the old `include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake)` design,
but if you keep using the old design, then it is still required to `source zephyr-env.sh` or execute `zephyr-env.cmd`.

Using the new `find_package()` remove the need to `source zephyr-env.sh`.

It is still possible to set the environment variable ZEPHYR_BASE, and doing so will overwrite the CMake package search functionality in Zephyr.

For more information on the new desgin, re-read the getting started guide (as the latest docs has not yet been build, this is a ):
https://docs.zephyrproject.org/latest/getting_started/index.html
https://docs.zephyrproject.org/latest/guides/zephyr_cmake_package.html


Best regards

Torsten


Re: Development Issue on LPC55S69

Lawrence King
 

Hi Vince:

 

2) I am not sure what you mean when you say “the voltage on the MOSI signal is unstable”. The Oscilloscope traces below look fine, however, the probes on your oscilloscope have not been properly compensated hence you see the ‘tilt’ on the signals instead of nice square waves. Take a look at this article to understand why and how to compensate your probes. https://www.circuitspecialists.com/blog/oscilloscope-probe-compensation-adjustment/

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: devel@... <devel@...> On Behalf Of Vince Wu (???)
Sent: Monday, March 30, 2020 12:46 AM
To: devel@...
Cc: Kevin Chu (
朱國偉) <Kevin.Chu@...>; Clone KL Liao (廖崑霳) <CloneKL.Liao@...>; Wu, Hubert <Hubert.Wu@...>
Subject: [Zephyr-devel] Development Issue on LPC55S69

 

Hi,

 

We have some issues on developing LPC55S69 based on Zephyr OS.

 

  1. EVB can’t run FW successfully if I do operation for double type variable.

I found the FW with this problem will link some more libraries as follows, maybe it cause the problem.

 

  1. The voltage of MOSI signal for SPI interface in idle state is unstable.

The following 4 situations happen:

  1. Start from high voltage and end with high voltage
  2. Start from high voltage and end with low voltage
  3. Start from low voltage and end with high voltage
  4. Start from low voltage and end with high voltage

For example:

 

  1. No counter driver.

If I open the counter drivers option in menuconfig, it will build fail.

  1. Bug in GPIO driver, gpio_mcux_lpc.c.

Original source will assign incorrect ISR for the assigned pin.

 

Please help to answer these problems, thanks.

 

Best regards,

 

Vince Wu

Project Lead

Moxa Connectivity Project Development

Fl. 4, No. 135, Lane 235, Baoqiao Rd.

Xindian Dist., New Taipei City, Taiwan, R.O.C.

Tel : +886-2-89191230 ext.1187

vince.wu@...

Moxa_Logo_2013.jpg
This email and any attached files may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this email. Any unauthorized duplication, utilization, disclosure, or distribution of the material in this email and its attached files is strictly forbidden.

 


Development Issue on LPC55S69

Vince Wu (吳家瑋) <Vince.Wu@...>
 

Hi,

 

We have some issues on developing LPC55S69 based on Zephyr OS.

 

1.      EVB can’t run FW successfully if I do operation for double type variable.

I found the FW with this problem will link some more libraries as follows, maybe it cause the problem.

 

2.      The voltage of MOSI signal for SPI interface in idle state is unstable.

The following 4 situations happen:

1.      Start from high voltage and end with high voltage

2.      Start from high voltage and end with low voltage

3.      Start from low voltage and end with high voltage

4.      Start from low voltage and end with high voltage

For example:

 

3.      No counter driver.

If I open the counter drivers option in menuconfig, it will build fail.

4.      Bug in GPIO driver, gpio_mcux_lpc.c.

Original source will assign incorrect ISR for the assigned pin.

 

Please help to answer these problems, thanks.

 

Best regards,

 

Vince Wu

Project Lead

Moxa Connectivity Project Development

Fl. 4, No. 135, Lane 235, Baoqiao Rd.

Xindian Dist., New Taipei City, Taiwan, R.O.C.

Tel : +886-2-89191230 ext.1187

vince.wu@...

Moxa_Logo_2013.jpg
This email and any attached files may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this email. Any unauthorized duplication, utilization, disclosure, or distribution of the material in this email and its attached files is strictly forbidden.

 


Zephyr CMake package / find_package(Zephyr)

Rasmussen, Torsten
 

Hi All,

 

A new way of including boilerplate code has been introduced with this PR https://github.com/zephyrproject-rtos/zephyr/pull/23054

 

This means a simple Zephyr application now looks as:

# Find Zephyr. This also loads Zephyr's build system.

cmake_minimum_required(VERSION 3.13.1)

find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

project(my_zephyr_app)

 

This means that developers no longer need to set ZEPHYR_BASE in their environment, but can let CMake find the Zephyr base using find_package().

 

For this to work, it is necessary to execute a new west command: `west zephyr-export`

This command only needs to be executed once, for example after a `west init`

 

All samples in Zephyr repository has been updated to use: find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})

 

To all downstream user having own Zephyr-based applications, you may switch to the new find_package() method.

 

Note: this new feature is fully compatible with the old `include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake)` design,

but if you keep using the old design, then it is still required to `source zephyr-env.sh` or execute `zephyr-env.cmd`.

 

Using the new `find_package()` remove the need to `source zephyr-env.sh`.

 

It is still possible to set the environment variable ZEPHYR_BASE, and doing so will overwrite the CMake package search functionality in Zephyr.

 

For more information on the new desgin, re-read the getting started guide (as the latest docs has not yet been build, this is a ):

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/getting_started/index.rst

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/guides/zephyr_cmake_package.rst

 

(Still waiting for the docs to be rebuilt)

 

 

Best regards

 

Torsten

 

 


Re: Most BLE applications with nrf52 boards are broken on Version 2.1

Bolivar, Marti
 

The beacon sample builds for me at Zephyr v2.1.0 for nrf52_pc10040 with
Zephyr SDK 0.11.1.

Did you skip a 'west update' or need a --prisitine?

"Li, Jun R via Lists.Zephyrproject.Org"
<jun.r.li=intel.com@...> writes:

Hey,
I’ve tried to build a couple of BLE applications, like “beacon” , “peripheral_hr” with several nRF52 boards such as “nrf52_pca10040”, “nrf52840_pca10056” on the version 2.1. All building process is broken at the link stage with the following errors:

/opt/zephyr-sdk-0.10.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/../../../../arm-zephyr-eabi/bin/ld: subsys/bluetooth/host/libsubsys__bluetooth__host.a(hci_core.c.obj): in function `le_set_private_addr':
/home/uwb/projects/iid_device/zephyr/subsys/bluetooth/host/hci_core.c:581: undefined reference to `bt_rand'
/opt/zephyr-sdk-0.10.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/../../../../arm-zephyr-eabi/bin/ld: subsys/bluetooth/host/libsubsys__bluetooth__host.a(hci_core.c.obj): in function `create_random_addr':
/home/uwb/projects/iid_device/zephyr/subsys/bluetooth/host/hci_core.c:4658: undefined reference to `bt_rand'
collect2: error: ld returned 1 exit status
zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:104: recipe for target 'zephyr/zephyr_prebuilt.elf' failed
make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1
CMakeFiles/Makefile2:579: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

I’m not sure if the CI process still covers the tests for most applications.

Regards,
Jun

--



Most BLE applications with nrf52 boards are broken on Version 2.1

Li, Jun R
 

Hey,

I’ve tried to build a couple of BLE applications, like “beacon” , “peripheral_hr” with several nRF52 boards such as “nrf52_pca10040”, “nrf52840_pca10056” on the version 2.1. All building process is broken at the link stage with the following errors:

 

/opt/zephyr-sdk-0.10.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/../../../../arm-zephyr-eabi/bin/ld: subsys/bluetooth/host/libsubsys__bluetooth__host.a(hci_core.c.obj): in function `le_set_private_addr':

/home/uwb/projects/iid_device/zephyr/subsys/bluetooth/host/hci_core.c:581: undefined reference to `bt_rand'

/opt/zephyr-sdk-0.10.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/../../../../arm-zephyr-eabi/bin/ld: subsys/bluetooth/host/libsubsys__bluetooth__host.a(hci_core.c.obj): in function `create_random_addr':

/home/uwb/projects/iid_device/zephyr/subsys/bluetooth/host/hci_core.c:4658: undefined reference to `bt_rand'

collect2: error: ld returned 1 exit status

zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:104: recipe for target 'zephyr/zephyr_prebuilt.elf' failed

make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1

CMakeFiles/Makefile2:579: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed

make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2

Makefile:83: recipe for target 'all' failed

make: *** [all] Error 2

 

I’m not sure if the CI process still covers the tests for most applications.

 

Regards,

Jun

 

-- 

 


ZEBRA RFC source tree location #ble

deang@...
 

The ZEBRA RFC (see RFC: https://github.com/zephyrproject-rtos/zephyr/issues/23465) is a feature proposal for a simple way to add secure authentication between two Bluetooth devices.  ZEBRA is not part of the Bluetooth stack, it uses the Bluetooth stack via the firmware application to authenticate.   There are several places where the ZEBRA code could potentially resided within the Zephyr code base:


  1. As a sub directory of subsys.   subsys/auth
Good option.  The subsys directory contains key components of Zephyr.  While you can use Zephyr without a sub system, say networking, these components are often critical and used in an embedded system.  The subsys/auth subdirectory would contain ZEBRA and other authentication methods such as Google Fast Pair.   As security becomes more important to real time systems, it makes sense to make authentication a key component of Zephyr.  A subsys/auth would also enable code sharing between different authentication methods.


2.  As a sub directory lib.   lib/auth
Good option.  The lib directory contains various libraries, ZEBRA can is essentially a library sitting on top of the Bluetooth stack providing authentication services.  Other authentication methods would be separate libraries. 


Looking for suggestions and comments on which option would work the best. 

I personally prefer option #1.  

Thanks,

Dean Gereaux