Make RTIC 2 work on stable by using main's stack as an allocator

book/en/src/SUMMARY.md

@@ -28,7 +28,6 @@
 ---
 
 - [Migrating from v1.0.x to v2.0.0](./migration_v1_v2.md)
-  - [Rust Nightly & features](./migration_v1_v2/nightly.md)
   - [Migrating to `rtic-monotonics`](./migration_v1_v2/monotonics.md)
   - [Software tasks must now be `async`](./migration_v1_v2/async_tasks.md)
   - [Using and understanding `rtic-sync`](./migration_v1_v2/rtic-sync.md)

book/en/src/migration_v1_v2.md

@@ -2,7 +2,7 @@
 
 Migrating a project from RTIC `v1.0.x` to `v2.0.0` involves the following steps:
 
-1. `v2.0.0` requires [`#![type_alias_impl_trait]`](https://github.com/rust-lang/rust/issues/63063) and Rust Nightly.
+1. `v2.1.0` works on Rust Stable from 1.75 (**recommended**), while older versions require a `nightly` compiler via the use of [`#![type_alias_impl_trait]`](https://github.com/rust-lang/rust/issues/63063).
 2. Migrating from the monotonics included in `v1.0.x` to `rtic-time` and `rtic-monotonics`, replacing `spawn_after`, `spawn_at`.
 3. Software tasks are now required to be `async`, and using them correctly.
 4. Understanding and using data types provided by `rtic-sync`.
@@ -12,7 +12,7 @@ For a detailed description of the changes, refer to the subchapters.
 If you wish to see a code example of changes required, you can check out [the full example migration page](./migration_v1_v2/complete_example.md).
 
 #### TL;DR (Too Long; Didn't Read)
-1. Add `#![type_alias_impl_trait]` to your crate, and use `cargo +nightly`.
-2. Instead of `spawn_after` and `spawn_at`, you now use the `async` functions `delay`, `delay_until` (and related) with impls provided by `rtic-monotonics`.
-3. Software tasks _must_ be `async fn`s now. Not returning from a task is allowed so long as there is an `await` in the task. You can still `lock` shared resources.
-4. Use `rtic_sync::arbiter::Arbiter` to `await` access to a shared resource, and `rtic_sync::channel::Channel` to communicate between tasks instead of `spawn`-ing new ones.
+
+1. Instead of `spawn_after` and `spawn_at`, you now use the `async` functions `delay`, `delay_until` (and related) with impls provided by `rtic-monotonics`.
+2. Software tasks _must_ be `async fn`s now. Not returning from a task is allowed so long as there is an `await` in the task. You can still `lock` shared resources.
+3. Use `rtic_sync::arbiter::Arbiter` to `await` access to a shared resource, and `rtic_sync::channel::Channel` to communicate between tasks instead of `spawn`-ing new ones.

book/en/src/migration_v1_v2/complete_example.md

@@ -97,7 +97,6 @@ _Note_: This diff may not be 100% accurate, but it displays the important change
 ``` diff
 #![no_main]
  #![no_std]
-+#![feature(type_alias_impl_trait)]
  
  use panic_rtt_target as _;
  use rtic::app;

book/en/src/migration_v1_v2/nightly.md

@@ -1,5 +0,0 @@
-# RTIC now requires Rust Nightly
-
-The new `async` features require that you use a nightly compiler, and that the feature `type_alias_impl_trait` is enabled for your applications.
-
-To enable this feature, you must add the line `#![feature(type_alias_impl_trait)]` to the root file of your project, on the lines below or above where `#![no_std]` and `#![no_main]` are defined.

book/en/src/preface.md

@@ -141,8 +141,6 @@ Asynchronous programming in various forms are getting increased popularity and l
 
 The Rust standard library provides collections for dynamically allocated data-structures which are useful to manage execution contexts at run-time. However, in the setting of resource constrained real-time systems, dynamic allocations are problematic (both regarding performance and reliability - Rust runs into a *panic* on an out-of-memory condition). Thus, static allocation is the preferable approach!
 
-RTIC provides a mechanism for `async`/`await` that relies solely on static allocations. However, the implementation relies on the `#![feature(type_alias_impl_trait)]` (TAIT) which is undergoing stabilization (thus RTIC v2.x currently requires a *nightly* toolchain). Technically, using TAIT, the compiler determines the size of each execution context allowing static allocation.
-
 From a modelling perspective `async/await` lifts the run-to-completion requirement of SRP, and each section of code between two yield points (`await`s) can be seen as an individual task. The compiler will reject any attempt to `await` while holding a resource (not doing so would break the strict LIFO requirement on resource usage under SRP).
 
 So with the technical stuff out of the way, what does `async/await` bring to the table?