Date   

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
 
 
________________________________________________________________________________


API documentation changes

Gerard Marull Paretas
 

Hi,

I have opened a PR that introduces an important change in the documentation build. We will now enable by default the :member: option in the Doxygen directives. This means that all public members (e.g. struct fields) will be automatically displayed.

To prevent accidental exposure of private API content, I encourage all API maintainers to check if the resulting documentation contains the expected information.


Thanks,

--

Gerard Marull-Paretas
Teslabs Engineering S.L.
teslabs.com T. +34 622 321 312

CONFIDENTIALITY NOTICE:
The contents of this email message and any attachments are intended solely for the addressee(s)
and may contain confidential and/or privileged information and may be legally protected from
disclosure. If you are not the intended recipient of this message or their agent, or if this message
has been addressed to you in error, please immediately alert the sender by reply email and then
delete this message and any attachments. If you are not the intended recipient, you are hereby
notified that any use, dissemination, copying, or storage of this message or its attachments is
strictly prohibited. 


Zephyr: Toolchain Working Group - Mon, 05/17/2021 #cal-notice

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

Zephyr: Toolchain Working Group

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

Where:
Microsoft Teams Meeting

Description:

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


Zephyr: Toolchain Working Group - Mon, 05/17/2021 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Toolchain Working Group

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

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: Torsten Rasmussen

Description:

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


Re: Review of concept of changing UART flow control from Kconfig to DTS config

lairdjm
 

Hi,

In all of our modules, UART 0 is the primary UART. We have 8 boards in Zephyr, so we should plan to enable flow control on all those 8 boards and then add 8 overlays to most sample projects to disable flow control and future projects that we create? This is what I mean by a mess, what could previously be done in one file now needs as many files as boards, it also means that each time a new board is added, we have to go and add a new overlay to all of those areas again.

Will need to look into the function to enable/disable it to see how that works and how we can incorporate that into projects but the original Kconfig system worked fine with no issues.

Thanks,

Jamie

 

From: Chruściński, Krzysztof <Krzysztof.Chruscinski@...>
Sent: 17 May 2021 07:31
To: Bolivar, Marti <Marti.Bolivar@...>; Jamie Mccrae <Jamie.Mccrae@...>; devel@...
Subject: ODP: [Zephyr-devel] Review of concept of changing UART flow control from Kconfig to DTS config

 

Hi Jaime,

 

i've moved flow control to DTS as property already existed (https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/serial/uart-controller.yaml) so this approach is more generic since Kconfig option was nordic specific. Note that you can have flow control enabled by default in a board dts file but then delete the property in the overlay with "/delete-property/ hw-flow-ctrl". Also it is an initial condition and you can control flow control at runtime with uart_configure() as long as CTS,RTS pins are set.

 

regards,

Krzysztof

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures. - zephyrproject-rtos/zephyr

github.com

 


Od: Bolivar, Marti <Marti.Bolivar@...>
Wysłane: piątek, 14 maja 2021 22:46
Do: Jamie Mccrae <Jamie.Mccrae@...>; devel@... <devel@...>
DW: Chruściński, Krzysztof <Krzysztof.Chruscinski@...>
Temat: RE: [Zephyr-devel] Review of concept of changing UART flow control from Kconfig to DTS config

 

Hi Jaime,

Jamie Mccrae <Jamie.Mccrae@...> writes:

> Hi Marti,
> Let's say there is a board (all our boards are Nordic-based so this
> applies to all of them) which has a UART brought out to a header, the
> UART might be used for a multitude of things, it could be a debug port
> which is mostly unused, or it could be connected to a PC for
> exchanging a lot of data, or it could be connected to a shield,
> perhaps a modem, which does not have flow control pins - this is one
> board (and one .dts file) but with different requirements for flow
> control, in the old system this worked fine and flow control could be
> enabled or disabled on a per-project configuration or even by
> board/shield overlays (one board but many different projects). With
> the new system, that isn't possible, this requires unique board .dts
> files because you can no longer disable or enable flow control via a
> Kconfig option

I think we might be talking past each other but I think I'm finally
getting what you mean.

It does sound like we agree that:

- dts/arm/nordic/*.dtsi sets hw-flow-control to 'false' by default,
  meaning flow control is opt-in at the SoC level

- boards/arm/.../BOARD.dts files can still set per-board defaults for
  hw-flow-control for each uart node, so it's up to the board maintainer
  to decide if they want to change that default

- each 'project' (Zephyr application) can still change that using a DTS
  overlay

> (yet strangely parity is still a Kconfig option, the
> change itself doesn't really make sense to me).

I agree that seems like some future work to move to DT but it was
probably out of scope for PR #25999. I'll leave it to Krzysztof to
comment on whether he'll be moving parity to DT also.

> The issue is not that it is opt-in or opt-out, the issue is that it is
> opt-in at a DTS level (and thus a board level) and not opt-in at a
> project level. If we enable flow control for our board, we need to add
> overlays to every sample project for all of our boards whereby flow
> control isn't needed which becomes a mess.

The Kconfig options that are gone now were per-instance
(UART_0_NRF_FLOW_CONTROL, UART_1_NRF_FLOW_CONTROL, etc.), so I'm still
confused about what you were doing that used to work on a "project" wide
basis that no longer does.

If you were doing something like this in <app>/Kconfig:

        config UART_1_NRF_FLOW_CONTROL
                default y if BOARD_MY_BOARD

        source "Kconfig.zephyr"

Then you can just move that same setting to <app>/boards/my_board.overlay.

If you were doing something like this:

        config UART_1_NRF_FLOW_CONTROL
                default y if SOC_FAMILY_NRF

        source "Kconfig.zephyr"

Then unless *all* of your boards use UART 1 in the same way for that
purpose, this seems like an unsafe thing to do.

So I still don't get what you are trying to say; can you please provide
a sample of what you were doing before to make this concrete?

Thanks,
Martí

> Thanks,
> Jamie
>
> -----Original Message-----
> From: Bolivar, Marti <Marti.Bolivar@...>
> Sent: 13 May 2021 17:11
> To: Jamie Mccrae <Jamie.Mccrae@...>; devel@...
> Cc: Chruściński, Krzysztof <Krzysztof.Chruscinski@...>
> Subject: Re: [Zephyr-devel] Review of concept of changing UART flow control from Kconfig to DTS config
>
> EXTERNAL EMAIL: Be careful with attachments and links.
>
> Hi (and +Krzysztof in Cc),
>
> "lairdjm via lists.zephyrproject.org"
> <jamie.mccrae=lairdconnect.com@...> writes:
>
>> Hi,
>> I only noticed today that the Kconfig option for enabling hardware
>> flow control on UARTs, which used to be an optional Kconfig option,
>> was removed and replaced with a DTS boards file configuration option
>> instead, as per
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F25999&amp;data=04%7C01%7CKrzysztof.Chruscinski%40nordicsemi.no%7C6fd3411e84a24205ff2d08d917196548%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637566220104051473%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wcMCORctdAegU0i9hWQGQ97aYPQUfCNjLmQDuwi83zM%3D&amp;reserved=0
>
> To be clear, this PR is limited to nRF SoCs only, it is not a project-wide change.
>
>> I find this to be a bit of a step backwards for application
>> development, we have many boards in zephyr that we and customers use,
>> these boards might be used for something simple like a sensor or might
>> be used alongside a PC for doing some heavy processing and message
>> passing over Bluetooth, so with a sensor, the log system might be
>> active but it won't have anything connected to it most of the time
>> unless there's an issue, so flow control is not required here, if it's
>> enabled then it's going to cause an issue once the UART buffer gets
>> full. However, on a PC communications module, that would be using the
>> UART constantly, and need data integrity so needs flow control - in
>> the old system, the boards file would have the flow control pins and
>> it would be disabled by default, a project could enable it with a
>> Kconfig option, this was great. However with the new system, it seems
>> that we need to force flow control on all our boards, and then in
>> instances where it's not needed, have an overlay for that specific
>> board (and we have many boards) to delete the hardware flow control
>> part. This means that to enable hardware flow control, we need to
>> update our boards file then add an overlay to almost every sample
>> application in zephyr for most of our boards to disable flow control.
>> This seems a bit chaotic to me so I would like to revisit this concept
>> of having flow control configurable as a Kconfig option, the pins
>> should be defined in the DTS file which hasn't changed but if flow
>> control is needed or not should be controlled on a project basis, opt
>> in not opt out.
>
> I'm having a bit of trouble understanding what you mean here.
>
> The boolean hw-flow-control property is still available for enabling hardware flow control for both UART and UARTE:
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zephyrproject.org%2Flatest%2Freference%2Fdevicetree%2Fbindings%2Fserial%2Fnordic%252Cnrf-uarte.html%23dtbinding-nordic-nrf-uarte&amp;data=04%7C01%7CKrzysztof.Chruscinski%40nordicsemi.no%7C6fd3411e84a24205ff2d08d917196548%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637566220104061477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=X3jtha%2Fd2i4tieieSIPZIrphsrRS9XqT%2Fw9yrF2ng5s%3D&amp;reserved=0
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zephyrproject.org%2Flatest%2Freference%2Fdevicetree%2Fbindings%2Fserial%2Fnordic%252Cnrf-uart.html%23dtbinding-nordic-nrf-uart&amp;data=04%7C01%7CKrzysztof.Chruscinski%40nordicsemi.no%7C6fd3411e84a24205ff2d08d917196548%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637566220104061477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wxmcD7efAxynMqjWpb2EsSOIjCXMTIXHi8YxN93AQF4%3D&amp;reserved=0
>
> Looking at the code, if hw-flow-control is disabled in DTS (the default), then in both drivers cfg->flow_ctrl is false. The HAL configuration structure ends up with flow control disabled in that case:
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fblob%2F5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1%2Fdrivers%2Fserial%2Fuart_nrfx_uart.c%23L346&amp;data=04%7C01%7CKrzysztof.Chruscinski%40nordicsemi.no%7C6fd3411e84a24205ff2d08d917196548%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637566220104061477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6u1UkJ4CE%2Bp%2FcvW25jdfjTdF6fli6txIjYSXRIgrVBc%3D&amp;reserved=0
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fblob%2F5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1%2Fdrivers%2Fserial%2Fuart_nrfx_uarte.c%23L397&amp;data=04%7C01%7CKrzysztof.Chruscinski%40nordicsemi.no%7C6fd3411e84a24205ff2d08d917196548%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637566220104061477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=oFEKmFPzlWFnncv1%2FtrLmnMXVcK0ocJD9eBpO709zt8%3D&amp;reserved=0
>
> So flow control at a SoC level seems to be turned off by default.
>
> It's true that many boards in PR #25999 do enable it by default, e.g.
> nRF52840-DK:
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F25999%2Ffiles%23diff-f496b12068cf78fdbb22c1b8a4eaeb66010db95b4e80db7377a340ae30a83519R7&amp;data=04%7C01%7CKrzysztof.Chruscinski%40nordicsemi.no%7C6fd3411e84a24205ff2d08d917196548%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637566220104061477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uHwoUaYpNQQRM9HGTkQf%2FQB2KpLsqHVF7BcN4dYWe%2FA%3D&amp;reserved=0
>
> But it seems like at a board maintainer level, you can leave the SoC default as-is to make flow control "opt in" as requested.
>
>>
>> Are there any thoughts on this subject and how to get this working,
>> focused on ease of being able to set this for ours and customer's
>> reuse?
>
> It looks like flow control is off by default and it's opt-in; what did I miss?
>
> Thanks!
> Martí
>
>> Thanks,
>> Jamie
>>
>>
>>
> THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.


ODP: [Zephyr-devel] Review of concept of changing UART flow control from Kconfig to DTS config

Chruściński, Krzysztof
 

Hi Jaime,

i've moved flow control to DTS as property already existed (https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/serial/uart-controller.yaml) so this approach is more generic since Kconfig option was nordic specific. Note that you can have flow control enabled by default in a board dts file but then delete the property in the overlay with "/delete-property/ hw-flow-ctrl". Also it is an initial condition and you can control flow control at runtime with uart_configure() as long as CTS,RTS pins are set.

regards,
Krzysztof
Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures. - zephyrproject-rtos/zephyr
github.com


Od: Bolivar, Marti <Marti.Bolivar@...>
Wysłane: piątek, 14 maja 2021 22:46
Do: Jamie Mccrae <Jamie.Mccrae@...>; devel@... <devel@...>
DW: Chruściński, Krzysztof <Krzysztof.Chruscinski@...>
Temat: RE: [Zephyr-devel] Review of concept of changing UART flow control from Kconfig to DTS config
 
Hi Jaime,

Jamie Mccrae <Jamie.Mccrae@...> writes:

> Hi Marti,
> Let's say there is a board (all our boards are Nordic-based so this
> applies to all of them) which has a UART brought out to a header, the
> UART might be used for a multitude of things, it could be a debug port
> which is mostly unused, or it could be connected to a PC for
> exchanging a lot of data, or it could be connected to a shield,
> perhaps a modem, which does not have flow control pins - this is one
> board (and one .dts file) but with different requirements for flow
> control, in the old system this worked fine and flow control could be
> enabled or disabled on a per-project configuration or even by
> board/shield overlays (one board but many different projects). With
> the new system, that isn't possible, this requires unique board .dts
> files because you can no longer disable or enable flow control via a
> Kconfig option

I think we might be talking past each other but I think I'm finally
getting what you mean.

It does sound like we agree that:

- dts/arm/nordic/*.dtsi sets hw-flow-control to 'false' by default,
  meaning flow control is opt-in at the SoC level

- boards/arm/.../BOARD.dts files can still set per-board defaults for
  hw-flow-control for each uart node, so it's up to the board maintainer
  to decide if they want to change that default

- each 'project' (Zephyr application) can still change that using a DTS
  overlay

> (yet strangely parity is still a Kconfig option, the
> change itself doesn't really make sense to me).

I agree that seems like some future work to move to DT but it was
probably out of scope for PR #25999. I'll leave it to Krzysztof to
comment on whether he'll be moving parity to DT also.

> The issue is not that it is opt-in or opt-out, the issue is that it is
> opt-in at a DTS level (and thus a board level) and not opt-in at a
> project level. If we enable flow control for our board, we need to add
> overlays to every sample project for all of our boards whereby flow
> control isn't needed which becomes a mess.

The Kconfig options that are gone now were per-instance
(UART_0_NRF_FLOW_CONTROL, UART_1_NRF_FLOW_CONTROL, etc.), so I'm still
confused about what you were doing that used to work on a "project" wide
basis that no longer does.

If you were doing something like this in <app>/Kconfig:

        config UART_1_NRF_FLOW_CONTROL
                default y if BOARD_MY_BOARD

        source "Kconfig.zephyr"

Then you can just move that same setting to <app>/boards/my_board.overlay.

If you were doing something like this:

        config UART_1_NRF_FLOW_CONTROL
                default y if SOC_FAMILY_NRF

        source "Kconfig.zephyr"

Then unless *all* of your boards use UART 1 in the same way for that
purpose, this seems like an unsafe thing to do.

So I still don't get what you are trying to say; can you please provide
a sample of what you were doing before to make this concrete?

Thanks,
Martí

> Thanks,
> Jamie
>

> -----Original Message-----
> From: Bolivar, Marti <Marti.Bolivar@...>
> Sent: 13 May 2021 17:11
> To: Jamie Mccrae <Jamie.Mccrae@...>; devel@...
> Cc: Chruściński, Krzysztof <Krzysztof.Chruscinski@...>
> Subject: Re: [Zephyr-devel] Review of concept of changing UART flow control from Kconfig to DTS config
>
> EXTERNAL EMAIL: Be careful with attachments and links.
>
> Hi (and +Krzysztof in Cc),
>
> "lairdjm via lists.zephyrproject.org"
> <jamie.mccrae=lairdconnect.com@...> writes:
>
>> Hi,
>> I only noticed today that the Kconfig option for enabling hardware
>> flow control on UARTs, which used to be an optional Kconfig option,
>> was removed and replaced with a DTS boards file configuration option
>> instead, as per
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F25999&amp;data=04%7C01%7CKrzysztof.Chruscinski%40nordicsemi.no%7C6fd3411e84a24205ff2d08d917196548%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637566220104051473%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wcMCORctdAegU0i9hWQGQ97aYPQUfCNjLmQDuwi83zM%3D&amp;reserved=0
>
> To be clear, this PR is limited to nRF SoCs only, it is not a project-wide change.
>
>> I find this to be a bit of a step backwards for application
>> development, we have many boards in zephyr that we and customers use,
>> these boards might be used for something simple like a sensor or might
>> be used alongside a PC for doing some heavy processing and message
>> passing over Bluetooth, so with a sensor, the log system might be
>> active but it won't have anything connected to it most of the time
>> unless there's an issue, so flow control is not required here, if it's
>> enabled then it's going to cause an issue once the UART buffer gets
>> full. However, on a PC communications module, that would be using the
>> UART constantly, and need data integrity so needs flow control - in
>> the old system, the boards file would have the flow control pins and
>> it would be disabled by default, a project could enable it with a
>> Kconfig option, this was great. However with the new system, it seems
>> that we need to force flow control on all our boards, and then in
>> instances where it's not needed, have an overlay for that specific
>> board (and we have many boards) to delete the hardware flow control
>> part. This means that to enable hardware flow control, we need to
>> update our boards file then add an overlay to almost every sample
>> application in zephyr for most of our boards to disable flow control.
>> This seems a bit chaotic to me so I would like to revisit this concept
>> of having flow control configurable as a Kconfig option, the pins
>> should be defined in the DTS file which hasn't changed but if flow
>> control is needed or not should be controlled on a project basis, opt
>> in not opt out.
>
> I'm having a bit of trouble understanding what you mean here.
>
> The boolean hw-flow-control property is still available for enabling hardware flow control for both UART and UARTE:
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zephyrproject.org%2Flatest%2Freference%2Fdevicetree%2Fbindings%2Fserial%2Fnordic%252Cnrf-uarte.html%23dtbinding-nordic-nrf-uarte&amp;data=04%7C01%7CKrzysztof.Chruscinski%40nordicsemi.no%7C6fd3411e84a24205ff2d08d917196548%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637566220104061477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=X3jtha%2Fd2i4tieieSIPZIrphsrRS9XqT%2Fw9yrF2ng5s%3D&amp;reserved=0
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zephyrproject.org%2Flatest%2Freference%2Fdevicetree%2Fbindings%2Fserial%2Fnordic%252Cnrf-uart.html%23dtbinding-nordic-nrf-uart&amp;data=04%7C01%7CKrzysztof.Chruscinski%40nordicsemi.no%7C6fd3411e84a24205ff2d08d917196548%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637566220104061477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wxmcD7efAxynMqjWpb2EsSOIjCXMTIXHi8YxN93AQF4%3D&amp;reserved=0
>
> Looking at the code, if hw-flow-control is disabled in DTS (the default), then in both drivers cfg->flow_ctrl is false. The HAL configuration structure ends up with flow control disabled in that case:
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fblob%2F5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1%2Fdrivers%2Fserial%2Fuart_nrfx_uart.c%23L346&amp;data=04%7C01%7CKrzysztof.Chruscinski%40nordicsemi.no%7C6fd3411e84a24205ff2d08d917196548%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637566220104061477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6u1UkJ4CE%2Bp%2FcvW25jdfjTdF6fli6txIjYSXRIgrVBc%3D&amp;reserved=0
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fblob%2F5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1%2Fdrivers%2Fserial%2Fuart_nrfx_uarte.c%23L397&amp;data=04%7C01%7CKrzysztof.Chruscinski%40nordicsemi.no%7C6fd3411e84a24205ff2d08d917196548%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637566220104061477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=oFEKmFPzlWFnncv1%2FtrLmnMXVcK0ocJD9eBpO709zt8%3D&amp;reserved=0
>
> So flow control at a SoC level seems to be turned off by default.
>
> It's true that many boards in PR #25999 do enable it by default, e.g.
> nRF52840-DK:
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F25999%2Ffiles%23diff-f496b12068cf78fdbb22c1b8a4eaeb66010db95b4e80db7377a340ae30a83519R7&amp;data=04%7C01%7CKrzysztof.Chruscinski%40nordicsemi.no%7C6fd3411e84a24205ff2d08d917196548%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637566220104061477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uHwoUaYpNQQRM9HGTkQf%2FQB2KpLsqHVF7BcN4dYWe%2FA%3D&amp;reserved=0
>
> But it seems like at a board maintainer level, you can leave the SoC default as-is to make flow control "opt in" as requested.
>
>>
>> Are there any thoughts on this subject and how to get this working,
>> focused on ease of being able to set this for ours and customer's
>> reuse?
>
> It looks like flow control is off by default and it's opt-in; what did I miss?
>
> Thanks!
> Martí
>
>> Thanks,
>> Jamie
>>
>>
>>
> THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.


ODP: [Zephyr-devel] logging MACRO LOG_ERR/LOG_INF/LOG_DBG expansion issue

Chruściński, Krzysztof
 

Hi,

compiler is able to figure out things and remove code that is known not to be executed.

Code like this will disapear from the binary:

if ( 2 > 3) {
   foo();
}

It can even be more complex like here were constant comes from inline function:

static inline int f3(void)
{
    return 3;
}

if (2 > f3()) {
  foo();
}

regards,
Krzysztof

Od: devel@... <devel@...> w imieniu użytkownika qzhang via lists.zephyrproject.org <qzhang=ambiq.com@...>
Wysłane: piątek, 14 maja 2021 09:03
Do: devel@... <devel@...>
Temat: [Zephyr-devel] logging MACRO LOG_ERR/LOG_INF/LOG_DBG expansion issue
 
Hi,

I am new to zephyr, I am reading the logging subsystem code and find that 'LOG_ERR/LOG_INF/LOG_DBG ..., etc.' will be expanded finally by below MACRO

looks like even I disable the logging (not set CONFIG_LOG), below code is still remained in the code after the preprocessing, Is my understanding correct or not? does it cause the code bloat?  

/*****************************************************************************/
/****************** Macros for standard logging ******************************/
/*****************************************************************************/
#define Z_LOG2(_level, _source, _dsource, ...) do { \
if (!Z_LOG_CONST_LEVEL_CHECK(_level)) { \
break; \
} \
if (IS_ENABLED(CONFIG_LOG_MINIMAL)) { \
Z_LOG_TO_PRINTK(_level, __VA_ARGS__); \
break; \
} \
\
bool is_user_context = k_is_user_context(); \
uint32_t filters = IS_ENABLED(CONFIG_LOG_RUNTIME_FILTERING) ? \
(_dsource)->filters : 0;\
if (!LOG_CHECK_CTX_LVL_FILTER(is_user_context, _level, filters)) { \
break; \
} \
if (IS_ENABLED(CONFIG_LOG2)) { \
int _mode; \
void *_src = IS_ENABLED(CONFIG_LOG_RUNTIME_FILTERING) ? \
(void *)_dsource : (void *)_source; \
Z_LOG_MSG2_CREATE(UTIL_NOT(IS_ENABLED(CONFIG_USERSPACE)), _mode, \
  CONFIG_LOG_DOMAIN_ID, _src, _level, NULL,\
  0, __VA_ARGS__); \
} else { \
Z_LOG_INTERNAL(is_user_context, _level, \
_source, _dsource, __VA_ARGS__);\
} \
if (false) { \
/* Arguments checker present but never evaluated.*/ \
/* Placed here to ensure that __VA_ARGS__ are*/ \
/* evaluated once when log is enabled.*/ \
z_log_printf_arg_checker(__VA_ARGS__); \
} \
} while (false) 

Br
Quan


bluetooth init error -90

Smitha Ratnam <s.ratnam@...>
 

Hi,

We are trying to use the silicon labs thunderboard sense2 SLTB004A device with bluetooth. 
When we program the device the zephyr beacon sample, we get the following error:



* Booting Zephyr OS build zephyr-v2.5.0-3011-gb61c23943c6f  * Starting Beacon Demo Bluetooth init failed (err -19) [00:00:00.007,000] <err> bt_hci_core: No HCI driver registered
What are we supposed to do to get the bluetooth on the device initialised?
Does Zephyr support the device for bluetooth?

Thanks and regards,
Smitha.


Re: Review of concept of changing UART flow control from Kconfig to DTS config

Bolivar, Marti
 

Hi Jaime,

Jamie Mccrae <Jamie.Mccrae@lairdconnect.com> writes:

Hi Marti,
Let's say there is a board (all our boards are Nordic-based so this
applies to all of them) which has a UART brought out to a header, the
UART might be used for a multitude of things, it could be a debug port
which is mostly unused, or it could be connected to a PC for
exchanging a lot of data, or it could be connected to a shield,
perhaps a modem, which does not have flow control pins - this is one
board (and one .dts file) but with different requirements for flow
control, in the old system this worked fine and flow control could be
enabled or disabled on a per-project configuration or even by
board/shield overlays (one board but many different projects). With
the new system, that isn't possible, this requires unique board .dts
files because you can no longer disable or enable flow control via a
Kconfig option
I think we might be talking past each other but I think I'm finally
getting what you mean.

It does sound like we agree that:

- dts/arm/nordic/*.dtsi sets hw-flow-control to 'false' by default,
meaning flow control is opt-in at the SoC level

- boards/arm/.../BOARD.dts files can still set per-board defaults for
hw-flow-control for each uart node, so it's up to the board maintainer
to decide if they want to change that default

- each 'project' (Zephyr application) can still change that using a DTS
overlay

(yet strangely parity is still a Kconfig option, the
change itself doesn't really make sense to me).
I agree that seems like some future work to move to DT but it was
probably out of scope for PR #25999. I'll leave it to Krzysztof to
comment on whether he'll be moving parity to DT also.

The issue is not that it is opt-in or opt-out, the issue is that it is
opt-in at a DTS level (and thus a board level) and not opt-in at a
project level. If we enable flow control for our board, we need to add
overlays to every sample project for all of our boards whereby flow
control isn't needed which becomes a mess.
The Kconfig options that are gone now were per-instance
(UART_0_NRF_FLOW_CONTROL, UART_1_NRF_FLOW_CONTROL, etc.), so I'm still
confused about what you were doing that used to work on a "project" wide
basis that no longer does.

If you were doing something like this in <app>/Kconfig:

config UART_1_NRF_FLOW_CONTROL
default y if BOARD_MY_BOARD

source "Kconfig.zephyr"

Then you can just move that same setting to <app>/boards/my_board.overlay.

If you were doing something like this:

config UART_1_NRF_FLOW_CONTROL
default y if SOC_FAMILY_NRF

source "Kconfig.zephyr"

Then unless *all* of your boards use UART 1 in the same way for that
purpose, this seems like an unsafe thing to do.

So I still don't get what you are trying to say; can you please provide
a sample of what you were doing before to make this concrete?

Thanks,
Martí

Thanks,
Jamie

-----Original Message-----
From: Bolivar, Marti <Marti.Bolivar@nordicsemi.no>
Sent: 13 May 2021 17:11
To: Jamie Mccrae <Jamie.Mccrae@lairdconnect.com>; devel@lists.zephyrproject.org
Cc: Chruściński, Krzysztof <Krzysztof.Chruscinski@nordicsemi.no>
Subject: Re: [Zephyr-devel] Review of concept of changing UART flow control from Kconfig to DTS config

EXTERNAL EMAIL: Be careful with attachments and links.

Hi (and +Krzysztof in Cc),

"lairdjm via lists.zephyrproject.org"
<jamie.mccrae=lairdconnect.com@lists.zephyrproject.org> writes:

Hi,
I only noticed today that the Kconfig option for enabling hardware
flow control on UARTs, which used to be an optional Kconfig option,
was removed and replaced with a DTS boards file configuration option
instead, as per
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F25999&;data=04%7C01%7CMarti.Bolivar%40nordicsemi.no%7C5c1be122bb954defc40408d916c23c8e%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565846839519950%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=0W%2B%2BfqwljQG6qjP9QMhB8iurIcO7XVWYSWflTzQzr4o%3D&amp;reserved=0
To be clear, this PR is limited to nRF SoCs only, it is not a project-wide change.

I find this to be a bit of a step backwards for application
development, we have many boards in zephyr that we and customers use,
these boards might be used for something simple like a sensor or might
be used alongside a PC for doing some heavy processing and message
passing over Bluetooth, so with a sensor, the log system might be
active but it won't have anything connected to it most of the time
unless there's an issue, so flow control is not required here, if it's
enabled then it's going to cause an issue once the UART buffer gets
full. However, on a PC communications module, that would be using the
UART constantly, and need data integrity so needs flow control - in
the old system, the boards file would have the flow control pins and
it would be disabled by default, a project could enable it with a
Kconfig option, this was great. However with the new system, it seems
that we need to force flow control on all our boards, and then in
instances where it's not needed, have an overlay for that specific
board (and we have many boards) to delete the hardware flow control
part. This means that to enable hardware flow control, we need to
update our boards file then add an overlay to almost every sample
application in zephyr for most of our boards to disable flow control.
This seems a bit chaotic to me so I would like to revisit this concept
of having flow control configurable as a Kconfig option, the pins
should be defined in the DTS file which hasn't changed but if flow
control is needed or not should be controlled on a project basis, opt
in not opt out.
I'm having a bit of trouble understanding what you mean here.

The boolean hw-flow-control property is still available for enabling hardware flow control for both UART and UARTE:

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zephyrproject.org%2Flatest%2Freference%2Fdevicetree%2Fbindings%2Fserial%2Fnordic%252Cnrf-uarte.html%23dtbinding-nordic-nrf-uarte&;data=04%7C01%7CMarti.Bolivar%40nordicsemi.no%7C5c1be122bb954defc40408d916c23c8e%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565846839529903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=C9EI5WbaHSkWuLTC2UWStIEy3Ci%2Fu%2BzfHMYs25tJbOo%3D&amp;reserved=0
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zephyrproject.org%2Flatest%2Freference%2Fdevicetree%2Fbindings%2Fserial%2Fnordic%252Cnrf-uart.html%23dtbinding-nordic-nrf-uart&;data=04%7C01%7CMarti.Bolivar%40nordicsemi.no%7C5c1be122bb954defc40408d916c23c8e%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565846839529903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=p7RxoZRshUR6g4G%2BObmjzpwCkY4CmULrwJPMewLTbD0%3D&amp;reserved=0

Looking at the code, if hw-flow-control is disabled in DTS (the default), then in both drivers cfg->flow_ctrl is false. The HAL configuration structure ends up with flow control disabled in that case:

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fblob%2F5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1%2Fdrivers%2Fserial%2Fuart_nrfx_uart.c%23L346&;data=04%7C01%7CMarti.Bolivar%40nordicsemi.no%7C5c1be122bb954defc40408d916c23c8e%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565846839529903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=NPYYVLZDGn51OzWHL7gCJzh1k4K8IO2tNYmXlKU6OcI%3D&amp;reserved=0
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fblob%2F5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1%2Fdrivers%2Fserial%2Fuart_nrfx_uarte.c%23L397&;data=04%7C01%7CMarti.Bolivar%40nordicsemi.no%7C5c1be122bb954defc40408d916c23c8e%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565846839529903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vJEoEuuSIBa6kdW7RmFttrB8BePBXVSjW%2BLrnSxGyso%3D&amp;reserved=0

So flow control at a SoC level seems to be turned off by default.

It's true that many boards in PR #25999 do enable it by default, e.g.
nRF52840-DK:

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F25999%2Ffiles%23diff-f496b12068cf78fdbb22c1b8a4eaeb66010db95b4e80db7377a340ae30a83519R7&;data=04%7C01%7CMarti.Bolivar%40nordicsemi.no%7C5c1be122bb954defc40408d916c23c8e%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565846839529903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=gxlorGb5sNWseWeGo%2BlxMxcq0s%2F87Vx76MjrZQxfM9k%3D&amp;reserved=0

But it seems like at a board maintainer level, you can leave the SoC default as-is to make flow control "opt in" as requested.


Are there any thoughts on this subject and how to get this working,
focused on ease of being able to set this for ours and customer's
reuse?
It looks like flow control is off by default and it's opt-in; what did I miss?

Thanks!
Martí

Thanks,
Jamie


THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.


Re: [REMINDER] Changing default branch name on GitHub - action required

Bolivar, Marti
 

The main west repository [1] has also renamed its default branch to
'main'. Similar guidance applies if you've got a local clone or GitHub
fork.

Martí

https://github.com/zephyrproject-rtos/west

"Kumar Gala via lists.zephyrproject.org"
<kumar.gala=linaro.org@lists.zephyrproject.org> writes:

Reminder to all that this change has gone into effect.

You may additionally want to make this change in your own GitHub fork of Zephyr.

- k

On May 12, 2021, at 10:35 AM, Kumar Gala <kumar.gala@linaro.org> wrote:

We will be changing the default branch on github from 'master' to 'main' on Friday (May 14, 2021).

There is no action required for any open PRs, however you'll need to update your local git clone as follows:

git branch -m master main
git fetch origin
git branch -u origin/main main

You'll need to be utilizing at least west 0.10.1 or later.

Will announce here when this change is made on Friday.

I’ve also opened this GitHub discussion on this topic as well:

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fdiscussions%2F35230&;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C417aecdca65440ed29e008d916b37071%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565782203787159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=iejytjccZLgHyuzPZqnf0odj4Riv0xFWu3eeJFJrMoQ%3D&amp;reserved=0

thanks

- k


341 - 360 of 8114