You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+4-2Lines changed: 4 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,14 +11,16 @@ This crate is a fork of the splendid [`async-io`](https://github.com/smol-rs/asy
11
11
12
12
## How to use?
13
13
14
-
`async-io-mini` is a drop-in, API-compatible replacement for the `Async` and `Timer` types from `async-io`.
14
+
`async-io-mini` is an API-compatible replacement for the `Async` and `Timer` types from `async-io`.
15
15
16
16
So either:
17
17
* Just replace all `use async_io` occurances in your crate with `use async_io_mini`
18
18
* Or - in your `Cargo.toml` - replace:
19
19
*`async-io = "..."`
20
20
* with `async-io = { package = "async-io-mini", ... }`
21
21
22
+
Additionally, you need to provide an `embassy-time-driver` implementation. This is either done by the HAL of your MCU, or `embassy-time` provides you with a `std`-specific implementation. If you are not using `embassy-executor`, you will also need to select one of the `embassy-time/generic-queue-*` features.
23
+
22
24
## Justification
23
25
24
26
While `async-io` supports a ton of operating systems - _including ESP-IDF for the Espressif MCU chips_ - it does have a non-trivial memory consumption in the hidden thread named `async-io`. Since its hidden `Reactor` object is initialized lazily, it so happens that it is first allocated on-stack, and then it is moved into the static context. This requires the `async-io` thread (as well as _any_ thread from where you are polling sockets) to have at least 8K stack, which - by MCU standards! - is relatively large if you are memory-constrained.
@@ -39,7 +41,7 @@ Further, `async-io` has a non-trivial set of dependencies (again - for MCUs; for
39
41
40
42
## Enhancements
41
43
42
-
The `Timer` type of `async_io_mini` is based on the `embassy-time` crate, and as such should offer a higher resolution on embedded operating systems like the ESP-IDF than what can be normally achieved by implementing timers using the `timeout` parameter of the `select` syscall (as `async-io` does).
44
+
The `Timer` type of `async_io_mini` is based on the `embassy-time` crate, and as such should offer a higher resolution on embedded operating systems like the ESP-IDF than what can be normally achieved by implementing timers using the `timeout` parameter of the `select` syscall (as `async-io` does).
43
45
44
46
The reason for this is that on the ESP-IDF, the `timeout` parameter of `select` provides a resolution of 10ms (one FreeRTOS sys-tick), while
45
47
`embassy-time` is implemented using the [ESP-IDF Timer service](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/esp_timer.html), which provides resolutions up to 1 microsecond.
0 commit comments