1. devel@lists.zephyrproject.org
   Date   
Re: warning: TEST_RANDOM_GENERATOR

alpi@...
 

Hi,
The native_posix board does not use the Bluetooth simulator.
Its random generator is deterministic, but can be seeded ( --seed=<random_seed>) to enable reproducible tests(*1).

The nrf52_bsim board (*2) does use the Bluetooth simulator (BabbleSim, a.k.a. bsim (*3)), and has another random generator (a model of the nRF5x RNG HW) which is also deterministic and can be seeded.

What these 2 Zephyr targets have in common is that both are based on the POSIX architecture. So the result of building targeting these boards is actually a native executable for the host computer, which the developer can run and debug like a normal Linux program.
Apart from this, the nrf52_bsim RADIO HW models, use the BabbleSim physical layer simulator to simulate the radio activity, and communicate with other simulated devices.

1 https://docs.zephyrproject.org/latest/boards/posix/native_posix/doc/board.html#peripherals
2 https://docs.zephyrproject.org/latest/boards/posix/nrf52_bsim/doc/board.html
3 https://babblesim.github.io

BR
Alberto

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Wednesday 30 January 2019 08:22
To: Alberto Escolar Piedras (ALPI) <ALPI@oticon.com>; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] warning: TEST_RANDOM_GENERATOR

Hello Alberto,

On Wed, 30 Jan 2019 07:15:41 +0000
"Alberto Escolar Piedras (ALPI)" <ALPI@oticon.com> wrote:

Regarding "predictable random number generator", that's interesting
idea for some kinds of testing, but I'm personally not aware of us
using such advanced and cunning test methods in Zephyr.
That's the native posix one ;)
D'oh, I stand corrected. Now I remember it, Bluetooth simulation support, right?

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Re: warning: TEST_RANDOM_GENERATOR

Paul Sokolovsky
 

Hello Alberto,

On Wed, 30 Jan 2019 07:15:41 +0000
"Alberto Escolar Piedras (ALPI)" <ALPI@oticon.com> wrote:

Regarding "predictable random number generator", that's interesting
idea for some kinds of testing, but I'm personally not aware of us
using such advanced and cunning test methods in Zephyr.
That's the native posix one ;)
D'oh, I stand corrected. Now I remember it, Bluetooth simulation
support, right?

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Code Freeze for 1.14 on Friday Feb 1st

Kumar Gala
 

All,

Just wanted to remind everyone that the code freeze for 1.14 will be this Friday. Please tag any PR as with 1.14 milestone that you feel should try and get merged as part of 1.14.

Thanks

- k
Re: warning: TEST_RANDOM_GENERATOR

Paul Sokolovsky
 

Hello Andrei,

On Tue, 29 Jan 2019 13:35:19 +0000
"Andrei Gansari" <andrei.gansari@nxp.com> wrote:

Hello everyone,

I have a question regarding TEST_RANDOM_GENERATOR.
When building networking samples for boards with entropy devices is
get the warning: warning: TEST_RANDOM_GENERATOR (defined at
subsys/random/Kconfig:8) was assigned the value 'y' but got the value
'n'.

We find in subsys/random/Kconfig
TEST_RANDOM_GENERATOR depends on !ENTROPY_HAS_DRIVER
ENTROPY_DEVICE_RANDOM_GENERATOR depends on ENTROPY_HAS_DRIVER

Most networking samples have set TEST_RANDOM_GENERATOR=y and as I
understand it's for pseudo-random number generation. Boards that have
entropy devices (ENTROPY_HAS_DRIVER) will disable
TEST_RANDOM_GENERATOR.

When setting TEST_RANDOM_GENERATOR we just want a random generator or
we want a predictable/intuitive random number generator?
We want to have a "random generator" device be present in Zephyr
setup, which various subsystems then can use (instead of failing). So,
TEST_RANDOM_GENERATOR is a fallback choice which is always available.
For example, it's available in qemu_* boards, which otherwise don't
have a "real" randomgen. That's why you see TEST_RANDOM_GENERATOR in
many networking samples - the only way to make networking samples
accessing to *anyone* is to make sure they run with qemu networking.

Regarding "predictable random number generator", that's interesting
idea for some kinds of testing, but I'm personally not aware of us
using such advanced and cunning test methods in Zephyr.

If we want
both type of generators, then we could remove ENTROPY_HAS_DRIVER
check on TEST_RANDOM_GENERATOR?

Is this an issue?


Andrei G.
[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
warning: TEST_RANDOM_GENERATOR

Andrei Gansari
 

Hello everyone,

 

I have a question regarding TEST_RANDOM_GENERATOR.

When building networking samples for boards with entropy devices is get the warning:

warning: TEST_RANDOM_GENERATOR (defined at subsys/random/Kconfig:8) was assigned the value 'y' but got the value 'n'.

 

We find in subsys/random/Kconfig

TEST_RANDOM_GENERATOR depends on !ENTROPY_HAS_DRIVER

ENTROPY_DEVICE_RANDOM_GENERATOR depends on ENTROPY_HAS_DRIVER

 

Most networking samples have set TEST_RANDOM_GENERATOR=y and as I understand it's for pseudo-random number generation. Boards that have entropy devices (ENTROPY_HAS_DRIVER) will disable TEST_RANDOM_GENERATOR.

 

When setting TEST_RANDOM_GENERATOR we just want a random generator or we want a predictable/intuitive random number generator?

If we want both type of generators, then we could remove ENTROPY_HAS_DRIVER check on TEST_RANDOM_GENERATOR?

 

Is this an issue?

 

 

Andrei G.
More datails about HAL architecture

Francesco Franchina <cescus92@...>
 

Hello everyone!

I'm new to Zephyr and I'm considering to use it to build my next wearable project that will be based on the nRF5 SoC.

Having studied a bit the architecture of features of the project it seems a pretty good choice to me but I still have a doubt that I could not solve reading the documentation and looking around in the web.

I've read about the policy of adopting the HALs of different vendors but I didn't understand:
1) Are there some development policies that ensure that they will not interfere with my code? (e.g. do they mess with interrupts, registers or tasks?)
2) Do they behave consistently across all the supported board or I should expect some slightly different behaviors?

Thanks in advance for your time!

Francesco
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool

Carles Cufi
 

Hi Luiz,

-----Original Message-----
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Sent: 29 January 2019 12:25
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>
Cc: Jamie Mccrae <Jamie.Mccrae@lairdtech.com>; zephyr-devel <zephyr-
devel@lists.zephyrproject.org>; zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] [Zephyr-users] Introducing west, Zephyr's
meta-tool

Hi Carles,
On Tue, Jan 29, 2019 at 11:40 AM Cufi, Carles
<Carles.Cufi@nordicsemi.no> wrote:

Hi Jamie, Luiz,

-----Original Message-----
From: Jamie Mccrae <Jamie.Mccrae@lairdtech.com>
Sent: 29 January 2019 10:35
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>; Cufi, Carles
<Carles.Cufi@nordicsemi.no>
Cc: zephyr-devel <zephyr-devel@lists.zephyrproject.org>; zephyr-
users@lists.zephyrproject.org
Subject: RE: [Zephyr-devel] [Zephyr-users] Introducing west,
Zephyr's meta-tool

Hi Carles,
Note that we have not at any point considered moving away from
GitHub. The plan is to adapt to what the service offers and try to
find a solution that works well with it. This is also one of the
reasons we are first introducing west without actually splitting the
ext/ folder into multiple external repos: we want to expose users to
west before we start doing more radical changes.

Well good, though Im not sure what problem does west solves then?
For pulling it sounds like submodules is the preferable solution
(to linux folks at least):
https://public-inbox.org/git/338901fc-6dc8-2684-c116-393e603f85e9@
suse
.de/t/
I agree with Luiz here, what does west provide that submodules
doesn't provide? Why do I and others now need yet another piece of
software to build Zephyr code (python)?
There are a number of reasons why we don't use Git submodules, all of
which are described in the GitHub issue describing multi-repo:
https://github.com/zephyrproject-rtos/zephyr/issues/6770
Well I didn't have to go as far since someone already commented similar
thing:

https://github.com/zephyrproject-rtos/zephyr/issues/6770#issuecomment-
445496706

So attached vs detached approach, there seems to be quite many on the
camp that we need to have the repositories attached while some
considered the detached approach a must have. As individual contributor
I think using the attached approach is a must, specially if one wants to
actually run sanity checks which sometimes is necessary e.g. when you
are actually writing a test case which depends on a feature from a
different repository.
If by "attached" you mean that projects in the manifest are locked at a particular SHA, then that is exactly what we will do upstream (https://github.com/zephyrproject-rtos/zephyr/blob/master/west.yml#L37). That is not to say that some downstreams may choose to free float on the tip of a branch, but this is *not* going to be the case for upstream Zephyr. I will edit the body of the issue to make that clear.

Regards,

Carles
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool

Luiz Augusto von Dentz
 

Hi Carles,
On Tue, Jan 29, 2019 at 11:40 AM Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Jamie, Luiz,

-----Original Message-----
From: Jamie Mccrae <Jamie.Mccrae@lairdtech.com>
Sent: 29 January 2019 10:35
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>; Cufi, Carles
<Carles.Cufi@nordicsemi.no>
Cc: zephyr-devel <zephyr-devel@lists.zephyrproject.org>; zephyr-
users@lists.zephyrproject.org
Subject: RE: [Zephyr-devel] [Zephyr-users] Introducing west, Zephyr's
meta-tool

Hi Carles,
Note that we have not at any point considered moving away from
GitHub. The plan is to adapt to what the service offers and try to find
a solution that works well with it. This is also one of the reasons we
are first introducing west without actually splitting the ext/ folder
into multiple external repos: we want to expose users to west before we
start doing more radical changes.

Well good, though Im not sure what problem does west solves then? For
pulling it sounds like submodules is the preferable solution (to linux
folks at least):
https://public-inbox.org/git/338901fc-6dc8-2684-c116-393e603f85e9@suse
.de/t/
I agree with Luiz here, what does west provide that submodules doesn't
provide? Why do I and others now need yet another piece of software to
build Zephyr code (python)?
There are a number of reasons why we don't use Git submodules, all of which are described in the GitHub issue describing multi-repo:
https://github.com/zephyrproject-rtos/zephyr/issues/6770
Well I didn't have to go as far since someone already commented similar thing:

https://github.com/zephyrproject-rtos/zephyr/issues/6770#issuecomment-445496706

So attached vs detached approach, there seems to be quite many on the
camp that we need to have the repositories attached while some
considered the detached approach a must have. As individual
contributor I think using the attached approach is a must, specially
if one wants to actually run sanity checks which sometimes is
necessary e.g. when you are actually writing a test case which depends
on a feature from a different repository.

I encourage you to read through the (admittedly quite long) list of comments there and continue the conversation.

Regards,

Carles

--
Luiz Augusto von Dentz
Re: Introducing west, Zephyr's meta-tool

Carles Cufi
 

Hi all,

West is now merged to master.

The documentation build has completed but the new set of documents have not yet been published to docs.zephyrproject.org. As soon as those are updated online (should take a few hours) you can refer to:

https://docs.zephyrproject.org/latest/getting_started/getting_started.html
and
https://docs.zephyrproject.org/latest/tools/west/index.html

for the west documentation.

Thanks to everybody who has contributed or given feedback so far!

Regards,

Carles

-----Original Message-----
From: Cufi, Carles
Sent: 28 January 2019 09:43
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>; zephyr-
users@lists.zephyrproject.org
Subject: Introducing west, Zephyr's meta-tool

Hi all,

For a few months now we have been working on a meta-tool named west,
designed to act both as a command-line tool to build, flash an debug
Zephyr-based applications and also to manage the additional Git
repositories that Zephyr will require in order to build in the near
future.

West is written in Python 3, lives in its own repository [1] and its
bootstrapper is available on PyPi [2].
As soon as we merge the topic-west [3] branch into master (which should
happen in the next few days) you will need to install west in order to
flash and debug, since those commands will rely on havig west present as
part of your Zephyr workflow.

The updated west documentation will be online in the Zephyr
documentation website [4] as soon as the topic-west branch is merged
into master. In the meantime you can also look at the unrendered
documentation sources in the topic-west branch [5] and the existing
GitHub issues [6][7].

In order to install the west boostrapper (which you can do today) run:

# On Linux
pip3 install --user west

# On macOS and Windows
pip3 install west

Once the west bootstrapper is installed and the topic-west branch is
merged into master, you will have 2 choices to get a west main
installation.

1. Clone a new copy of the zephyr repository using west:

west init zephyrproject
cd zephyrproject
west update

2. Install west around an existing local zephyr clone:

Move the cloned zephyr/ repository to an empty enclosing folder (for
example zephyrproject/zephyr/), and from this enclosing folder
zephyrproject/ run:

west init -l zephyr/
west update
The -l <path to zephyr> parameter instructs west to use an existing
local copy instead of cloning a remote repository.

Feedback and patches are welcome, but note that the feature will likely
be merged as-is since we consider we have left ample time to raise any
major issues regarding the workflow and decisions taken during the
development of west. This is however only the beginning of west's
(hopefully) long existence as the Zephyr command-line meta-tool, and it
will certainly evolve and change considerably in the future with the
help of the community.

Please submit feedback in the form of GitHub issues on the west
repository itself [1] unless it affects features or functionality in the
zephyr repository directly.

I will reply to this email once the topic-west branch is merged into
master.

Thank you to everybody who has contributed so far!

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/west
[2] https://pypi.org/project/west/
[3] https://github.com/zephyrproject-rtos/zephyr/tree/topic-west
[4] https://docs.zephyrproject.org/latest/tools/west/index.html
[5] https://github.com/zephyrproject-rtos/zephyr/tree/topic-
west/doc/tools/west
[6] https://github.com/zephyrproject-rtos/zephyr/issues/6205
[7] https://github.com/zephyrproject-rtos/zephyr/issues/6770
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool

Carles Cufi
 

Hi Jamie, Luiz,

-----Original Message-----
From: Jamie Mccrae <Jamie.Mccrae@lairdtech.com>
Sent: 29 January 2019 10:35
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>; Cufi, Carles
<Carles.Cufi@nordicsemi.no>
Cc: zephyr-devel <zephyr-devel@lists.zephyrproject.org>; zephyr-
users@lists.zephyrproject.org
Subject: RE: [Zephyr-devel] [Zephyr-users] Introducing west, Zephyr's
meta-tool

Hi Carles,
Note that we have not at any point considered moving away from
GitHub. The plan is to adapt to what the service offers and try to find
a solution that works well with it. This is also one of the reasons we
are first introducing west without actually splitting the ext/ folder
into multiple external repos: we want to expose users to west before we
start doing more radical changes.

Well good, though Im not sure what problem does west solves then? For
pulling it sounds like submodules is the preferable solution (to linux
folks at least):
https://public-inbox.org/git/338901fc-6dc8-2684-c116-393e603f85e9@suse
.de/t/
I agree with Luiz here, what does west provide that submodules doesn't
provide? Why do I and others now need yet another piece of software to
build Zephyr code (python)?
There are a number of reasons why we don't use Git submodules, all of which are described in the GitHub issue describing multi-repo:
https://github.com/zephyrproject-rtos/zephyr/issues/6770

I encourage you to read through the (admittedly quite long) list of comments there and continue the conversation.

Regards,

Carles
USB audio #nrf52840

marcus
 

Hi,

I am wondering about any plans regarding USB audio and isochronous endpoints.
See github issue: https://github.com/zephyrproject-rtos/zephyr/issues/12775
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool

lairdjm
 

Hi Carles,
Note that we have not at any point considered moving away from GitHub. The plan is to adapt to what the service offers and try to find a solution that works well with it. This is also one of the reasons we are first introducing west without actually splitting the ext/ folder into multiple external repos: we want to expose users to west before we start doing more radical changes.
Well good, though Im not sure what problem does west solves then? For
pulling it sounds like submodules is the preferable solution (to linux
folks at least):
https://public-inbox.org/git/338901fc-6dc8-2684-c116-393e603f85e9@suse.de/t/
I agree with Luiz here, what does west provide that submodules doesn't provide? Why do I and others now need yet another piece of software to build Zephyr code (python)?
Thanks,
Jamie
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool

Luiz Augusto von Dentz
 

Hi Carles,

On Mon, Jan 28, 2019 at 10:54 PM Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Luiz,

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Luiz Augusto von Dentz
Sent: 28 January 2019 21:00
Subject: Re: [Zephyr-devel] [Zephyr-users] Introducing west, Zephyr's
meta-tool

Hi Carles,

How about pull request, how does west deals with them? Or it doesn't and
which case we have to deal with individual git repositories and issue
git push ourselves? This looks like repo which I never liked.
You can see that dealing with Pull Requests is listed as an unresolved issue in the description here:
https://github.com/zephyrproject-rtos/zephyr/issues/6770

There are several possibilities to deal with this, but first and since that you mention Google repo let me make an important distinction. With repo you typically (though not always) track the tip of master on multiple repositories. With west, although that is also possible, we will require specific SHAs for all repos (projects) that are not the main zephyr repo (i.e. the manifest repo).

Options we have (informally, in calls and chats) considered:
1. Send 2 PRs to the 2 repos affected (say for example zephyr + mbedtls), where the branch name used matches. Then CI running in zephyr could look at all repositories listed in the manifest and check if an outstanding PR for it exists with the same GitHub username and branch name.
2. Send the PR to the external project (mbedtls in our example) and another PR to zephyr with the manifest modified so that it points to the fork and branch name of the project's PR. When those are merged, CI could then replace the contents of the manifest with the proper SHA.
3. Introduce some sort of per-PR ChangeId that CI knows how to parse.
4. GitHub adds support for cross-repository PRs. There have been multiple hints that this is coming, but obviously we cannot know when, if ever, this feature will be available.
From these alternatives I only see 4 really working in practice, but
it is limited to repositories being in github in which case the PR
requests can perhaps be generated from a single clone and github could
then forward to each individual project but still tracking on the
original. For other options even if west learn how to properly
separate each PR the user still needs its own repository for each of
those if they are hosted in github which would have to be tracked
individually, or in case it is not hosted in github it may have to
deal with mailing list, gerrit, etc.

Note that we have not at any point considered moving away from GitHub. The plan is to adapt to what the service offers and try to find a solution that works well with it. This is also one of the reasons we are first introducing west without actually splitting the ext/ folder into multiple external repos: we want to expose users to west before we start doing more radical changes.
Well good, though Im not sure what problem does west solves then? For
pulling it sounds like submodules is the preferable solution (to linux
folks at least):

https://public-inbox.org/git/338901fc-6dc8-2684-c116-393e603f85e9@suse.de/t/

Ideas and feedback welcome!

Thanks,

Carles


On Mon, Jan 28, 2019 at 10:43 AM Cufi, Carles
<carles.cufi@nordicsemi.no> wrote:

Hi all,

For a few months now we have been working on a meta-tool named west,
designed to act both as a command-line tool to build, flash an debug
Zephyr-based applications and also to manage the additional Git
repositories that Zephyr will require in order to build in the near
future.

West is written in Python 3, lives in its own repository [1] and its
bootstrapper is available on PyPi [2].
As soon as we merge the topic-west [3] branch into master (which
should happen in the next few days) you will need to install west in
order to flash and debug, since those commands will rely on havig west
present as part of your Zephyr workflow.

The updated west documentation will be online in the Zephyr
documentation website [4] as soon as the topic-west branch is merged
into master. In the meantime you can also look at the unrendered
documentation sources in the topic-west branch [5] and the existing
GitHub issues [6][7].

In order to install the west boostrapper (which you can do today) run:

# On Linux
pip3 install --user west

# On macOS and Windows
pip3 install west

Once the west bootstrapper is installed and the topic-west branch is
merged into master, you will have 2 choices to get a west main
installation.

1. Clone a new copy of the zephyr repository using west:

west init zephyrproject
cd zephyrproject
west update

2. Install west around an existing local zephyr clone:

Move the cloned zephyr/ repository to an empty enclosing folder (for
example zephyrproject/zephyr/), and from this enclosing folder
zephyrproject/ run:

west init -l zephyr/
west update
The -l <path to zephyr> parameter instructs west to use an existing
local copy instead of cloning a remote repository.

Feedback and patches are welcome, but note that the feature will
likely be merged as-is since we consider we have left ample time to
raise any major issues regarding the workflow and decisions taken during
the development of west. This is however only the beginning of west's
(hopefully) long existence as the Zephyr command-line meta-tool, and it
will certainly evolve and change considerably in the future with the
help of the community.

Please submit feedback in the form of GitHub issues on the west
repository itself [1] unless it affects features or functionality in the
zephyr repository directly.

I will reply to this email once the topic-west branch is merged into
master.

Thank you to everybody who has contributed so far!

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/west
[2] https://pypi.org/project/west/
[3] https://github.com/zephyrproject-rtos/zephyr/tree/topic-west
[4] https://docs.zephyrproject.org/latest/tools/west/index.html
[5]
https://github.com/zephyrproject-rtos/zephyr/tree/topic-west/doc/tools
/west [6] https://github.com/zephyrproject-rtos/zephyr/issues/6205
[7] https://github.com/zephyrproject-rtos/zephyr/issues/6770



--
Luiz Augusto von Dentz


--
Luiz Augusto von Dentz
Re: USB ECM buffer size

Andrei
 

Hi Nicolas,

On Mon, Jan 28, 2019 at 04:54:12PM +0100, nicolas lantz wrote:
Hi,

I am working on a demo using Ethernet Over USB on the nrf52840.

In subsys/usb/class/netusb/

I saw a misalignement probleme between the :
        .wMaxSegmentSize = sys_cpu_to_le16(1514),
        declared in function_ecm.c
and the :
        #define NETUSB_MTU 1500
        declared in netusb.h

As rx_buf & tx_buf are defined with a NETUSB_MTU size, this cause that the
frames over 1500 bytes can not be received and are discarded.

Secondly, as fragmentation is not supported (for UDP and TCP datagram), I
suggest to increase the  NETUSB_MTU to the maximum of the possible
ethernet frame size :1522

These modifications give :
    in netusb.h : #define NETUSB_MTU 1522
    in function_ecm.c : .wMaxSegmentSize = sys_cpu_to_le16(NETUSB_MTU),

Attached a patch.
Could you make a proper commit and send Pull Request on github?

Best regards
Andrei Emeltchenko
Ble slave to get master's device name #ble #nrf52480

Andrew Gu
 

Hi, I am making a program in a slave (peripheral) device. I can get a master (central) device connect to the slave (peripheral) device. But, how can I make the slave device to get the device name of the master device after the connection is on? I tried to use bt_gatt_read, but did not have any luck. My code is below. Can anyone help? Thanks in advance.

struct bt_conn *default_conn = NULL;
struct bt_gatt_read_params conn_param;
char devname[64];

u8_t conn_param_read_cb(struct bt_conn *conn, u8_t err, struct bt_gatt_read_params *params, const void *data, u16_t length) {
    if (err) return 0;
    memset(devname, 0, 64);
    memcpy(devname, data, length);
    return 0;
}

void connected(struct bt_conn *conn, u8_t err) {
    if (err) return;
    default_conn = bt_conn_ref(conn);
    conn_param.func = conn_param_read_cb;
    conn_param.handle_count = 1;
    conn_param.single.handle = sys_le16_to_cpu(0x2a00); //BT_UUID_GAP_DEVICE_NAME
    conn_param.single.offset = 0;
    bt_gatt_read(conn, &conn_param);
    return;
}
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool

Carles Cufi
 

Hi Luiz,

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Luiz Augusto von Dentz
Sent: 28 January 2019 21:00
Subject: Re: [Zephyr-devel] [Zephyr-users] Introducing west, Zephyr's
meta-tool

Hi Carles,

How about pull request, how does west deals with them? Or it doesn't and
which case we have to deal with individual git repositories and issue
git push ourselves? This looks like repo which I never liked.
You can see that dealing with Pull Requests is listed as an unresolved issue in the description here:
https://github.com/zephyrproject-rtos/zephyr/issues/6770

There are several possibilities to deal with this, but first and since that you mention Google repo let me make an important distinction. With repo you typically (though not always) track the tip of master on multiple repositories. With west, although that is also possible, we will require specific SHAs for all repos (projects) that are not the main zephyr repo (i.e. the manifest repo).

Options we have (informally, in calls and chats) considered:
1. Send 2 PRs to the 2 repos affected (say for example zephyr + mbedtls), where the branch name used matches. Then CI running in zephyr could look at all repositories listed in the manifest and check if an outstanding PR for it exists with the same GitHub username and branch name.
2. Send the PR to the external project (mbedtls in our example) and another PR to zephyr with the manifest modified so that it points to the fork and branch name of the project's PR. When those are merged, CI could then replace the contents of the manifest with the proper SHA.
3. Introduce some sort of per-PR ChangeId that CI knows how to parse.
4. GitHub adds support for cross-repository PRs. There have been multiple hints that this is coming, but obviously we cannot know when, if ever, this feature will be available.

Note that we have not at any point considered moving away from GitHub. The plan is to adapt to what the service offers and try to find a solution that works well with it. This is also one of the reasons we are first introducing west without actually splitting the ext/ folder into multiple external repos: we want to expose users to west before we start doing more radical changes.

Ideas and feedback welcome!

Thanks,

Carles


On Mon, Jan 28, 2019 at 10:43 AM Cufi, Carles
<carles.cufi@nordicsemi.no> wrote:

Hi all,

For a few months now we have been working on a meta-tool named west,
designed to act both as a command-line tool to build, flash an debug
Zephyr-based applications and also to manage the additional Git
repositories that Zephyr will require in order to build in the near
future.

West is written in Python 3, lives in its own repository [1] and its
bootstrapper is available on PyPi [2].
As soon as we merge the topic-west [3] branch into master (which
should happen in the next few days) you will need to install west in
order to flash and debug, since those commands will rely on havig west
present as part of your Zephyr workflow.

The updated west documentation will be online in the Zephyr
documentation website [4] as soon as the topic-west branch is merged
into master. In the meantime you can also look at the unrendered
documentation sources in the topic-west branch [5] and the existing
GitHub issues [6][7].

In order to install the west boostrapper (which you can do today) run:

# On Linux
pip3 install --user west

# On macOS and Windows
pip3 install west

Once the west bootstrapper is installed and the topic-west branch is
merged into master, you will have 2 choices to get a west main
installation.

1. Clone a new copy of the zephyr repository using west:

west init zephyrproject
cd zephyrproject
west update

2. Install west around an existing local zephyr clone:

Move the cloned zephyr/ repository to an empty enclosing folder (for
example zephyrproject/zephyr/), and from this enclosing folder
zephyrproject/ run:

west init -l zephyr/
west update
The -l <path to zephyr> parameter instructs west to use an existing
local copy instead of cloning a remote repository.

Feedback and patches are welcome, but note that the feature will
likely be merged as-is since we consider we have left ample time to
raise any major issues regarding the workflow and decisions taken during
the development of west. This is however only the beginning of west's
(hopefully) long existence as the Zephyr command-line meta-tool, and it
will certainly evolve and change considerably in the future with the
help of the community.

Please submit feedback in the form of GitHub issues on the west
repository itself [1] unless it affects features or functionality in the
zephyr repository directly.

I will reply to this email once the topic-west branch is merged into
master.

Thank you to everybody who has contributed so far!

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/west
[2] https://pypi.org/project/west/
[3] https://github.com/zephyrproject-rtos/zephyr/tree/topic-west
[4] https://docs.zephyrproject.org/latest/tools/west/index.html
[5]
https://github.com/zephyrproject-rtos/zephyr/tree/topic-west/doc/tools
/west [6] https://github.com/zephyrproject-rtos/zephyr/issues/6205
[7] https://github.com/zephyrproject-rtos/zephyr/issues/6770



--
Luiz Augusto von Dentz
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool

Luiz Augusto von Dentz
 

Hi Carles,

How about pull request, how does west deals with them? Or it doesn't
and which case we have to deal with individual git repositories and
issue git push ourselves? This looks like repo which I never liked.

On Mon, Jan 28, 2019 at 10:43 AM Cufi, Carles <carles.cufi@nordicsemi.no> wrote:

Hi all,

For a few months now we have been working on a meta-tool named west, designed to act both as a command-line tool to build, flash an debug Zephyr-based applications and also to manage the additional Git repositories that Zephyr will require in order to build in the near future.

West is written in Python 3, lives in its own repository [1] and its bootstrapper is available on PyPi [2].
As soon as we merge the topic-west [3] branch into master (which should happen in the next few days) you will need to install west in order to flash and debug, since those commands will rely on havig west present as part of your Zephyr workflow.

The updated west documentation will be online in the Zephyr documentation website [4] as soon as the topic-west branch is merged into master. In the meantime you can also look at the unrendered documentation sources in the topic-west branch [5] and the existing GitHub issues [6][7].

In order to install the west boostrapper (which you can do today) run:

# On Linux
pip3 install --user west

# On macOS and Windows
pip3 install west

Once the west bootstrapper is installed and the topic-west branch is merged into master, you will have 2 choices to get a west main installation.

1. Clone a new copy of the zephyr repository using west:

west init zephyrproject
cd zephyrproject
west update

2. Install west around an existing local zephyr clone:

Move the cloned zephyr/ repository to an empty enclosing folder (for example zephyrproject/zephyr/), and from this enclosing folder zephyrproject/ run:

west init -l zephyr/
west update
The -l <path to zephyr> parameter instructs west to use an existing local copy instead of cloning a remote repository.

Feedback and patches are welcome, but note that the feature will likely be merged as-is since we consider we have left ample time to raise any major issues regarding the workflow and decisions taken during the development of west. This is however only the beginning of west's (hopefully) long existence as the Zephyr command-line meta-tool, and it will certainly evolve and change considerably in the future with the help of the community.

Please submit feedback in the form of GitHub issues on the west repository itself [1] unless it affects features or functionality in the zephyr repository directly.

I will reply to this email once the topic-west branch is merged into master.

Thank you to everybody who has contributed so far!

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/west
[2] https://pypi.org/project/west/
[3] https://github.com/zephyrproject-rtos/zephyr/tree/topic-west
[4] https://docs.zephyrproject.org/latest/tools/west/index.html
[5] https://github.com/zephyrproject-rtos/zephyr/tree/topic-west/doc/tools/west
[6] https://github.com/zephyrproject-rtos/zephyr/issues/6205
[7] https://github.com/zephyrproject-rtos/zephyr/issues/6770


--
Luiz Augusto von Dentz
USB ECM buffer size

nicolas lantz
 

Hi,

I am working on a demo using Ethernet Over USB on the nrf52840.

In subsys/usb/class/netusb/

I saw a misalignement probleme between the :
        .wMaxSegmentSize = sys_cpu_to_le16(1514),
        declared in function_ecm.c
and the :
        #define NETUSB_MTU 1500
        declared in netusb.h

As rx_buf & tx_buf are defined with a NETUSB_MTU size, this cause that the frames over 1500 bytes can not be received and are discarded.


Secondly, as fragmentation is not supported (for UDP and TCP datagram), I suggest to increase the  NETUSB_MTU to the maximum of the possible ethernet frame size :1522

These modifications give :
    in netusb.h : #define NETUSB_MTU 1522
    in function_ecm.c : .wMaxSegmentSize = sys_cpu_to_le16(NETUSB_MTU),


Attached a patch.

-- 
Cordialement,
Nicolas

Nicolas LANTZ
M : +33 (0)6 19 07 43 43
T : +33 (0)9 52 96 81 86
www.ubicore.net

?
align-wMaxSegmentSize-and-NETUSBMTU.patch

Re: Get RSSI in DTM(Zephyr)

Tommy Lin (林志聰) <Tommy.Lin@...>
 

Hi Vinayak,

I find a sample code in tests/Bluetooth/shell , and it can seem to test BT DTM.

It will produce an error message about SRAM overflow (log is in attachment) , when I compile it.

 

 

Could you give us some suggestions.

 

Best regards,

Tommy

From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]
Sent: Monday, January 14, 2019 3:45 PM
To: Isaac Chen (陳尚航) <Isaac_Chen@...>; Tommy Lin (林志聰) <Tommy.Lin@...>; zephyr-devel@...
Cc: Hanyu.Hsu@...; Rung-Sheng Lee (李榮盛) <Rung.Sheng.Lee@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: RE: Get RSSI in DTM(Zephyr)

 

Hi Chen,

 

1.     As I know, BLE RSSI can’t be measured in standard DTM mode. Is it possible to add new feature in DTM to support BLE RSSI measurement?

[vich] Yes, this is possible, but the command will have to be proprietary as per your test requirements.

 

2.     If the answer to the above question is “no”, I still need your confirmation if other test modes exist that can measure RSSI except DTM mode.

In our experiences of other algorithm(LTE/WCDMA…etc.), RSSI usually can be detected easily in test mode via a CW tone. So it’s why we want

to double check this.

[vich] RSSI can be easily measured in nRF5x series chips during Radio Rx mode. Implementation will have to be as per your requirement, as standard DTM mode does not define any interface for RSSI in DTM mode.

 

3.     Do you have any customers who have experiences to measure conductive RSSI in factory or in lab? If so, can you share the methodology?

[vich] Other customers may be doing so, but I am not aware of unless the implementation is submitted upstream via a PR.

 

 

Regards,

Vinayak

 

From: Isaac Chen (陳尚航) <Isaac_Chen@...>
Sent: 14 January 2019 04:08
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Tommy Lin (林志聰) <Tommy.Lin@...>; zephyr-devel@...
Cc: Hanyu.Hsu@...; Rung-Sheng Lee (李榮盛) <Rung.Sheng.Lee@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: RE: Get RSSI in DTM(Zephyr)
Importance: High

 

Hi Vinayak,

 

Our customer requested us to test conductive BLE RSSI in factory for accuracy improvement.

Could you please clarify the following questions?

1.     As I know, BLE RSSI can’t be measured in standard DTM mode. Is it possible to add new feature in DTM to support BLE RSSI measurement?

[vich] Yes, this is possible, but the command will have to be proprietary as per your test requirements.

2.     If the answer to the above question is “no”, I still need your confirmation if other test modes exist that can measure RSSI except DTM mode.

In our experiences of other algorithm(LTE/WCDMA…etc.), RSSI usually can be detected easily in test mode via a CW tone. So it’s why we want

to double check this.

[vich] RSSI can be easily measured in nRF5x series chips during Radio Rx mode. Implementation will have to be as per your requirement, as standard DTM mode does not define any interface for RSSI in DTM mode.

3.     Do you have any customers who have experiences to measure conductive RSSI in factory or in lab? If so, can you share the methodology?

[vich] Other customers may be doing so, but I am not aware of unless the implementation is submitted upstream via a PR.

 

 

Best Regards

 

Isaac Chen

Quanta Computer Inc.

Business Unit 11 BL1

Tel  : +886-3-327-2345 Ext : 17585

 

This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately. 

 

From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]
Sent: Wednesday, January 09, 2019 8:00 PM
To: Tommy Lin (林志聰); zephyr-devel@...
Cc: Hanyu.Hsu@...; Isaac Chen (陳尚航); Rung-Sheng Lee (李榮盛); Brent Tsai (蔡旻其); Ryan Hsu (徐振鋒)
Subject: RE: Get RSSI in DTM

 

Hi Tommy,

 

I don’t remember if DTM mode has any RSSI command in the Specification.

 

Could you please elaborate on your requirements?

 

Regards,

Vinayak

 

From: devel@... <devel@...> On Behalf Of Tommy Lin (???)
Sent: 08 January 2019 13:25
To: zephyr-devel@...
Cc: Hanyu.Hsu@...; Isaac Chen (陳尚航) <Isaac_Chen@...>; Rung-Sheng Lee (李榮盛) <Rung.Sheng.Lee@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: [Zephyr-devel] Get RSSI in DTM

 

Hi ,

We have a product using nRF51824 with zephyr.

We use hci_uart sample code and follow below link , and we can get other BT device’s RSSI.

https://devzone.nordicsemi.com/b/blog/posts/nrf5x-support-within-the-zephyr-project-rtos

 

We have a question , If it is in DTM(Direct Test Mode) , how can we get RSSI?

Could you give us some suggestions.

 

Best regards,

Tommy

?
message_log.txt

bond information deleted #ble

nick.ward@...
 

Hi all,
I'm developing a system with Zephyr that has been configured to have 4 Bluetooth connections and 4 paired devices for a Nordic nRF52832 SoC.
 
CONFIG_BT_MAX_CONN=4
CONFIG_BT_MAX_PAIRED=4

I'm finding that when pairing/bonding with a phone the first is very smooth to go through the pairing/bonding process (passkey displayed on the Zephyr device and passkey entered on the mobile device).  Pairing the second device with the 1st connected is not as smooth and doesn't always succeed.
It should be noted that a notification (between 14 to 20 bytes) is being generated every 1s.

I've found that after creating a BLE bond and I connection and disconnect the mobile device 3 or 4 times the bond information is deleted on the mobile device (I'm testing with the Nordic nrf connect app and this information is in the log).  I'm currently not sure why this is happening and am I hoping it can be fixed as this behaviour would be very inconvenient for users of this device (constantly having to repair their mobile device bond).   I would imagine if I hadn't assigned enough tx/rx buffers for the Bluetooth stack the connection may be flaky but I wouldn't think the bond information would become lost.

If anyone could give some insight into what might be happening to causes this issue I would be very grateful.
Thanks.

Nick Ward
1901 - 1920 of 7536  
More
Home Messages Hashtags Subgroups Terms