Add W5100, W5500, and ECN28J60 interrupt-driven mode #1986
Conversation
No polling needed and should reduce latency by using the GPIO interrupt to signal the Pico to read a received packet.
|
FWIW this passes the simple WiFiClient tests and reduces delay on |
|
@JAndrassy this PR should enable you to use IRQ-based reception on your ESP32 WiFi driver as well. The changes to the driver itself should be minimal and it can really reduce latency and CPU overhead. |
|
the esp-hosted firmware maintainers messed up the handshake pin which was originally intended as interrupt signal. |
|
Ah, too bad. This change may also heolp w/the starvation issue you found with LittleFS in your sketch from #1973. If you still have the setup and run either WizNet chip, it might be worth re-adding the LittleFS bits and stting if you get any better performance. With polling it's possible the LWIP lock is always taken when the poll happens...even if it's unlocked at other times. With level-based IRQs, all you need is 1 clock cycle unlocked and it'll catch the interrupt and poll. |
Under heavy load the GPIO stack was seen to grow beyond 4 entries, causing further driver interrupts to be ignored. Increase the depth to 8 to give add'l leeway. Add short docs on specifying the interrupt pin for the WizNet devices.
It took longer to wire up the module than it took to add IRQ based reception support!
earlephilhower
changed the title
|
I've had this running for >1hr on various boards with On the ENC I can get <1ms ping response. On the W5100, if I bump up the SPI from 4MHz to 25MHz I get ping responses of 2ms. Both of which are very stable. With polling the ping would range from 1-20ms (since the Pico would only look for packets every 20ms!), and the web server response under load felt much worse. |
No polling needed and should reduce latency by using the GPIO interrupt to signal the Pico to read a received packet.