-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Shared uart isr #5600
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
base: master
Are you sure you want to change the base?
Shared uart isr #5600
Changes from 1 commit
2e9a1c0
5bc2ea5
ae7903d
6b87398
6564edb
285b7f5
c96209d
2e3ca18
d6de293
ab03100
b0df4d0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -152,10 +152,10 @@ extern "C" { | |
// uart_subscribeInterrupt & uart_unsubscribeInterrupt are not safe and must | ||
// be called within ETS_UART_INTR_DISABLE()/ETS_UART_INTR_ENABLE() protection | ||
// | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Other unsafe functions have There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you glance at the use of subscribe inside uart.c, you will notice that a bunch of other stuff that needs to be done inside the INTR_EN/DISABLE sandwich. These other operations are similar but different from each use case. While unsubscribe does not; I decided to keep them consistent rather than only one require the sandwich. Keeping a balanced API. I really don't like either direction (what I have and what you suggested). I am very open to other suggestions. These are exposed, do we really want to mark them unsafe? While its self documenting, it seems inconsistent with any other API. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please implement like bullet 1 above. The unsafe word in the function name is meant to indicate it's not interrupt-safe and it shouldn't be exported, if at all possible. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not quite resolved. I'll try to explain again.
In this case, there could be undefined behavior if there is an IRQ in the middle of calling these functions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also, it is ok to skip argument sanity checks in the _unsafe functions, but the safe versions should implement checks on the received args. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @devyte Maybe I was not clear enough. You can't wrap the subscribe as the site of where you call it has to be already wrapped with it due to several processes of setting up the uart hardware are required to be called within the same DISABLE/ENABLE. This is what I was pointing out by referencing the call spots withing UART.C. This same setup; but different based on needs of the caller is done externally by anyone needing to use uart ISR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you mean these unsafe functions need to be called by the user? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. YES, these two unsafe functions are called by the user. I pointed to my project that consumes these in the pull comments at the top. Can I just point them to my code? Ok, its not simple ;-) The real use of this is where you aren't doing simple serial, otherwise you would just use Serial. In general, using the hardware to talk to devices that take a serial stream; often where translation is done from data on the MCU as you send. Which means configuring the UART to your custom needs (using all those esoteric features to invert, turn off stop bits, etc) that are not exposed by Serial or even the current uart.h. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here is a link to my code that does this specifically, copied below
|
||
void uart_subscribeInterrupt(int uart_nr, uartInterruptHandler callback, void* param); | ||
void uart_subscribeInterrupt_unsafe(int uart_nr, uartInterruptHandler callback, void* param); | ||
// if uart_unsubscribeInterrupt returns false, then ETS_UART_INTR_ENABLE() doesn't | ||
// need to be called after it | ||
bool uart_unsubscribeInterrupt(int uart_nr, uartInterruptHandler callback); | ||
bool uart_unsubscribeInterrupt_unsafe(int uart_nr, uartInterruptHandler callback); | ||
|
||
#if defined (__cplusplus) | ||
} // extern "C" | ||
|
Uh oh!
There was an error while loading. Please reload this page.