Description
Context:
#106
https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/blob/master/adafruit_esp32spi/adafruit_esp32spi.py#L176
I haven't verified this exhaustively, but as far as I can tell, practically every method in ESP_SPIcontrol will at some point call _wait_for_ready somewhere in it's call stack.
I've got a simple sensor logger that's calling IO using an airlift, and round trip for a successful post is on average about 8 seconds. Only about 2-3 seconds of that is actually opening sockets, sending, receiving, parsing, etc, the rest of the time we're waiting for the ESP32.
This means that until I added the hack in the PR above, I couldn't have a UI. The hack was admittedly a hack so I closed it, but this is a problem that should be solved one way or another
@tannewt suggested starting on the async/concurrency project which would be nice, but I don't see that being done any time soon and it would be nice to have this addressed in some capacity before then
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Participants
Activity
tannewt commentedon Sep 30, 2020
When this is an important issue, we should do it with
asynciobecause that is how it's done in CPython. Doing it another way will just make it harder to move to asyncio after and be inconsistent in the meantime. I don't actually think we're that far fromasynciosupport, it just needs a reason to work on it. @warriorofwire has gotten it pretty far and may have ideas about this library.siddacious commentedon Sep 30, 2020
What do you mean by "when this is an important issue"? It seems important now. Perhaps you meant "while"?
kvc0 commentedon Sep 30, 2020
Yeah looking at that PR I'm inclined to congratulate you on an industrious workaround that worked for your project. That this library has a _wait_for_ready method means that it can pretty easily support both async and synchronous patterns.
I need to revitalize my circuitpython development environment on my new machine and finish async support. Or maybe you're interested? :-)
siddacious commentedon Oct 1, 2020
It would be interesting to see how the async code you're working on is coming together, however relying on me to get it done would be a good way to not see it be finished this year as I'm already waist deep in several projects.
tannewt commentedon Oct 1, 2020
Sorry, I should have said, "When this is our top priority", or left it off entirely. I'd like to see it done with asyncio. I don't have the time to make that happen. Hopefully someone else can help us get there sooner.
siddacious commentedon Oct 5, 2020
Where is it in terms of priority? I'm asking because before too long there's going to be another 4k+ users of this library and it would be nice to provide them a better experience if possible
tannewt commentedon Oct 6, 2020
@siddacious Not very high. I'm more concerned with using less memory during requests than allowing for concurrency.
siddacious commentedon Oct 9, 2020
@tannewt holy cow I had no idea:
tannewt commentedon Oct 9, 2020
Yuuuuup! I've made a number of changes in https://github.com/tannewt/Adafruit_CircuitPython_ESP32SPI/tree/split that would be great to merge into main.
siddacious commentedon Oct 12, 2020
@tannewt 👀
siddacious commentedon Oct 30, 2020
@tannewt is the above
splitbranch still wanting to be merged? I saw a bit of talk around NINA/ airlift stuff so I wanted to make sure it wouldn't be obsolete by the time it was mergeabletannewt commentedon Nov 3, 2020
@siddacious I think it'll be easier to slim down the changes in
splitto just the wifi and socket APIs that match the new S2 API and then merge them into the Airlift API. TheESP32SPIlibrary has corner cases that will be hard to test like digitalio support.