Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow switching form Interrupt-driven UPART API to asynchronous API on STM32. #48606

Closed
r2r0 opened this issue Aug 3, 2022 · 1 comment · Fixed by #60396
Closed

Allow switching form Interrupt-driven UPART API to asynchronous API on STM32. #48606

r2r0 opened this issue Aug 3, 2022 · 1 comment · Fixed by #60396
Assignees
Labels
area: API Changes to public APIs area: UART Universal Asynchronous Receiver-Transmitter Enhancement Changes/Updates/Additions to existing features

Comments

@r2r0
Copy link
Member

r2r0 commented Aug 3, 2022

Is your enhancement proposal related to a problem? Please describe.
Actual implementation does not support use case when UART driver is initialized to use Interrupt-driven API (uart_irq_callback_set) and then we want to switch later to asynchronous API (uart_callback_set).
It is because the "old" callback for interrupt API is still remembered, and it is still used in ISR.
This disturbs logic of asynchronous API code in ISR (TC flag is cleared before used).

Describe the solution you'd like
When given API is initialized (i.e., asynchronous) then other types of API (i.e., interrupt-driven) should not used anymore.

Describe alternatives you've considered
It is still possible to call uart_irq_callback_set with NULL callback before calling to uart_callback_set but it looks more than workaround and it depends on how some things are implemented now.

Additional context

@r2r0 r2r0 added the Enhancement Changes/Updates/Additions to existing features label Aug 3, 2022
@henrikbrixandersen henrikbrixandersen added area: UART Universal Asynchronous Receiver-Transmitter platform: STM32 ST Micro STM32 labels Aug 9, 2022
@erwango erwango self-assigned this Aug 10, 2022
@erwango
Copy link
Member

erwango commented Aug 10, 2022

So I had a quick look to irq and async implementation in serial drivers in Zephyr:
4 are implementing both IRQ driven and ASYNC mode simultaneously (nrfx_uarte implements both modes but they are exclusive).
On these 4, mcux_lpuart, sam0 and stm32 behave the way that you describe.
nrfx_uart does some specific processing to check if irq are disabled first, so I think it should be compliant with your expectations.

So the workaround that you are mentioning is more a main line way of doing things.
If there is a change to be done, I'd expect a clarification of the uart API to be done first.

@erwango erwango added area: API Changes to public APIs and removed platform: STM32 ST Micro STM32 labels Aug 10, 2022
@erwango erwango assigned dcpleung and unassigned erwango Aug 10, 2022
dcpleung added a commit to dcpleung/zephyr that referenced this issue Jul 14, 2023
Both the IRQ API and Asynchronous API support callback.
However, since they are both interrupt driven, having
callbacks on both API would interfere with each other
in almost all cases. So this adds a kconfig to signal
that the callbacks should be exclusive to each other.
In other words, if one is set, the other should not
be active. Drivers implementing both APIs have been
updated to remove the callbacks from the other API.
Though, this still leaves the option to disable
the kconfig and allows both APIs to have callbacks
if one desires.

Fixes zephyrproject-rtos#48606

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
dcpleung added a commit to dcpleung/zephyr that referenced this issue Jul 14, 2023
Both the IRQ API and Asynchronous API support callback.
However, since they are both interrupt driven, having
callbacks on both API would interfere with each other
in almost all cases. So this adds a kconfig to signal
that the callbacks should be exclusive to each other.
In other words, if one is set, the other should not
be active. Drivers implementing both APIs have been
updated to remove the callbacks from the other API.
Though, this still leaves the option to disable
the kconfig and allows both APIs to have callbacks
if one desires.

Fixes zephyrproject-rtos#48606

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
fabiobaltieri pushed a commit that referenced this issue Jul 18, 2023
Both the IRQ API and Asynchronous API support callback.
However, since they are both interrupt driven, having
callbacks on both API would interfere with each other
in almost all cases. So this adds a kconfig to signal
that the callbacks should be exclusive to each other.
In other words, if one is set, the other should not
be active. Drivers implementing both APIs have been
updated to remove the callbacks from the other API.
Though, this still leaves the option to disable
the kconfig and allows both APIs to have callbacks
if one desires.

Fixes #48606

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
kunoh pushed a commit to kunoh/zephyr that referenced this issue Aug 7, 2023
Both the IRQ API and Asynchronous API support callback.
However, since they are both interrupt driven, having
callbacks on both API would interfere with each other
in almost all cases. So this adds a kconfig to signal
that the callbacks should be exclusive to each other.
In other words, if one is set, the other should not
be active. Drivers implementing both APIs have been
updated to remove the callbacks from the other API.
Though, this still leaves the option to disable
the kconfig and allows both APIs to have callbacks
if one desires.

Fixes zephyrproject-rtos#48606

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: API Changes to public APIs area: UART Universal Asynchronous Receiver-Transmitter Enhancement Changes/Updates/Additions to existing features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants