Merge pull request #325 from AfoHT/rtic-rename

Rename RTFM to RTIC

8 files changed, 42 insertions, 42 deletions

diff --git a/book/en/src/internals/access.md b/book/en/src/internals/access.md
index a4c9ca0..6433707 100644
--- a/book/en/src/internals/access.md
+++ b/book/en/src/internals/access.md
@@ -1,6 +1,6 @@
 # Access control
 
-One of the core foundations of RTFM is access control. Controlling which parts
+One of the core foundations of RTIC is access control. Controlling which parts
 of the program can access which static variables is instrumental to enforcing
 memory safety.
 
@@ -12,8 +12,8 @@ resides in the same scope in which they are declared. Modules give some control
 over how a static variable can be accessed by they are not flexible enough.
 
 To achieve the fine-grained access control where tasks can only access the
-static variables (resources) that they have specified in their RTFM attribute
-the RTFM framework performs a source code level transformation. This
+static variables (resources) that they have specified in their RTIC attribute
+the RTIC framework performs a source code level transformation. This
 transformation consists of placing the resources (static variables) specified by
 the user *inside* a `const` item and the user code *outside* the `const` item.
 This makes it impossible for the user code to refer to these static variables.
@@ -28,7 +28,7 @@ The code below is an example of the kind of source level transformation that
 happens behind the scenes:
 
 ``` rust
-#[rtfm::app(device = ..)]
+#[rtic::app(device = ..)]
 const APP: () = {
     static mut X: u64: 0;
     static mut Y: bool: 0;
diff --git a/book/en/src/internals/ceilings.md b/book/en/src/internals/ceilings.md
index 6b0530c..49d248a 100644
--- a/book/en/src/internals/ceilings.md
+++ b/book/en/src/internals/ceilings.md
@@ -2,10 +2,10 @@
 
 A resource *priority ceiling*, or just *ceiling*, is the dynamic priority that
 any task must have to safely access the resource memory. Ceiling analysis is
-relatively simple but critical to the memory safety of RTFM applications.
+relatively simple but critical to the memory safety of RTIC applications.
 
 To compute the ceiling of a resource we must first collect a list of tasks that
-have access to the resource -- as the RTFM framework enforces access control to
+have access to the resource -- as the RTIC framework enforces access control to
 resources at compile time it also has access to this information at compile
 time. The ceiling of the resource is simply the highest logical priority among
 those tasks.
@@ -27,7 +27,7 @@ gets a unique reference (`&mut-`) to resources.
 An example to illustrate the ceiling analysis:
 
 ``` rust
-#[rtfm::app(device = ..)]
+#[rtic::app(device = ..)]
 const APP: () = {
     struct Resources {
         // accessed by `foo` (prio = 1) and `bar` (prio = 2)
diff --git a/book/en/src/internals/critical-sections.md b/book/en/src/internals/critical-sections.md
index 94aee2c..f95a5a7 100644
--- a/book/en/src/internals/critical-sections.md
+++ b/book/en/src/internals/critical-sections.md
@@ -2,7 +2,7 @@
 
 When a resource (static variable) is shared between two, or more, tasks that run
 at different priorities some form of mutual exclusion is required to mutate the
-memory in a data race free manner. In RTFM we use priority-based critical
+memory in a data race free manner. In RTIC we use priority-based critical
 sections to guarantee mutual exclusion (see the [Immediate Ceiling Priority
 Protocol][icpp]).
 
@@ -31,7 +31,7 @@ task we give it a *resource proxy*, whereas we give a unique reference
 The example below shows the different types handed out to each task:
 
 ``` rust
-#[rtfm::app(device = ..)]
+#[rtic::app(device = ..)]
 const APP: () = {
     struct Resources {
         #[init(0)]
@@ -102,7 +102,7 @@ pub mod bar {
 const APP: () = {
     static mut x: u64 = 0;
 
-    impl rtfm::Mutex for resources::x {
+    impl rtic::Mutex for resources::x {
         type T = u64;
 
         fn lock<R>(&mut self, f: impl FnOnce(&mut u64) -> R) -> R {
@@ -161,7 +161,7 @@ In this particular example we could implement the critical section as follows:
 > **NOTE:** this is a simplified implementation
 
 ``` rust
-impl rtfm::Mutex for resources::x {
+impl rtic::Mutex for resources::x {
     type T = u64;
 
     fn lock<R, F>(&mut self, f: F) -> R
@@ -224,7 +224,7 @@ provides extra information to the compiler.
 Consider this program:
 
 ``` rust
-#[rtfm::app(device = ..)]
+#[rtic::app(device = ..)]
 const APP: () = {
     struct Resources {
         #[init(0)]
@@ -235,7 +235,7 @@ const APP: () = {
 
     #[init]
     fn init() {
-        rtfm::pend(Interrupt::UART0);
+        rtic::pend(Interrupt::UART0);
     }
 
     #[interrupt(binds = UART0, priority = 1, resources = [x, y])]
@@ -338,7 +338,7 @@ const APP: () = {
 
     // similarly for `UART0` / `foo` and `UART2` / `baz`
 
-    impl<'a> rtfm::Mutex for resources::x<'a> {
+    impl<'a> rtic::Mutex for resources::x<'a> {
         type T = u64;
 
         fn lock<R>(&mut self, f: impl FnOnce(&mut u64) -> R) -> R {
@@ -419,7 +419,7 @@ fn foo(c: foo::Context) {
 
 ## The BASEPRI invariant
 
-An invariant that the RTFM framework has to preserve is that the value of the
+An invariant that the RTIC framework has to preserve is that the value of the
 BASEPRI at the start of an *interrupt* handler must be the same value it has
 when the interrupt handler returns. BASEPRI may change during the execution of
 the interrupt handler but running an interrupt handler from start to finish
@@ -429,7 +429,7 @@ This invariant needs to be preserved to avoid raising the dynamic priority of a
 handler through preemption. This is best observed in the following example:
 
 ``` rust
-#[rtfm::app(device = ..)]
+#[rtic::app(device = ..)]
 const APP: () = {
     struct Resources {
         #[init(0)]
@@ -439,7 +439,7 @@ const APP: () = {
     #[init]
     fn init() {
         // `foo` will run right after `init` returns
-        rtfm::pend(Interrupt::UART0);
+        rtic::pend(Interrupt::UART0);
     }
 
     #[task(binds = UART0, priority = 1)]
@@ -447,7 +447,7 @@ const APP: () = {
         // BASEPRI is `0` at this point; the dynamic priority is currently `1`
 
         // `bar` will preempt `foo` at this point
-        rtfm::pend(Interrupt::UART1);
+        rtic::pend(Interrupt::UART1);
 
         // BASEPRI is `192` at this point (due to a bug); the dynamic priority is now `2`
         // this function returns to `idle`
@@ -472,7 +472,7 @@ const APP: () = {
 
         // this has no effect due to the BASEPRI value
         // the task `foo` will never be executed again
-        rtfm::pend(Interrupt::UART0);
+        rtic::pend(Interrupt::UART0);
 
         loop {
             // ..
@@ -488,10 +488,10 @@ const APP: () = {
 ```
 
 IMPORTANT: let's say we *forget* to roll back `BASEPRI` in `UART1` -- this would
-be a bug in the RTFM code generator.
+be a bug in the RTIC code generator.
 
 ``` rust
-// code generated by RTFM
+// code generated by RTIC
 
 const APP: () = {
     // ..
diff --git a/book/en/src/internals/interrupt-configuration.md b/book/en/src/internals/interrupt-configuration.md
index 98a98e5..278707c 100644
--- a/book/en/src/internals/interrupt-configuration.md
+++ b/book/en/src/internals/interrupt-configuration.md
@@ -1,18 +1,18 @@
 # Interrupt configuration
 
-Interrupts are core to the operation of RTFM applications. Correctly setting
+Interrupts are core to the operation of RTIC applications. Correctly setting
 interrupt priorities and ensuring they remain fixed at runtime is a requisite
 for the memory safety of the application.
 
-The RTFM framework exposes interrupt priorities as something that is declared at
+The RTIC framework exposes interrupt priorities as something that is declared at
 compile time. However, this static configuration must be programmed into the
 relevant registers during the initialization of the application. The interrupt
 configuration is done before the `init` function runs.
 
-This example gives you an idea of the code that the RTFM framework runs:
+This example gives you an idea of the code that the RTIC framework runs:
 
 ``` rust
-#[rtfm::app(device = lm3s6965)]
+#[rtic::app(device = lm3s6965)]
 const APP: () = {
     #[init]
     fn init(c: init::Context) {
diff --git a/book/en/src/internals/late-resources.md b/book/en/src/internals/late-resources.md
index 8724fbb..ad2a5e5 100644
--- a/book/en/src/internals/late-resources.md
+++ b/book/en/src/internals/late-resources.md
@@ -9,7 +9,7 @@ The example below shows the kind of code that the framework generates to
 initialize late resources.
 
 ``` rust
-#[rtfm::app(device = ..)]
+#[rtic::app(device = ..)]
 const APP: () = {
     struct Resources {
         x: Thing,
diff --git a/book/en/src/internals/non-reentrancy.md b/book/en/src/internals/non-reentrancy.md
index f1ce2cb..0b0e4a7 100644
--- a/book/en/src/internals/non-reentrancy.md
+++ b/book/en/src/internals/non-reentrancy.md
@@ -1,6 +1,6 @@
 # Non-reentrancy
 
-In RTFM, tasks handlers are *not* reentrant. Reentering a task handler can break
+In RTIC, tasks handlers are *not* reentrant. Reentering a task handler can break
 Rust aliasing rules and lead to *undefined behavior*. A task handler can be
 reentered in one of two ways: in software or by hardware.
 
@@ -11,7 +11,7 @@ invoked using FFI (see example below). FFI requires `unsafe` code so end users
 are discouraged from directly invoking an interrupt handler.
 
 ``` rust
-#[rtfm::app(device = ..)]
+#[rtic::app(device = ..)]
 const APP: () = {
     #[init]
     fn init(c: init::Context) { .. }
@@ -42,7 +42,7 @@ const APP: () = {
 };
 ```
 
-The RTFM framework must generate the interrupt handler code that calls the user
+The RTIC framework must generate the interrupt handler code that calls the user
 defined task handlers. We are careful in making these handlers impossible to
 call from user code.
 
@@ -76,5 +76,5 @@ const APP: () = {
 
 A task handler can also be reentered without software intervention. This can
 occur if the same handler is assigned to two or more interrupts in the vector
-table but there's no syntax for this kind of configuration in the RTFM
+table but there's no syntax for this kind of configuration in the RTIC
 framework.
diff --git a/book/en/src/internals/tasks.md b/book/en/src/internals/tasks.md
index dd3638a..995a885 100644
--- a/book/en/src/internals/tasks.md
+++ b/book/en/src/internals/tasks.md
@@ -1,6 +1,6 @@
 # Software tasks
 
-RTFM supports software tasks and hardware tasks. Each hardware task is bound to
+RTIC supports software tasks and hardware tasks. Each hardware task is bound to
 a different interrupt handler. On the other hand, several software tasks may be
 dispatched by the same interrupt handler -- this is done to minimize the number
 of interrupts handlers used by the framework.
@@ -27,7 +27,7 @@ Let's first take a look the code generated by the framework to dispatch tasks.
 Consider this example:
 
 ``` rust
-#[rtfm::app(device = ..)]
+#[rtic::app(device = ..)]
 const APP: () = {
     // ..
 
@@ -183,7 +183,7 @@ const APP: () = {
                         });
 
                         // pend the interrupt that runs the task dispatcher
-                        rtfm::pend(Interrupt::UART0);
+                        rtic::pend(Interrupt::UART0);
                     }
 
                     None => {
@@ -252,7 +252,7 @@ const APP: () = {
                         });
 
                         // pend the interrupt that runs the task dispatcher
-                        rtfm::pend(Interrupt::UART0);
+                        rtic::pend(Interrupt::UART0);
                     }
 
                     None => {
@@ -315,7 +315,7 @@ lock-free.
 
 ## Queue capacity
 
-The RTFM framework uses several queues like ready queues and free queues. When
+The RTIC framework uses several queues like ready queues and free queues. When
 the free queue is empty trying to `spawn` a task results in an error; this
 condition is checked at runtime. Not all the operations performed by the
 framework on these queues check if the queue is empty / full. For example,
@@ -356,7 +356,7 @@ endpoint is owned by a task dispatcher.
 Consider the following example:
 
 ``` rust
-#[rtfm::app(device = ..)]
+#[rtic::app(device = ..)]
 const APP: () = {
     #[idle(spawn = [foo, bar])]
     fn idle(c: idle::Context) -> ! {
diff --git a/book/en/src/internals/timer-queue.md b/book/en/src/internals/timer-queue.md
index e0242f0..0eba106 100644
--- a/book/en/src/internals/timer-queue.md
+++ b/book/en/src/internals/timer-queue.md
@@ -11,7 +11,7 @@ appropriate ready queue.
 Let's see how this in implemented in code. Consider the following program:
 
 ``` rust
-#[rtfm::app(device = ..)]
+#[rtic::app(device = ..)]
 const APP: () = {
     // ..
 
@@ -47,7 +47,7 @@ mod foo {
 }
 
 const APP: () = {
-    type Instant = <path::to::user::monotonic::timer as rtfm::Monotonic>::Instant;
+    type Instant = <path::to::user::monotonic::timer as rtic::Monotonic>::Instant;
 
     // all tasks that can be `schedule`-d
     enum T {
@@ -141,7 +141,7 @@ const APP: () = {
                     });
 
                     // pend the task dispatcher
-                    rtfm::pend(Interrupt::UART0);
+                    rtic::pend(Interrupt::UART0);
                 }
             }
         }
@@ -160,7 +160,7 @@ timeout interrupt to the `SysTick` handler.
 
 ## Resolution and range of `cyccnt::Instant` and `cyccnt::Duration`
 
-RTFM provides a `Monotonic` implementation based on the `DWT`'s (Data Watchpoint
+RTIC provides a `Monotonic` implementation based on the `DWT`'s (Data Watchpoint
 and Trace) cycle counter. `Instant::now` returns a snapshot of this timer; these
 DWT snapshots (`Instant`s) are used to sort entries in the timer queue. The
 cycle counter is a 32-bit counter clocked at the core clock frequency. This
@@ -221,7 +221,7 @@ analysis.
 To illustrate, consider the following example:
 
 ``` rust
-#[rtfm::app(device = ..)]
+#[rtic::app(device = ..)]
 const APP: () = {
     #[task(priority = 3, spawn = [baz])]
     fn foo(c: foo::Context) {
@@ -353,7 +353,7 @@ const APP: () = {
                             });
                         });
 
-                        rtfm::pend(Interrupt::UART0);
+                        rtic::pend(Interrupt::UART0);
                     }
 
                     None => {