From ab17bbf9f37e81b9aab88694e73d23f54664fa01 Mon Sep 17 00:00:00 2001 From: datdenkikniet Date: Fri, 5 May 2023 19:31:25 +0200 Subject: [PATCH] Demarcate a bit more --- book/en/src/by-example/app.md | 6 ++++++ book/en/src/by-example/software_tasks.md | 9 ++++----- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/book/en/src/by-example/app.md b/book/en/src/by-example/app.md index b5815fc0be..0aeed5b61d 100644 --- a/book/en/src/by-example/app.md +++ b/book/en/src/by-example/app.md @@ -30,6 +30,12 @@ At compile time the task/resource model is analyzed under the Stack Resource Pol Overall, the generated code infers no additional overhead in comparison to a hand-written implementation, thus in Rust terms RTIC offers a zero-cost abstraction to concurrency. +## Priority + +Priorities in RTIC are specified using the `priority = N` (where N is a positive number) argument passed to the `#[task]` attribute. All `#[task]`s can have a priority. If the priority of a task is not specified, it is set to the default value of 1. + +Priorities in RTIC follow a higher value = more important scheme. For examples, a task with priority 2 will preempt a task with priority 1. + ## An RTIC application example To give a taste of RTIC, the following example contains commonly used features. diff --git a/book/en/src/by-example/software_tasks.md b/book/en/src/by-example/software_tasks.md index ddf88fdb77..444f4a6f27 100644 --- a/book/en/src/by-example/software_tasks.md +++ b/book/en/src/by-example/software_tasks.md @@ -1,7 +1,6 @@ # Software tasks & spawn -The RTIC concept of a software task shares a lot with that of [hardware tasks](./hardware_tasks.md) with the core difference that a software task is not explicitly bound to a specific -interrupt vector, but rather bound to a “dispatcher” interrupt vector running at the intended priority of the software task (see below). +The RTIC concept of a software task shares a lot with that of [hardware tasks](./hardware_tasks.md). The core difference is that a software task is not explicitly bound to a specific interrupt vector, but rather bound to a “dispatcher” interrupt vector running at the intended priority of the software task (see below). Similarly to *hardware* tasks, the `#[task]` attribute used on a function declare it as a task. The absence of a `binds = InterruptName` argument to the attribute declares the function as a *software task*. @@ -9,11 +8,11 @@ The static method `task_name::spawn()` spawns (starts) a software task and given The *software* task itself is given as an `async` Rust function, which allows the user to optionally `await` future events. This allows to blend reactive programming (by means of *hardware* tasks) with sequential programming (by means of *software* tasks). -Whereas, *hardware* tasks are assumed to run-to-completion (and return), *software* tasks may be started (`spawned`) once and run forever, with the side condition that any loop (execution path) is broken by at least one `await` (yielding operation). +While *hardware* tasks are assumed to run-to-completion (and return), *software* tasks may be started (`spawned`) once and run forever, on the condition that any loop (execution path) is broken by at least one `await` (yielding operation). -All *software* tasks at the same priority level shares an interrupt handler acting as an async executor dispatching the software tasks. +## Dispatchers -This list of dispatchers, `dispatchers = [FreeInterrupt1, FreeInterrupt2, ...]` is an argument to the `#[app]` attribute, where you define the set of free and usable interrupts. +All *software* tasks at the same priority level share an interrupt handler acting as an async executor dispatching the software tasks. This list of dispatchers, `dispatchers = [FreeInterrupt1, FreeInterrupt2, ...]` is an argument to the `#[app]` attribute, where you define the set of free and usable interrupts. Each interrupt vector acting as dispatcher gets assigned to one priority level meaning that the list of dispatchers need to cover all priority levels used by software tasks.