Refactor async functionality for no_std/no_alloc

[pperanich]

Looking to continue the discussion from #3 for refactoring the async implementation to work in both no_std and no_alloc environments. In particular, I would like to use this crate within an embassy-rs project.

In the previous issue, you said you had thoughts as to how you could statically allocate space for the futures. Do you still view this as a viable approach? I have not had luck in finding this done elsewhere.

[deltronix]

Similarly I would like to use this crate within an rtic project, while I do not need my state machines to be async currently it would be a very nice to have feature in the future 😏.

[schphil]

Same here! If I can be of any help let me know.

[mdeloof]

So I've been thinking about this for a while, and although I initially thought I'd be able to statically allocate the space for the futures, I currently don't see how that could work and frankly I'm not familiar enough with how futures work under the hood to say if it's even possible or not.

But! I've also realised recently that I could create an implementation of statig that doesn't use async recursion and that should work on no_std. I've tried making an initial version today and things looked good until I hit rust-lang/rust#100013 and I'm not sure if there's anything I could for the moment to circumvent this issue. So it could be I'll have to wait until this issue is resolved, but the good news is that eventually async on no_std should be possible.

[pperanich]

Awesome to hear that you have a refactor in mind to circumvent this issue. Do you plan on pushing that working branch? I'd like to see what direction you plan on taking things. Thanks!

[mdeloof]

I found some time to work on this today. I've been able to resolve the bug and now have something that seems to work (code is on no_std_async). I plan on testing it with embassy but I haven't had a chance yet. Feel free to try it out though :)