diff options
Diffstat (limited to 'book/en/src/internals')
| -rw-r--r-- | book/en/src/internals/targets.md | 48 |
1 files changed, 46 insertions, 2 deletions
diff --git a/book/en/src/internals/targets.md b/book/en/src/internals/targets.md index 67c6a59..210b381 100644 --- a/book/en/src/internals/targets.md +++ b/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`. |