-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
Comments
So I had a quick look to irq and async implementation in serial drivers in Zephyr: So the workaround that you are mentioning is more a main line way of doing things. |
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>
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>
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>
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>
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 touart_callback_set
but it looks more than workaround and it depends on how some things are implemented now.Additional context
The text was updated successfully, but these errors were encountered: