Merge #254

254: Update RTFM name to RTIC, fixed links, updated singletons.md example. r=adamgreig a=PTaylor-us



Co-authored-by: Peter Taylor <PTaylor@FluenTech.info>

Author: bors[bot]

src/concurrency/index.md

@@ -555,23 +555,23 @@ fn timer() {
 Whew! This is safe, but it is also a little unwieldy. Is there anything else
 we can do?
 
-## RTFM
+## RTIC
 
-One alternative is the [RTFM framework], short for Real Time For the Masses. It
+One alternative is the [RTIC framework], short for Real Time Interrupt-driven Concurrency. It
 enforces static priorities and tracks accesses to `static mut` variables
 ("resources") to statically ensure that shared resources are always accessed
 safely, without requiring the overhead of always entering critical sections and
 using reference counting (as in `RefCell`). This has a number of advantages such
 as guaranteeing no deadlocks and giving extremely low time and memory overhead.
 
-[RTFM framework]: https://github.com/japaric/cortex-m-rtfm
+[RTIC framework]: https://github.com/rtic-rs/cortex-m-rtic
 
 The framework also includes other features like message passing, which reduces
 the need for explicit shared state, and the ability to schedule tasks to run at
 a given time, which can be used to implement periodic tasks. Check out [the
 documentation] for more information!
 
-[the documentation]: https://japaric.github.io/cortex-m-rtfm/book/
+[the documentation]: https://rtic.rs
 
 ## Real Time Operating Systems
 

src/peripherals/singletons.md

@@ -73,24 +73,25 @@ fn main() {
 
 [cortex_m docs](https://docs.rs/cortex-m/latest/cortex_m/macro.singleton.html)
 
-Additionally, if you use `cortex-m-rtfm`, the entire process of defining and obtaining these peripherals are abstracted for you, and you are instead handed a `Peripherals` structure that contains a non-`Option<T>` version of all of the items you define.
+Additionally, if you use [`cortex-m-rtic`](https://github.com/rtic-rs/cortex-m-rtic), the entire process of defining and obtaining these peripherals are abstracted for you, and you are instead handed a `Peripherals` structure that contains a non-`Option<T>` version of all of the items you define.
 
 ```rust,ignore
-// cortex-m-rtfm v0.3.x
-app! {
-    resources: {
-        static RX: Rx<USART1>;
-        static TX: Tx<USART1>;
+// cortex-m-rtic v0.5.x
+#[rtic::app(device = lm3s6965, peripherals = true)]
+const APP: () = {
+    #[init]
+    fn init(cx: init::Context) {
+        static mut X: u32 = 0;
+         
+        // Cortex-M peripherals
+        let core: cortex_m::Peripherals = cx.core;
+        
+        // Device specific peripherals
+        let device: lm3s6965::Peripherals = cx.device;
     }
 }
-fn init(p: init::Peripherals) -> init::LateResources {
-    // Note that this is now an owned value, not a reference
-    let usart1: USART1 = p.device.USART1;
-}
 ```
 
-[japaric.io rtfm v3](https://blog.japaric.io/rtfm-v3/)
-
 ## But why?
 
 But how do these Singletons make a noticeable difference in how our Rust code works?