Adding docs about RISC-V

README.md

@@ -41,6 +41,9 @@ A concurrency framework for building real-time systems.
 
 - **All Cortex-M devices are fully supported**.
 
+- **Most RISC-V devices are supported**. Refer to the [RTIC book]((https://rtic.rs/))
+  to learn more about RISC-V backends, their particularities, and their limitations.
+
 - This task model is amenable to known WCET (Worst Case Execution Time) analysis
   and scheduling analysis techniques.
 

book/en/src/internals/targets.md

@@ -1,5 +1,7 @@
 # Target Architecture
 
+## Cortex-M Devices
+
 While RTIC can currently target all Cortex-m devices there are some key architecture differences that 
 users should be aware of. Namely, the absence of Base Priority Mask Register (`BASEPRI`) which lends
 itself exceptionally well to the hardware priority ceiling support used in RTIC, in the ARMv6-M and
@@ -27,11 +29,11 @@ Table 1 below shows a list of Cortex-m processors and which type of critical sec
 | Cortex-M23 | ARMv8-M-base |                  |        ✓       |
 | Cortex-M33 | ARMv8-M-main |         ✓        |                |
 
-## Priority Ceiling
+### Priority Ceiling
 
 This is covered by the [Resources](../by-example/resources.html) page of this book.
 
-## Source Masking
+### Source Masking
 
 Without a `BASEPRI` register which allows for directly setting a priority ceiling in the Nested 
 Vectored Interrupt Controller (NVIC), RTIC must instead rely on disabling (masking) interrupts.
@@ -66,3 +68,45 @@ risk of data race conditions. At time *t4*, task A completes and returns the exe
 
 Since source masking relies on use of the NVIC, core exception sources such as HardFault, SVCall,
 PendSV, and SysTick cannot share data with other tasks.
+
+## RISC-V Devices
+
+All the current RISC-V backends work in a similar way as Cortex-M devices with priority ceiling.
+Therefore, the [Resources](../by-example/resources.html) page of this book is a good reference.
+However, some of these backends are not full hardware implementations, but use software to emulate
+a physical interrupt controller. Therefore, these backends do not implement hardware tasks, and
+only software tasks are needed. Furthermore, the number of software tasks for these targets is
+not bounded by the number of available physical interrupt sources.
+
+Table 2 below compares the available RISC-V backends.
+
+#### *Table 2: Critical Section Implementation by Processor Architecture*
+
+| Backend                 | Compatible targets            | Backend-specific configuration | Hardware Tasks | Software Tasks | Number of tasks bounded by HW |
+| :---------------------: | :---------------------------: | :----------------------------: | :------------: | :------------: | :---------------------------: |
+| `riscv-esp32c3-backend` | ESP32-C3 only                 |                                |        ✓       |        ✓       |               ✓               |
+| `riscv-mecall-backend`  | Any RISC-V device             |                                |                |        ✓       |                               |
+| `riscv-clint-backend`   | Devices with CLINT peripheral |                ✓               |                |        ✓       |                               |
+
+
+### `riscv-mecall-backend`
+
+It is not necessary to provide a list of dispatchers in the `#[app]` attribute, as RTIC will generate them at compile time.
+Priority levels can go from 0 (for the `idle` task) to 255.
+
+### `riscv-clint-backend`
+
+It is not necessary to provide a list of `dispatchers` in the `#[app]` attribute, as RTIC will generate them at compile time.
+Priority levels can go from 0 (for the `idle` task) to 255.
+
+You **must** include a `backend`-specific configuration in the `#[app]` attribute so RTIC knows the ID number used to identify the HART running your application.
+For example, for `e310x` chips, you would configure a minimal application as follows:
+
+```rust
+#[rtic::app(device = e310x, backend = H0)]
+mod app {
+  // your application here
+}
+```
+
+In this way, RTIC will always refer to HART `H0`.

book/en/src/starting_a_project.md

@@ -12,6 +12,25 @@ protection using [`flip-link`]. There is also a multitude of examples provided b
 
 For inspiration, you may look at the [RTIC examples].
 
+## RTIC on RISC-V devices
+
+Even though RTIC was initially developed for ARM Cortex-M, it is possible to use RTIC on RISC-V devices.
+However, the RISC-V ecosystem is more heterogeneous.
+To tackle this issue, currently, RTIC implements three different backends:
+
+- **`riscv-esp32c3-backend`**: This backend provides support for the ESP32-C3 SoC.
+  In these devices, RTIC is very similar to its Cortex-M counterpart.
+
+- **`riscv-mecall-backend`**: This backend provides support for **any** RISC-V device.
+  In this backend, pending tasks trigger Machine Environment Call exceptions.
+  The handler for this exception source dispatches pending tasks according to their priority.
+  The behavior of this backend is equivalent to `riscv-clint-backend`.
+  The main difference of this backend is that all the tasks **must be** [software tasks](./by-example/software_tasks.md).
+  Additionally, it is not required to provide a list of dispatchers in the `#[app]` attribute, as RTIC will generate them at compile time.
+
+- **`riscv-clint-backend`**: This backend supports devices with a CLINT peripheral.
+  It is equivallent to `riscv-mecall-backend`, but instead of triggering exceptions, it triggers software interrupts via the `MSIP` register of the CLINT.
+
 [`defmt`]: https://github.com/knurling-rs/defmt/
 [`flip-link`]: https://github.com/knurling-rs/flip-link/
 [RTIC examples]: https://github.com/rtic-rs/rtic/tree/master/examples