Date   

Re: Zephyr Low Level BLE Radio question

Chettimada, Vinayak Kariappa
 

> I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

There are no standard HCI interface to set application defined radio frequency, this will be against the Bluetooth specifications.

 

Refer to Bluetooth Specification V5.2, Vol 6, Part B, section 4.4.2.1 Advertising channel index selection:

 

Advertising events use three predefined primary advertising physical channels.

Primary advertising channel indices are either used or unused.

For AUX_ADV_IND and AUX_CHAIN_IND PDUs, the secondary advertising

channel index used in the Channel Index subfield of the AuxPtr field is

implementation specific. It is recommended that sufficient channel diversity is

used to avoid collisions.

 

In the Zephyr BLE controller, advertising extensions is experimental, and the function that fills the advertising channel can be found here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/ll_sw/ull_adv_aux.c#L788

 

 

>Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.

 

Correct.

 

>Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

These bits decide the `advertising event` on the primary channels, to use channel 37, 38, and 39. The `small header` is repeated in these channels inside a standard `advertising event`, and that is what is selected by these bits.

For further details please refer to Bluetooth specifications.

 

-Vinayak

 

From: steven ghekiere <stevenghekiere@...>
Sent: 15 December 2020 20:51
To: Chettimada, Vinayak <vinayak.kariappa.chettimada@...>; Marciano Preciado <marciano@...>
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

 

Hey Vinayak,

 

Thanks for the reply!

 

I had a quick look at the extended advertising links you mentioned.

 

I assumed the general GAP protocol does similar stuff (as you showed) but doubted that it could just set data on a set channel.

I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

(Wrote this as I was reading through your provided documentation)

As I understand, the ‘bt_le_adv_param parameter of the create method’ has a 32 bit options field (0-17 actually used?).

In these options we have:

  • Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.
  • Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

 

Thanks!

 

Steven

 

 

From: Chettimada, Vinayak
Sent: dinsdag 15 december 2020 20:17
To: stevenghekiere@...; Marciano Preciado
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hi,

 

If you are building a Bluetooth Low Energy application using Zephyr, then you should use the public APIs, not call internal subsystem functions unless you know what you are doing.

 

I think you are looking for the below mentioned options when calling bt_le_ext_adv_create (https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.bt_le_ext_adv_create)

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

 

These are for the primary advertising channels, auxiliary PDU channels selection is controller implementation specific.

 

If you are not using Bluetooth Low Energy stack, then you should refer to nRF52840 product specification for implementing your proprietary radio protocol.

 

>The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too

 

Contributions to improve the code, comments and add new features are always welcome.

 

Regards,

Vinayak

 

 

From: users@... <users@...> On Behalf Of steven ghekiere via lists.zephyrproject.org
Sent: 15 December 2020 19:48
To: Marciano Preciado <marciano@...>
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Marciano,

 

Thanks for the quick reply!

I’d have to agree on the acronyms and such.

 

What do you mean that ‘somebody can help us’?

 

Thanks

 

Steven

 

 

 

From: Marciano Preciado
Sent: dinsdag 15 december 2020 19:15
To: stevenghekiere@...
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Steven!

 

I’d have to agree! The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too, but there aren’t. 😭

 

I hope somebody can help us out.

 

Best,

Marciano Preciado
Embedded Systems Engineer
PassiveLogic Inc.
Mobile 801-800-1184

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

 

On Dec 15, 2020, at 7:11 AM, steven ghekiere via lists.zephyrproject.org <stevenghekiere=hotmail.com@...> wrote:

 

 

Hey there,

 

I’m a student working on a project using a Nordic nRF52840 device.

 

The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.

More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.

 

I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least. 

I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.

 

Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.

Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.

 

Looking forward to your answer,

Steven Ghekiere

 

 

p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.

 

 

 

 


Re: Zephyr Low Level BLE Radio question

steven ghekiere <stevenghekiere@...>
 

 

Hey Vinayak,

 

Thanks for the reply!

 

I had a quick look at the extended advertising links you mentioned.

 

I assumed the general GAP protocol does similar stuff (as you showed) but doubted that it could just set data on a set channel.

I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

(Wrote this as I was reading through your provided documentation)

As I understand, the ‘bt_le_adv_param parameter of the create method’ has a 32 bit options field (0-17 actually used?).

In these options we have:

  • Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.
  • Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

 

Thanks!

 

Steven

 

 

From: Chettimada, Vinayak
Sent: dinsdag 15 december 2020 20:17
To: stevenghekiere@...; Marciano Preciado
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hi,

 

If you are building a Bluetooth Low Energy application using Zephyr, then you should use the public APIs, not call internal subsystem functions unless you know what you are doing.

 

I think you are looking for the below mentioned options when calling bt_le_ext_adv_create (https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.bt_le_ext_adv_create)

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

 

These are for the primary advertising channels, auxiliary PDU channels selection is controller implementation specific.

 

If you are not using Bluetooth Low Energy stack, then you should refer to nRF52840 product specification for implementing your proprietary radio protocol.

 

>The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too

 

Contributions to improve the code, comments and add new features are always welcome.

 

Regards,

Vinayak

 

 

From: users@... <users@...> On Behalf Of steven ghekiere via lists.zephyrproject.org
Sent: 15 December 2020 19:48
To: Marciano Preciado <marciano@...>
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Marciano,

 

Thanks for the quick reply!

I’d have to agree on the acronyms and such.

 

What do you mean that ‘somebody can help us’?

 

Thanks

 

Steven

 

 

 

From: Marciano Preciado
Sent: dinsdag 15 december 2020 19:15
To: stevenghekiere@...
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Steven!

 

I’d have to agree! The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too, but there aren’t. 😭

 

I hope somebody can help us out.

 

Best,

Marciano Preciado
Embedded Systems Engineer
PassiveLogic Inc.
Mobile 801-800-1184

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

 

On Dec 15, 2020, at 7:11 AM, steven ghekiere via lists.zephyrproject.org <stevenghekiere=hotmail.com@...> wrote:

 

 

Hey there,

 

I’m a student working on a project using a Nordic nRF52840 device.

 

The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.

More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.

 

I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least. 

I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.

 

Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.

Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.

 

Looking forward to your answer,

Steven Ghekiere

 

 

p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.

 

 

 

 


Re: Zephyr Low Level BLE Radio question

Chettimada, Vinayak Kariappa
 

Hi,

 

If you are building a Bluetooth Low Energy application using Zephyr, then you should use the public APIs, not call internal subsystem functions unless you know what you are doing.

 

I think you are looking for the below mentioned options when calling bt_le_ext_adv_create (https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.bt_le_ext_adv_create)

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

 

These are for the primary advertising channels, auxiliary PDU channels selection is controller implementation specific.

 

If you are not using Bluetooth Low Energy stack, then you should refer to nRF52840 product specification for implementing your proprietary radio protocol.

 

>The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too

 

Contributions to improve the code, comments and add new features are always welcome.

 

Regards,

Vinayak

 

 

From: users@... <users@...> On Behalf Of steven ghekiere via lists.zephyrproject.org
Sent: 15 December 2020 19:48
To: Marciano Preciado <marciano@...>
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Marciano,

 

Thanks for the quick reply!

I’d have to agree on the acronyms and such.

 

What do you mean that ‘somebody can help us’?

 

Thanks

 

Steven

 

 

 

From: Marciano Preciado
Sent: dinsdag 15 december 2020 19:15
To: stevenghekiere@...
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Steven!

 

I’d have to agree! The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too, but there aren’t. 😭

 

I hope somebody can help us out.

 

Best,

Marciano Preciado
Embedded Systems Engineer
PassiveLogic Inc.
Mobile 801-800-1184

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

 

On Dec 15, 2020, at 7:11 AM, steven ghekiere via lists.zephyrproject.org <stevenghekiere=hotmail.com@...> wrote:

 

 

Hey there,

 

I’m a student working on a project using a Nordic nRF52840 device.

 

The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.

More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.

 

I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least. 

I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.

 

Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.

Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.

 

Looking forward to your answer,

Steven Ghekiere

 

 

p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.

 

 

 


Re: Zephyr Low Level BLE Radio question

steven ghekiere <stevenghekiere@...>
 

Hey Marciano,

 

Thanks for the quick reply!

I’d have to agree on the acronyms and such.

 

What do you mean that ‘somebody can help us’?

 

Thanks

 

Steven

 

 

 

From: Marciano Preciado
Sent: dinsdag 15 december 2020 19:15
To: stevenghekiere@...
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Steven!

 

I’d have to agree! The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too, but there aren’t. 😭

 

I hope somebody can help us out.

 

Best,

Marciano Preciado
Embedded Systems Engineer
PassiveLogic Inc.
Mobile 801-800-1184

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.



On Dec 15, 2020, at 7:11 AM, steven ghekiere via lists.zephyrproject.org <stevenghekiere=hotmail.com@...> wrote:

 

 

Hey there,

 

I’m a student working on a project using a Nordic nRF52840 device.

 

The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.

More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.

 

I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least. 

I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.

 

Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.

Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.

 

Looking forward to your answer,

Steven Ghekiere

 

 

p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.

 

 

 


Re: Zephyr Low Level BLE Radio question

Marciano Preciado <marciano@...>
 

Hey Steven!

I’d have to agree! The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too, but there aren’t. 😭

I hope somebody can help us out.

Best,
Marciano Preciado
Embedded Systems Engineer
PassiveLogic Inc.
Mobile 801-800-1184

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

On Dec 15, 2020, at 7:11 AM, steven ghekiere via lists.zephyrproject.org <stevenghekiere=hotmail.com@...> wrote:

 
Hey there,
 
I’m a student working on a project using a Nordic nRF52840 device.
 
The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.
More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.
 
I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least. 
I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.
 
Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.
Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.
 
Looking forward to your answer,
Steven Ghekiere
 
 
p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.
 


Zephyr Low Level BLE Radio question

steven ghekiere <stevenghekiere@...>
 

 

Hey there,

 

I’m a student working on a project using a Nordic nRF52840 device.

 

The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.

More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.

 

I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least.

I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.

 

Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.

Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.

 

Looking forward to your answer,

Steven Ghekiere

 

 

p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.

 


Re: API meeting: agenda

Carles Cufi
 

One additional item if time permits:

- subsystem: task_wdt: Implement software watchdog suitable for multiple threads
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/28947

-----Original Message-----
From: Cufi, Carles
Sent: 15 December 2020 13:14
To: 'devel@lists.zephyrproject.org' <devel@lists.zephyrproject.org>;
users@lists.zephyrproject.org
Subject: API meeting: agenda

Hi all,

Agenda for today.
Note that this will be the last API meeting of 2020. The following one
will take place in January 5th, 2021.

- drivers: can: Rework can_configure API and zcan_frame
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/28345

- Minor ADC API updates
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/30533
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/30726

- I2C slave driver removed
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/30557


If you have additional items please let me know.

Teams link: https://teams.microsoft.com/l/meetup-
join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40threa
d.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-
b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-
5e334e88f6d8%22%7d

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


API meeting: agenda

Carles Cufi
 


Re: Support for Adafruit Feather #nrf52840 Sense #nrf52840

William Fish
 

Hi Leo,
The Adafruit Sense is much like the Arduino Sense, both use the nRF52840 but use a modified bootloader. They have been designed to work with the Arduino platform.

Luckily work porting the Arduino sense version is underway (check out the pull request on the Zephyr GitHub). So far it compiles and boots, there are a few issues still to be ironed out but if you could assist it would be appreciated. It shouldn't be a huge leap to get it working on the Adafruit version.

https://github.com/zephyrproject-rtos/zephyr/pull/29097

Billy..



k_uptime_get() #api

mohamed.belaroussi@...
 

I need to keep track of the time elapsed since boot-up using the function k_uptime_get() but it is always returning zero (0).
I am using an nRF5340PDK and Zephyr OS build v2.3.0-rc1-ncs1. The IDE used is SES for ARM (Nordic Edition) v5.10d (64-bit) running under windows 10.

This is what I am doing in my code.
#include <zephyr.h>
#include <kernel.h>
#include <sys/printk.h>
#include <stdio.h>

s64_t time_ms = k_uptime_get();

printf( "Booting-up @%i: \n", time_ms );
printk( "%i: ", time_ms );

Can someone please help and tell me what I am doing wrong?
Thank you.

Kind regards
Mohamed

 


Re: Query regarding Bluetooth Controller Porting

Carles Cufi
 

+ devel list

Pankaj,

If you are using a dual-chip solution, then as long as you controller complies with standard HCI there is no "porting" to do whatsoever.
In order to better understand what you need, can you let us know which transport do you plan on using (UART/H4, 3-wire/H3 or SPI) and whether it is a single-mode or dual-mode controller?

Unless your controllers has special requirements it should all be a matter of configuring the right Kconfig options and Devicetree nodes.

Carles

-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On
Behalf Of Kumar Gala via lists.zephyrproject.org
Sent: 08 December 2020 15:08
To: Pankaj Singh <PANKAJ.SINGH@onsemi.com>
Cc: users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Query regarding Bluetooth Controller Porting

You may want to ask this question on the devel list.
(devel@lists.zephyrproject.org)

- k

On Dec 8, 2020, at 12:02 AM, Pankaj Singh <PANKAJ.SINGH@onsemi.com>
wrote:

Hi,

We want to port our custom Bluetooth controller to run on Zephyr RTOS
(not using the default zephyr ble controller support). I went through the
Bluetooth documentation
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zep
hyrproject.org%2Flatest%2Fguides%2Fbluetooth%2Findex.html&amp;data=04%7C01
%7Ccarles.cufi%40nordicsemi.no%7Cc35438a7065845415d0708d89b82c771%7C28e5af
a2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637430333288501659%7CUnknown%7CTWFpbG
Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
C1000&amp;sdata=6J8jWeiNRxk3NPbnu1uQq0g01EaUG8wCYsQK58AFk6w%3D&amp;reserve
d=0
,https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.ze
phyrproject.org%2Flatest%2Fguides%2Fbluetooth%2Fbluetooth-
arch.html&amp;data=04%7C01%7Ccarles.cufi%40nordicsemi.no%7Cc35438a70658454
15d0708d89b82c771%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C63743033328
8501659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=pzOa7iuR0SSOR59u4s5VE3LgNF5MeoXR
ku7XtLCnOWo%3D&amp;reserved=0. The link’s talks about Bluetooth host in
detail and it was helpful. We want to use Dual Chip configuration mode
(use Zephyr Bluetooth host + custom Bluetooth controller support) .

From link it talks about various host only build configuration
o CONFIG_BT =y
o CONFIG_BT_HCI =y
o CONFIG_BT_CTLR =n


My query is in order to port custom controller what steps, build
configuration we need to take care of. If there is a link/document that
helps to describe porting of custom Bluetooth controller to Zephyr it will
be helpful.

-thanks




Re: Query regarding Bluetooth Controller Porting

Kumar Gala
 

You may want to ask this question on the devel list. (devel@lists.zephyrproject.org)

- k

On Dec 8, 2020, at 12:02 AM, Pankaj Singh <PANKAJ.SINGH@onsemi.com> wrote:

Hi,

We want to port our custom Bluetooth controller to run on Zephyr RTOS (not using the default zephyr ble controller support). I went through the Bluetooth documentation https://docs.zephyrproject.org/latest/guides/bluetooth/index.html ,https://docs.zephyrproject.org/latest/guides/bluetooth/bluetooth-arch.html. The link’s talks about Bluetooth host in detail and it was helpful. We want to use Dual Chip configuration mode (use Zephyr Bluetooth host + custom Bluetooth controller support) .

From link it talks about various host only build configuration
o CONFIG_BT =y
o CONFIG_BT_HCI =y
o CONFIG_BT_CTLR =n


My query is in order to port custom controller what steps, build configuration we need to take care of. If there is a link/document that helps to describe porting of custom Bluetooth controller to Zephyr it will be helpful.

-thanks


Query regarding Bluetooth Controller Porting

Pankaj Singh <PANKAJ.SINGH@...>
 

Hi,

 

We want to port our custom Bluetooth controller to run on Zephyr RTOS (not using the default zephyr ble controller support). I went through  the Bluetooth documentation https://docs.zephyrproject.org/latest/guides/bluetooth/index.html , https://docs.zephyrproject.org/latest/guides/bluetooth/bluetooth-arch.html.  The link’s talks about Bluetooth host in detail and it was helpful. We want to use Dual Chip configuration mode (use Zephyr Bluetooth host  + custom Bluetooth controller support) .

 

From link it talks about various host only build configuration

o   CONFIG_BT =y

o   CONFIG_BT_HCI =y

o   CONFIG_BT_CTLR =n

 

 

My query is in order to port custom controller what steps, build configuration we need to take care of.  If there is a link/document that helps to describe porting of custom Bluetooth controller to Zephyr it will be helpful.  

 

-thanks


Using C++ in projects

Yuval Peress
 

Looking at https://docs.zephyrproject.org/latest/reference/kernel/other/cxx_support.html#c-support-for-applications I've been able to play around with some C++ applications, but I'm not seeing any verbose documentation about this. For example RTTI does seem to be supported (while the doc still says it isn't). I have 2 questions:

1. Is there a specific standard of C++ that's supported by the Zephyr toolchain? Can we use C++20 (I've been building with it and so far it seems to work, I just want to know if that's officially supported)?
2. Is there a sub-taskforce to help keep the docs up-to-date? Should there be? Are there other things other than RTTI that are out of date?

Thanks in advance,

Yuval


Re: Support for Adafruit Feather #nrf52840 Sense #nrf52840

Carles Cufi
 

Hi Leo,

 

Zephyr seems to support the nRF52840 Feather Express, but not the Feather Sense:

https://docs.zephyrproject.org/latest/boards/arm/adafruit_feather_nrf52840/doc/index.html

 

This is the right place for questions about this board, not Nordic’s downstream.

 

I encourage you to read through the board porting guide and submit a Pull Request with the support for this board:

https://docs.zephyrproject.org/latest/guides/porting/board_porting.html

 

Once this board is functional in Zephyr, Nordic’s downstream will pick it up automatically and you’ll be able to use esb with it.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Leo via lists.zephyrproject.org
Sent: 06 December 2020 03:47
To: users@...
Subject: [Zephyr-users] Support for Adafruit Feather #nrf52840 Sense

 

Hello Zephyr team!

I have a question about board support and I also need your help building an example project.

1) Does Zephyr support the board below? How would I go about using its sensors?
https://www.adafruit.com/product/4516

2) Is this the right place to ask questions about NordicSemi's downstream of Zephyr's repository? If not, please point me to the right place!
The issue that I am having is that one example project that builds for nrf52840dk_nrf52840, does not build for adafruit_feather_nrf52840.

Example project: ncs/nrf/samples/esb/ptx
Zephyr version: 2.4.99
ZEPHYR_TOOLCHAIN_VARIANT is gnuarmemb
west build -b adafruit_feather_nrf52840 C:/embedded/ncs/nrf/samples/esb/ptx
Not sure which of the errors would better help identifying the issue, but here's the first one:
**************
    In file included from C:/embedded/ncs/zephyr/include/arch/arm/aarch32/arch.h:20,
                     from C:/embedded/ncs/zephyr/include/arch/cpu.h:19,
                     from C:/embedded/ncs/zephyr/include/kernel_includes.h:38,
                     from C:/embedded/ncs/zephyr/include/kernel.h:17,
                     from C:/embedded/ncs/zephyr/include/init.h:11,
                     from C:/embedded/ncs/zephyr/include/device.h:22,
                     from C:/embedded/ncs/zephyr/include/drivers/clock_control.h:26,
                     from C:/embedded/ncs/nrf/samples/esb/ptx/src/main.c:6:
    C:/embedded/ncs/nrf/samples/esb/ptx/src/main.c: In function 'leds_init':
    C:/embedded/ncs/zephyr/include/devicetree.h:202:32: error: 'DT_N_ALIAS_led2_P_gpios_IDX_0_VAL_pin' undeclared (first use in this function); did you mean 'DT_N_S_leds_S_led_0_P_gpios_IDX_0_VAL_pin'?
      202 | #define DT_ALIAS(alias) DT_CAT(DT_N_ALIAS_, alias)
          |                                ^~~~~~~~~~~
    ...
    ...
    ...
    ninja: build stopped: subcommand failed.
    FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' --build 'C:\embedded\build'
**************

The repository in question is https://github.com/nrfconnect/sdk-nrf/ which is the only one that has the esb/ptx example.
How do I build that specific example for this board?

Thanks for your help!
Best,
Leo


Support for Adafruit Feather #nrf52840 Sense #nrf52840

Leo
 

Hello Zephyr team!

I have a question about board support and I also need your help building an example project.

1) Does Zephyr support the board below? How would I go about using its sensors?
https://www.adafruit.com/product/4516

2) Is this the right place to ask questions about NordicSemi's downstream of Zephyr's repository? If not, please point me to the right place!
The issue that I am having is that one example project that builds for nrf52840dk_nrf52840, does not build for adafruit_feather_nrf52840.

Example project: ncs/nrf/samples/esb/ptx
Zephyr version: 2.4.99
ZEPHYR_TOOLCHAIN_VARIANT is gnuarmemb
west build -b adafruit_feather_nrf52840 C:/embedded/ncs/nrf/samples/esb/ptx
Not sure which of the errors would better help identifying the issue, but here's the first one:
**************
    In file included from C:/embedded/ncs/zephyr/include/arch/arm/aarch32/arch.h:20,
                     from C:/embedded/ncs/zephyr/include/arch/cpu.h:19,
                     from C:/embedded/ncs/zephyr/include/kernel_includes.h:38,
                     from C:/embedded/ncs/zephyr/include/kernel.h:17,
                     from C:/embedded/ncs/zephyr/include/init.h:11,
                     from C:/embedded/ncs/zephyr/include/device.h:22,
                     from C:/embedded/ncs/zephyr/include/drivers/clock_control.h:26,
                     from C:/embedded/ncs/nrf/samples/esb/ptx/src/main.c:6:
    C:/embedded/ncs/nrf/samples/esb/ptx/src/main.c: In function 'leds_init':
    C:/embedded/ncs/zephyr/include/devicetree.h:202:32: error: 'DT_N_ALIAS_led2_P_gpios_IDX_0_VAL_pin' undeclared (first use in this function); did you mean 'DT_N_S_leds_S_led_0_P_gpios_IDX_0_VAL_pin'?
      202 | #define DT_ALIAS(alias) DT_CAT(DT_N_ALIAS_, alias)
          |                                ^~~~~~~~~~~
    ...
    ...
    ...
    ninja: build stopped: subcommand failed.
    FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' --build 'C:\embedded\build'
**************

The repository in question is https://github.com/nrfconnect/sdk-nrf/ which is the only one that has the esb/ptx example.
How do I build that specific example for this board?

Thanks for your help!
Best,
Leo


Re: device_get_binding() returns NULL on all but one vl53l0x

Erwan Gouriou
 

Hi Matthias,

Indeed this dynamic behavior is not implemented.
As you can see in vl53lx driver, vl53l0x_init make use of DT_INST_FOO(0, bar) macros.
Which means only the information from instance 0 are used.

This being said, enabling dynamic support should not be that complicated.
A lot of zephyr drivers support instantiation and could be used as example.

Here are the steps:
- Add a config struct to the driver init to store all the instance init data from device tree
- rework the vl53l0x_init function to be instance agnostic by using this config struct
- Instantiate the driver DEVICE_AND_API_INIT thanks to DT_INST_FOREACH_STATUS_OKAY(FOO) macro

DT_INST_FOREACH_STATUS_OKAY(FOO) will loop through all dt enabled instances of your sensor
and call FOO(i) for each instance.
You'll find doc and examples of use of this macro throughout the tree. 

Best regards
Erwan






 

On Wed, 2 Dec 2020 at 14:56, Matthias Wenzel <mw@...> wrote:
Hi,

I am using six vl53l0x (a laser time-of-flight sensor) on two I2C busses (three each), and device_get_binding() returns NULL on all but one.

The vl53l0x is special in that regard that it cannot be pin-strapped to a device-address, instead it always comes up as address 0x29, and has a SW command to assign it a new address. So when using multiple vl53l0x on one I2C bus the mechanism is to keep all-but-one in reset, assign a new address, and release the next from reset. This mechanism seems to work fine with this loop getting called with 0..5:

void vl53l0x_init_addr(int n)
{
    const struct device *i2c1 = device_get_binding(DT_LABEL(DT_PATH(soc, i2c_40005400)));
    const struct device *i2c2 = device_get_binding(DT_LABEL(DT_PATH(soc, i2c_40005800)));

    switch (n)
    {
        case 0:
            xshut_release(PORTPIN_TOF_C_XSHUT);
            vl53l0x_hop_to_addr(i2c1, 0x31);
            vl53l0x[2].vl53l0x = device_get_binding(DT_LABEL(DT_NODELABEL(vl53l0x_c)));
            break;
        case 1:
            xshut_release(PORTPIN_TOF_B_XSHUT);
            vl53l0x_hop_to_addr(i2c1, 0x30);
            vl53l0x[1].vl53l0x = device_get_binding(DT_LABEL(DT_NODELABEL(vl53l0x_b)));
            break;
        case 2:
            xshut_release(PORTPIN_TOF_A_XSHUT);
            vl53l0x[0].vl53l0x = device_get_binding(DT_LABEL(DT_NODELABEL(vl53l0x_a)));
            break;
        case 3:
            xshut_release(PORTPIN_TOF_F_XSHUT);
            vl53l0x_hop_to_addr(i2c2, 0x31);
            vl53l0x[5].vl53l0x = device_get_binding(DT_LABEL(DT_NODELABEL(vl53l0x_f)));
            break;
        case 4:
            xshut_release(PORTPIN_TOF_E_XSHUT);
            vl53l0x_hop_to_addr(i2c2, 0x30);
            vl53l0x[4].vl53l0x = device_get_binding(DT_LABEL(DT_NODELABEL(vl53l0x_e)));
            break;
        case 5:
            xshut_release(PORTPIN_TOF_D_XSHUT);
            vl53l0x[3].vl53l0x = device_get_binding(DT_LABEL(DT_NODELABEL(vl53l0x_d)));
            break;
    }
}

However when testing lateron, only vl53l0x[0].vl53l0x has an address, the other five are 0. Note that vl53l0x[0].vl53l0x gets actually set in the third call to the above function.

    for (int i = 0; i < N_VL53L0X; i++)
    {
        printf("DEV[%d] = %p\r\n", i, vl53l0x[i].vl53l0x);
    }
Prints:
DEV[0] = 0x20020f04
DEV[1] = 0x0
DEV[2] = 0x0
DEV[3] = 0x0
DEV[4] = 0x0
DEV[5] = 0x0

I am using an DT-overlay which is

&i2c1 {
    status = "okay";
    clock-frequency = < 100000 >;
    pinctrl-0 = < &i2c1_scl_pb6 &i2c1_sda_pb9 >;
    vl53l0x_a: tofi2c1@29 {
        compatible = "st,vl53l0x";
        reg = < 0x29 >;
        label = "VL53L0X_A";
    };
    vl53l0x_b: tofi2c1@30 {
        compatible = "st,vl53l0x";
        reg = < 0x30 >;
        label = "VL53L0X_B";
    };
    vl53l0x_c: tofi2c1@31 {
        compatible = "st,vl53l0x";
        reg = < 0x31 >;
        label = "VL53L0X_C";
    };
};
&i2c2 {
    status = "okay";
    clock-frequency = < 100000 >;
    pinctrl-0 = < &i2c2_scl_pf1 &i2c2_sda_pf0 >;
    vl53l0x_d: tofi2c2@29 {
        compatible = "st,vl53l0x";
        reg = < 0x29 >;
        label = "VL53L0X_D";
    };
    vl53l0x_e: tofi2c2@30 {
        compatible = "st,vl53l0x";
        reg = < 0x30 >;
        label = "VL53L0X_E";
    };
    vl53l0x_f: tofi2c2@31 {
        compatible = "st,vl53l0x";
        reg = < 0x31 >;
        label = "VL53L0X_F";
    };
};

Is this "dynamic" behaviour unsupported in current DT and/or the zephyr vl53l0x driver implementation, or am I missing some detail on how to implement this properly?
I am on an nucleo-144 STM32F767ZI eval board.

Thanks & best regards,

matthias






contiki-ng RPL-border router in zephyr #nrf52840

Nikos Karamolegkos
 

Hello, I am investigating if the implementation of contiki-ng RPL border router can be useful in zephyr. I am trying to set up the echo client example of zephyr using the overlay-802154.conf file in order to ping6 from nrf52840-dk running zephyr to a cc2538 module running the contiki-ng RPL border router. I have the same configuration in both OS (channel, panid, band, etc) however I have not positive results yet. Has anybody tried something similar? I am testing is for fun to achieve OS diversity.

Thank you,


Zephyr SDK 0.12.0-beta-3 available for testing

Kumar Gala
 

Hi,

Latest version of the SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.12.0-beta-3

Please download and try things out and report any issues. Please report issues here:

https://github.com/zephyrproject-rtos/sdk-ng/issues

Known issues (these are on the Zephyr side):

* some xtensa platforms may need updating w/regards to Zephyr & Xtensa HAL
[ https://github.com/zephyrproject-rtos/zephyr/pull/23142 ]

* known issue with arm64 and linking C++ & newlib:
[ https://github.com/zephyrproject-rtos/zephyr/issues/28650 ]

Changes since the last release (beta-2):

• Fixed bug with ARM libgcc builds & CMSE
• Built newlib optimized

Current plan is to release SDK 0.12.0 towards the middle of next week.

- k


How to implements SPI slave event handler on zephyr #spi

mfinmuch@...
 

Recently I am trying to use nrf52840 to implement SPI slave on zephyr
In Nordic's SPIS example, it will go to spis_event_handler when an interrupt occurs
In spis_event_handler, judge whether the transmission has been completed, as follow
if (event.evt_type == NRF_DRV_SPIS_XFER_DONE)
I want to implement this interrupt function on zephyr
But at present zephyr SPIS I have not seen an example of event handler
Only simple spi_write and spi_read can be used to write/read
And in \zephyr\drivers\spi\spi_nrfx_spi.c, I saw a function that does the same thing as the spis_event_handler of the Nordic example
as follows

How to add this event_handler in the main function in the sample?

421 - 440 of 2789