numerous delay(1) in EthernetClient.cpp impose a long 1ms wait doing nothing in active polling of a resource (Ethernet.socketStatus) waiting a timeout.
why not using delayMicrosecond(10), basically something with finer granularity than one whole millisecond ?
or why not just call yield() and then poll again the flag the code is waiting for. (might put a lot of stress on SPI - so may be a little wait is necessary but not one full millisecond).
Also polling the flag is the very next instruction (in a do-while construct) after requesting an action (closing a socket), so it is very possible that the component did not get enough time to complete the previous SPI request and so checking the flag right away will likely fail, leading the code into the long 1ms delay - whereas giving a few micro-seconds for the SPI request to be executed before polling the flag would have resulted in the expected answer and no delay would have been introduced.
numerous
delay(1)in EthernetClient.cpp impose a long 1ms wait doing nothing in active polling of a resource (Ethernet.socketStatus) waiting a timeout.why not using delayMicrosecond(10), basically something with finer granularity than one whole millisecond ? or why not just call yield() and then poll again the flag the code is waiting for. (might put a lot of stress on SPI - so may be a little wait is necessary but not one full millisecond).
Also polling the flag is the very next instruction (in a do-while construct) after requesting an action (closing a socket), so it is very possible that the component did not get enough time to complete the previous SPI request and so checking the flag right away will likely fail, leading the code into the long 1ms delay - whereas giving a few micro-seconds for the SPI request to be executed before polling the flag would have resulted in the expected answer and no delay would have been introduced.