Date   

Network forum agenda

Jukka Rissanen
 

Hi all,

There is a network forum meeting tomorrow Tue 1 June at 8AM PST / 17.00
CEST.

Currently the agenda is empty, so if there is anything network related
topics you want to discuss, please let me know, otherwise I will cancel
the meeting.

Live Agenda/Minutes:
https://docs.google.com/document/d/1qFsOpvbyLzhflJbbv4Vl__497pKHDoUCy9hjAveyCX0/edit?usp=sharing

Shared Folder:
https://drive.google.com/drive/folders/1j6d0FLeOjiMil1Ellb59AsfHdzuWdAAc?usp=sharing

___________________________________________________________
Join Microsoft Teams Meeting (
https://teams.microsoft.com/l/meetup-join/19%3ameeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d
)
+1 321-558-6518 ( tel:+1 321-558-6518,,458216365# ) United States,
Orlando (Toll)
Conference ID: 458 216 365#
Local numbers (
https://dialin.teams.microsoft.com/325d775d-c910-441e-90d0-353ebaa56cdd?id=458216365
) | Reset PIN ( https://mysettings.lync.com/pstnconferencing ) | Learn
more about Teams ( https://aka.ms/JoinTeamsMeeting ) | Meeting options
(
https://teams.microsoft.com/meetingOptions/?organizerId=841a7c92-7816-4faf-9887-5e334e88f6d8&tenantId=af0096d9-700c-411a-b795-b3dd7122bad2&threadId=19_meeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw@thread.v2&messageId=0&language=en-US
)


Cheers,
Jukka


Re: #ble #ble

Chettimada, Vinayak Kariappa
 

Hi Carl,

Thank you for reporting the issue. You may send a pull request to fix accordingly and I will be glad to review the same.

As this is a bug, we could get this in for the 2.6 release.

Regards,
Vinayak


From: devel@... <devel@...> on behalf of Carl Stehle via lists.zephyrproject.org <droid=appception.com@...>
Sent: Thursday, May 27, 2021 7:28:17 AM
To: devel@... <devel@...>
Subject: [Zephyr-devel] #ble
 

I was unable to consistently set BLE Periodic Advertising Data, so had a look at:

subsys/bluetooth/controller/ll_sw/ull_adv_sync.c: adv_sync_hdr_set_clear()
(this is with recent commit f5c6afeccb53e4121ba5e97294cf589a752623d9)

I noticed 2 potential issues:

1. ter_hdr_prev = *ter_hdr;

If the Extended Header Length is 0, this can copy data (first byte of Adv Data) with misleading results. One workaround would be to replace that line with:

if (ter_com_hdr_prev->ext_hdr_len) {
  ter_hdr_prev = *ter_hdr;
} else {
  memset(&ter_hdr_prev, 0, sizeof(ter_hdr_prev));
}

2. ter_len = ull_adv_aux_hdr_len_calc(ter_com_hdr, &ter_dptr);

This can reset ter_dptr if the Extended Header Length is 0 so that it has the same value as ter_hdr. So ter_hdr should not be used after this call without first checking for non-zero Extended Header length (either ter_com_hdr->ext_hdr_len non-zero or that ter_hdr differs from ter_dptr).

Regards,
Carl



#ble #ble

Carl Stehle
 


I was unable to consistently set BLE Periodic Advertising Data, so had a look at:

subsys/bluetooth/controller/ll_sw/ull_adv_sync.c: adv_sync_hdr_set_clear()
(this is with recent commit f5c6afeccb53e4121ba5e97294cf589a752623d9)

I noticed 2 potential issues:

1. ter_hdr_prev = *ter_hdr;

If the Extended Header Length is 0, this can copy data (first byte of Adv Data) with misleading results. One workaround would be to replace that line with:

if (ter_com_hdr_prev->ext_hdr_len) {
  ter_hdr_prev = *ter_hdr;
} else {
  memset(&ter_hdr_prev, 0, sizeof(ter_hdr_prev));
}

2. ter_len = ull_adv_aux_hdr_len_calc(ter_com_hdr, &ter_dptr);

This can reset ter_dptr if the Extended Header Length is 0 so that it has the same value as ter_hdr. So ter_hdr should not be used after this call without first checking for non-zero Extended Header length (either ter_com_hdr->ext_hdr_len non-zero or that ter_hdr differs from ter_dptr).

Regards,
Carl



Cancelled Event: Zephyr Project: Dev Meeting - Thursday, May 27, 2021 #cal-cancelled

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

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, May 27, 2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Zephyr Project: APIs - Tue, 05/25/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 25 May 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


API meeting: agenda

Carles Cufi
 


Cancelled Event: Zephyr Memory Footprint - biweekly discussion - Monday, 24 May 2021 #cal-cancelled

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

Cancelled: Zephyr Memory Footprint - biweekly discussion

This event has been cancelled.

When:
Monday, 24 May 2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:
Working doc: https://docs.google.com/document/d/1bnQLJKVhgI3zkk3MsSXun8onEsA8z1Rf5ohdbCHASmU/edit#heading=h.x36xe8bnwr9r

________________________________________________________________________________
Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meeting
Or call in (audio only)
+1 321-558-6518,,546018126# United States, Orlando
Phone Conference ID: 546 018 126#
 
 
________________________________________________________________________________


Vscode windows settings for zephyr

Joris Offouga
 

Hello all,

I would like to know if it is possible to get vscode settings for zephyr ? , platformio is not flexible enough so that I can use the master branch of zephyr.

--
Best Regards,

Joris Offouga


Re: DT label vs nodelabel

Bolivar, Marti
 

Kevin Townsend <kevin.townsend@linaro.org> writes:

Hi Marti,

On Sat, 22 May 2021 at 00:35, Bolivar, Marti <Marti.Bolivar@nordicsemi.no>
wrote:


I get why you're asking this, but I don't think the project is totally
sold on discussions yet; is it?
I remember on a recent TSC call, Anas making the point (or perhaps it was
Maureen?) that GitHub Discussions is still quite different than Slack or
the mailing list, but that it might be a good long term repository of
sticky issues like this that people can more easily stumble across.
Yep, I was there too, but I don't recall that being a project-wide
decision. As far as I know, GitHub discussions are still in beta and
Zephyr is just experimenting with them.

It felt like a sensible suggestion to me, and this comment seemed like a
good use case given how obscure DT can feel to new users.
I personally do not use or monitor GitHub Discussions. I watch Slack,
the mailing list, and any issues and PRs that get thrown my way.

If the TSC decides to add discussions to the list of official places
Zephyr gets Zephyred, I guess I'll have no choice but to wade in at that
point ;).

But the above are already more than enough for me already ...


Kevin

PS: Sorry to hijack a useful discussion!
This is a good discussion too and I get where you're going, I just don't
want to start having to read discussions yet :).


Re: DT label vs nodelabel

Kevin Townsend
 

Hi Marti,

On Sat, 22 May 2021 at 00:35, Bolivar, Marti <Marti.Bolivar@...> wrote:

I get why you're asking this, but I don't think the project is totally
sold on discussions yet; is it?

I remember on a recent TSC call, Anas making the point (or perhaps it was Maureen?) that GitHub Discussions is still quite different than Slack or the mailing list, but that it might be a good long term repository of sticky issues like this that people can more easily stumble across. 

It felt like a sensible suggestion to me, and this comment seemed like a good use case given how obscure DT can feel to new users.

Kevin

PS: Sorry to hijack a useful discussion!


Re: DT label vs nodelabel

Bolivar, Marti
 

Marti Bolivar <marti.bolivar@nordicsemi.no> writes:

Hi Kevin,

Kevin Townsend <kevin.townsend@linaro.org> writes:

Hi Martí,

Thanks for the historical context.

Seems like something worth putting into a GitHub ´discussion’ thread on the
main zephyr repo for future access and updates, since DT in general has a
learning curve for new users?
I get why you're asking this, but I don't think the project is totally
sold on discussions yet; is it?

The mailing list is still the only official place for discussions like
this that has archives.
I should also mention that I'm going to be giving a talk on the 2.5
device model that will cover all of this:

https://github.com/zephyrproject-rtos/zephyr/wiki/2021-Zephyr-Developer-Summit#tuesday-june-8

I'm hoping the recording of that will be something we can link to for
newcomers at some point.



Kevin


Re: DT label vs nodelabel

Kevin Townsend
 

Hi Martí,

Thanks for the historical context. 

Seems like something worth putting into a GitHub ´discussion’ thread on the main zephyr repo for future access and updates, since DT in general has a learning curve for new users?

Kevin


Re: DT label vs nodelabel

Bolivar, Marti
 

Hi Kevin,

Kevin Townsend <kevin.townsend@linaro.org> writes:

Hi Martí,

Thanks for the historical context.

Seems like something worth putting into a GitHub ´discussion’ thread on the
main zephyr repo for future access and updates, since DT in general has a
learning curve for new users?
I get why you're asking this, but I don't think the project is totally
sold on discussions yet; is it?

The mailing list is still the only official place for discussions like
this that has archives.


Kevin


Re: DT label vs nodelabel

Bolivar, Marti
 

Hi Mike,

"Michael Rosen via lists.zephyrproject.org"
<michael.r.rosen=intel.com@lists.zephyrproject.org> writes:

Hey,

In Zephyr's devicetree, there are two separate concepts when it comes
to naming a node with a unique name: label property and node label. Is
there a design reason why these two have been kept separate or is it
just historic?
TL;DR it's historic.

Details:

The 'label property' and 'node label' concepts come from the devicetree
specification itself. The way they've been used in Zephyr is historic.

Label properties were used first because they work better with how
Zephyr's device model was historically defined. You can use node labels
now also as a result of various changes to the DT tooling and the device
model.

The device_get_binding() function predates the use of devicetree/DT in
zephyr. When DT support was added, 'struct device' objects started being
defined from DT nodes. Since device_get_binding() was what was available
to get a device, it was necessary to associate a string with each node
to be able to pass to device_get_binding() and get the actual device
struct.

Before v2.3, there was no concept of a 'node identifier' in the DT API.

There wasn't even really an "API" for devicetree; users had to use the
generated macros directly.

Starting with v2.3, you can use node labels to get node identifiers, but
in v2.3 and v2.4 you still had to get a label property to pass to
device_get_binding(), like so:

my_device = device_get_binding(DT_LABEL(DT_NODELABEL(my_node_label)));

In v2.5, DEVICE_DT_GET() and friends were added, and all of the in-tree
device drivers were reworked to support them. Since then, you can just
get the device directly at build time:

my_device = DEVICE_DT_GET(DT_NODELABEL(my_node_label));

The "old" way with device_get_binding() is still supported for
compatibility.

It seems to me it would be more convenient to leverage devicetree's
node label feature to provide each node that needs to be accessed the
string version of that label for use as DT_LABEL is used.
I'm not sure what you mean.

When it comes to getting device structs, there is no need to get the
node label as a string now that DT_NODELABEL() and DEVICE_DT_GET()
exist.

I have a pet project to remove device_get_binding() from all the
samples, to make this more obvious. I managed to get
https://github.com/zephyrproject-rtos/zephyr/pull/34589 merged in time
for v2.6, and will continue the project once the v2.7 merge window
opens.

There are a few edge cases where device_get_binding() is still required,
but most of the time, it's not necessary and is in fact better not to
use it.

I understand that while label properties don't need to be unique (ie,
not enforced by devicetree to be unique unlike node label), for how
they are typically used (device_get_binding), they do need to be
unique (which devicetree can enforce if node label were used instead).
Kumar has an open PR for enforcing unique label properties, FYI:

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

In a project I am working on, theres many new devicetree nodes which
would be nice to have a nicer name for debugging available in C than
the full path (the node name isnt unique due to the structure of the
device tree, a lot of the nodes are something like nodelabel1:
generic_name@0, nodelabel2: generic_name@1) and it would be nice if we
could just leverage the node label we are adding to the devicetree
rather than also adding an additional label property (I have been
thinking of making a patch to access node label as a string from the
node id and wondered if I should do it with the intention of replacing
the label property in Zephyr entirely or not).
One problem is that while node labels *are* unique, an individual node
may have zero, one, or many node labels, so saying "the" node label for
a node doesn't quite work in the general case. There might not be a node
label, or there might be more than one.

So I think node labels are not suitable for replacing the label property
entirely, but at the same time, label properties are increasingly
optional at this point.

That said, if you would like to propose devicetree.h API extensions that
can handle all the 0/1/many node labels cases and provide node labels as
strings for debugging use, please send a PR! We can try to merge it for
2.7 when the merge window opens up again.

Thanks,
Martí


Thanks,
Mike


-------------------------------------
Michael R Rosen
Firmware Engineer
Emerging Growth Incubation
RNB3-M1
Santa Clara, CA | 95054





Re: DT label vs nodelabel

Michael Rosen
 

I havent done it yet sorry; I was hoping to get a better understanding of the reason they are separate before going with one solution (just make node label available as a string separately or change it so label comes from node label instead of the label property).

 

From: devel@... <devel@...> On Behalf Of Martin Schröder
Sent: Friday, May 21, 2021 2:23 PM
To: Rosen, Michael R <michael.r.rosen@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] DT label vs nodelabel

 

Hi Michael,

Where can I find your patch? I'm interested in it as well. 

On May 21, 2021, at 09:00 PM, Michael Rosen <michael.r.rosen@...> wrote:

Hey,

 

In Zephyr’s devicetree, there are two separate concepts when it comes to naming a node with a unique name: label property and node label. Is there a design reason why these two have been kept separate or is it just historic?

 

It seems to me it would be more convenient to leverage devicetree’s node label feature to provide each node that needs to be accessed the string version of that label for use as DT_LABEL is used. I understand that while label properties don’t need to be unique (ie, not enforced by devicetree to be unique unlike node label), for how they are typically used (device_get_binding), they do need to be unique (which devicetree can enforce if node label were used instead). In a project I am working on, theres many new devicetree nodes which would be nice to have a nicer name for debugging available in C than the full path (the node name isnt unique due to the structure of the device tree, a lot of the nodes are something like nodelabel1: generic_name@0, nodelabel2: generic_name@1) and it would be nice if we could just leverage the node label we are adding to the devicetree rather than also adding an additional label property (I have been thinking of making a patch to access node label as a string from the node id and wondered if I should do it with the intention of replacing the label property in Zephyr entirely or not).

 

Thanks,

Mike

 

 

-------------------------------------

Michael R Rosen

Firmware Engineer

Emerging Growth Incubation

RNB3-M1

Santa Clara, CA | 95054

 

 


Re: DT label vs nodelabel

Martin Schröder
 

Hi Michael,

Where can I find your patch? I'm interested in it as well. 


On May 21, 2021, at 09:00 PM, Michael Rosen <michael.r.rosen@...> wrote:

Hey,

 

In Zephyr’s devicetree, there are two separate concepts when it comes to naming a node with a unique name: label property and node label. Is there a design reason why these two have been kept separate or is it just historic?

 

It seems to me it would be more convenient to leverage devicetree’s node label feature to provide each node that needs to be accessed the string version of that label for use as DT_LABEL is used. I understand that while label properties don’t need to be unique (ie, not enforced by devicetree to be unique unlike node label), for how they are typically used (device_get_binding), they do need to be unique (which devicetree can enforce if node label were used instead). In a project I am working on, theres many new devicetree nodes which would be nice to have a nicer name for debugging available in C than the full path (the node name isnt unique due to the structure of the device tree, a lot of the nodes are something like nodelabel1: generic_name@0, nodelabel2: generic_name@1) and it would be nice if we could just leverage the node label we are adding to the devicetree rather than also adding an additional label property (I have been thinking of making a patch to access node label as a string from the node id and wondered if I should do it with the intention of replacing the label property in Zephyr entirely or not).

 

Thanks,

Mike

 

 

-------------------------------------

Michael R Rosen

Firmware Engineer

Emerging Growth Incubation

RNB3-M1

Santa Clara, CA | 95054

 

 


DT label vs nodelabel

Michael Rosen
 

Hey,

 

In Zephyr’s devicetree, there are two separate concepts when it comes to naming a node with a unique name: label property and node label. Is there a design reason why these two have been kept separate or is it just historic?

 

It seems to me it would be more convenient to leverage devicetree’s node label feature to provide each node that needs to be accessed the string version of that label for use as DT_LABEL is used. I understand that while label properties don’t need to be unique (ie, not enforced by devicetree to be unique unlike node label), for how they are typically used (device_get_binding), they do need to be unique (which devicetree can enforce if node label were used instead). In a project I am working on, theres many new devicetree nodes which would be nice to have a nicer name for debugging available in C than the full path (the node name isnt unique due to the structure of the device tree, a lot of the nodes are something like nodelabel1: generic_name@0, nodelabel2: generic_name@1) and it would be nice if we could just leverage the node label we are adding to the devicetree rather than also adding an additional label property (I have been thinking of making a patch to access node label as a string from the node id and wondered if I should do it with the intention of replacing the label property in Zephyr entirely or not).

 

Thanks,

Mike

 

 

-------------------------------------

Michael R Rosen

Firmware Engineer

Emerging Growth Incubation

RNB3-M1

Santa Clara, CA | 95054

 

 


Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 20 May 2021 #cal-cancelled

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

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 20 May 2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Driver runtime expectation

lairdjm
 

Hi,

I have a query on drivers in the zephyr code base  in regards to interrupt handling that I am seeking advice on: should a driver in zephyr upon getting an unknown interrupt self-destruct itself, i.e. purposely stop itself from working even if the interrupt could be ignored and continue functioning as normal? Is this documented anywhere as a base for developing drivers?

Thanks,

Jamie


Cancelled Event: Zephyr Project: APIs - Tuesday, 18 May 2021 #cal-cancelled

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

Cancelled: Zephyr Project: APIs

This event has been cancelled.

When:
Tuesday, 18 May 2021
4:00pm to 5:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________

121 - 140 of 7903