Merge #741

741: Docs 2 r=korken89 a=datdenkikniet

Working on the migration guide and other docs

TODO:
- [x] Migration guide
- [x] Hardcoded examples should link to example code that is tested (this was already done, AFAICT)
- [x] Address #699 
- [x] Discuss: should we remove references to non-v2, apart from the migration guide and link to the book for v1? (Off-github conclusion: yes)
- [x] RTIC {vs,and} Embassy (important: distinction between embassy runtime & HALs)
- [x] More descriptive docs on how to implement & PR implementations of `Monotonic` to `rtic-monotonics` 


Co-authored-by: datdenkikniet <jcdra1@gmail.com>

1 files changed, 23 insertions, 0 deletions

diff --git a/book/en/archive/by_example/app_task.md b/book/en/archive/by_example/app_task.md
new file mode 100644
index 0000000..b2731f6
--- /dev/null
+++ b/book/en/archive/by_example/app_task.md
@@ -0,0 +1,23 @@
+<!-- Should probably be removed -->
+
+# Defining tasks with `#[task]`
+
+Tasks, defined with `#[task]`, are the main mechanism of getting work done in RTIC.
+
+Tasks can
+
+* Be spawned (now or in the future, also by themselves)
+* Receive messages (passing messages between tasks)
+* Be prioritized, allowing preemptive multitasking
+* Optionally bind to a hardware interrupt
+
+RTIC makes a distinction between “software tasks” and “hardware tasks”.
+
+*Hardware tasks* are tasks that are bound to a specific interrupt vector in the MCU while software tasks are not.
+
+This means that if a hardware task is bound to, lets say, a UART RX interrupt, the task will be run every
+time that interrupt triggers, usually when a character is received.
+
+*Software tasks* are explicitly spawned in a task, either immediately or using the Monotonic timer mechanism. 
+
+In the coming pages we will explore both tasks and the different options available.