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.

Join devel@lists.zephyrproject.org to automatically receive all group messages.