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

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

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

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/

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

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.

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/

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

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.

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Kumar Gala via Lists.Zephyrproject.Org
Sent: 30 March 2020 16:19
To: Rasmussen, Torsten <Torsten.Rasmussen@nordicsemi.no>
Cc: devel@lists.zephyrproject.org
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@nordicsemi.no> 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

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

On Mar 30, 2020, at 8:31 AM, Rasmussen, Torsten <Torsten.Rasmussen@nordicsemi.no> 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

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

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.