5

I'm building a library to be used on a no_std platform which allows you to do some common network-related IO, such as making HTTP requests or reading from/writing to Websockets.

Now, I would like this library to be a well-behaved citizen so that it can be easily included in other no_std applications. I hence want to package the library by implementing reasonable traits etc. The library would allow me to not have to use alloc, so supporting non-alloc no_std would be ideal.

These are the options I have looked at:

  • embedded_hal and nb: These crates are really low level (no generic traits like Read and Write or anything higher level) and the async model doesn't seem to be compatible with async/await
  • genio/core_io/...: These don't support async IO at all.
  • embrio: Seems interesting but it seems like using it would tie me to one specific environment, making the library less portable.
  • tokio v0.2.x: I would love to use it but there is no no_std support at all.
  • futures::io v0.3.x: Again, would love to use it but there is no no_std support.

Which async IO abstraction should I use in a no_std environment? If there is no good option right now, which one should I bet on/help out with for the future?

dflemstr
  • 25,947
  • 5
  • 70
  • 105
  • Async requires some sort of runtime. In std environments, that runtime can be made 'easily' with the std libraries. no_std however is not as unified as it can mean all the different microcontrollers, microprocessors, OS's as well as webassembly. So it really depends on what you actually want to support. – Geoxion Dec 02 '19 at 09:29
  • @Geoxion I'm assuming that it should be possible to implement some sort of `AsyncWrite` API that is not tied to a specific executor. For executors it already seems like there are a few good examples (e.g. for cortex-m, droneos and embrio) – dflemstr Dec 03 '19 at 18:46
  • 1
    Cortex-m isn't really an executor... But I see what you mean. What you could do is use the future trait. Then any executor that supports async await will be compatible with it. The standard future trait is also available for libcore – Geoxion Dec 03 '19 at 22:02
  • @Geoxion that was one of the options I listed above, that `futures::io` is actually not available on `no_std`. Yes, `core::future` and `futures` in general is available but not the IO specific bits. – dflemstr Dec 13 '19 at 20:20

1 Answers1

1

Take a look a look at embassy-rs. There is a very active community. Currently, embassy-rs supports;

  • Hardware abstraction layers
  • Time
  • Networking
  • Bluetooth
  • Lora
  • USB
  • DFU

All built on rust async. There are also some really nice macros to generate static buffers for tasks, so you don't need alloc.

silvergasp
  • 1,517
  • 12
  • 23