Optimizations
#2174
Replies: 1 comment
-
can you make an PR for your suggested change, please make sure to test it on actual hardwware. It is much easier to understand what you mean. I wrote lots of code during long span of time, I don't quite remember everything. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
@hathach
Why not also compare the interrupts when fetched with the enabled ones? Like
uint32_t int_status = USB->ISTR & USB->CNTR;
You mention here, that some devices have issues reacting to a resume signal from the host. I'm aware of such problems on AVR devices and as far as I remember it was host specific. So it should be good if the described failsafe would be used. For example the SOF interrupt can be enabled in the suspend block and disabled again in the resume block. That way the device would not get flooded with SOF interrupts when active while still providing a failsafe to resume normal USB operation when put to sleep.
I'm somehow skeptical that it's a good idea to skip the rest of the interrupts when there is a reset. I would imagine all spurious pending interrupt should be cleared if the return is used. Like what happens when the device had some other things to do and so handle multiple later on. It should be possible that another interrupt was set in addition which then isn't scheduled but a new one can't occur because the old one was never cleared. Or does this somehow not matter?
Beta Was this translation helpful? Give feedback.
All reactions