You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When NOT using the FIFO, interrupt storms significantly reduce performance without any real reason for being there. In short, the interrupt condition itself does not appear to be cleared properly, even if you write to the FIFO registers [this causes the opposite effect, actually, forcing a reset of some kind in the hardware], so you end up with rapid interrupt after interrupt with the USB.
The solution appears to be implementing the FIFO. The hardware was apparently intended to be run this way, even though having the FIFO off appeared to be a simpler implementation. It basically doesn't work properly without the FIFO. And hopefully, if there IS an interrupt storm, checking FIFO READ == FIFO WRITE and immediately existing the ISR will not impact performance too much.
When NOT using the FIFO, interrupt storms significantly reduce performance without any real reason for being there. In short, the interrupt condition itself does not appear to be cleared properly, even if you write to the FIFO registers [this causes the opposite effect, actually, forcing a reset of some kind in the hardware], so you end up with rapid interrupt after interrupt with the USB.
The solution appears to be implementing the FIFO. The hardware was apparently intended to be run this way, even though having the FIFO off appeared to be a simpler implementation. It basically doesn't work properly without the FIFO. And hopefully, if there IS an interrupt storm, checking FIFO READ == FIFO WRITE and immediately existing the ISR will not impact performance too much.
See #33 and #41
The text was updated successfully, but these errors were encountered: