change timeout to retry count in _wait_spi_char

[mikejc58]

This change modifies the adafruit_esp32spi.py's _wait_spi_char function to use a retry count rather than a 100 millisecond timeout. Since 100 milliseconds is less that a typical garbage collect, the timeout causes spurious timeout exceptions to be reported. The retry count is set to 50, which is about the number of times the existing code will go around its timeout loop in 100 milliseconds.

See the attached file for more details

conclusions.txt

[ladyada]

you dont need a time.sleep() in the loop?

[mikejc58]

No, I don't think so. There was never a time.sleep in the loop before, and with the retry count of 50, when/if _read_byte does not return the expected value (when it will loop), the existing code loops back and retries with no delay. 50 retries takes about 100 milliseconds, the same as the original timeout. So, in the case where retries are used, the new code performs exactly the same as before.

[mikejc58]

Actually, I should verify the 50 retries == 100 milliseconds. I think I might have measured that with instrumentation code in the path...that would reduce the count. I'll get back on this.

[mikejc58]

The 50 retries I measured taking 100 milliseconds were with a print statement each time around the loop. The actual time for 50 retries is only 3.3 milliseconds. So the retry loop needs about 1500 retries. I think it should actually do that. To minimize the chance that this modification will cause some changed behavior (other than what is intended), it should work like the old code. The old code would have looped about 1500 times until the 100 millisecond timeout occurred. We certainly could change it to time.sleep(0.01) and retry 10 times (for example), but I don't know if there is any point in that. Does Circuitpython have some use for those sleep cycles?

[mikejc58]

After sleeping on it, I think that using time.sleep(0.01) and retrying 10 times is a better choice. If asyncio is eventually going to be supported, all of these timeout loops should be changed.

I'll push that change after I run with that for a while.

[ladyada]

ok, ... it is now the exact same timeout as before (?)

[mikejc58]

Yes, 100 milliseconds.

[jposada202020]

@tannewt Do yo have any comments regarding this PR :)
Thanks

[anecdata]

Just a note that the revised approach to use explicit timing (time.sleep or checking elapsed time in a loop) seems preferable to using a counter to approximate time as the latter would vary across ports and boards.

[tannewt]

Looks good to me! Thank you!