Skip to content

Commit

Permalink
docs: content related to systick
Browse files Browse the repository at this point in the history
  • Loading branch information
decaday committed Dec 2, 2024
1 parent ba3f660 commit 53f3681
Show file tree
Hide file tree
Showing 2 changed files with 46 additions and 2 deletions.
6 changes: 4 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,7 @@ For a full list of chip capabilities and peripherals, check the [py32-data](http
- TODO: I haven't got a dev board yet, help-wanted
- N/A: Not available

### TODOs
## TODOs

Too many...

Expand All @@ -88,7 +88,9 @@ Too many...

This crate provides an implementation of the Embassy `time-driver`.

Embassy requires that any TIM used as a time-driver has at least two channels, so only TIM1 and TIM3 are available for the PY32F030, 003, and 002A series. You can select either `time-driver-tim3` or `time-driver-tim1` to specify the TIM to use.
Embassy requires that any TIM used as a time-driver has at least two channels, so only TIM1 and TIM3 are available for the PY32F030, 003, and 002A series. You can select either `time-driver-tim3` or `time-driver-tim1` to specify the TIM to use.

`time-driver-systick`: Although we do not recommend using it and there are some shortcomings, it does work. For details, please see [systick-demo](examples/systick-time-driver-f030/README.md)

## Minimum supported Rust version(MSRV)

Expand Down
42 changes: 42 additions & 0 deletions examples/systick-time-driver-f030/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
## Systick Time-Driver Demo

Although we do not recommend using it and there are some shortcomings, it does work (after all, some chips lack sufficient multi-channel timers).

Currently, the `systick-time-driver` implementation in `py32-hal` uses a retry loop. The reload value register (RVR) of the Systick timer is set to a fixed value, causing high-frequency interrupts. During these interrupts, it updates the tick count and checks whether any alarm has expired (since Systick lacks compare-capture functionality).

The interrupt frequency of Systick matches the tick frequency configured for `embassy-time`. It is **not recommended** to use excessively high frequencies because `time-driver-systick` generates frequent interrupts, unlike `time-driver-timx`. Additionally, `time-driver-systick` updates the tick count and wakes up alarms in software, which takes longer.

### Usage

Enable the `time-driver-systick` feature. Then, before initializing `py32-hal`, add the following:

```rust
use cortex_m::Peripherals;
let cp = Peripherals::take().unwrap();
let systick = cp.SYST;
```

Pass the `systick` instance during initialization:

```rust
let p = py32_hal::init(Default::default(), systick);
```

Complete code demo can be found in the same directory as this documentation.

### Feature: `td-systick-multi-alarms`

By default, only one alarm is provided (similar to a 2-channel timer). Enabling this feature provides three alarms (similar to a 4-channel timer).

Of course, this will also increase the execution time of the interrupt handler.

### More

[SysTick time driver · Issue #786 · embassy-rs/embassy](https://github.com/embassy-rs/embassy/issues/786)

Here are the key disadvantages of using **SysTick** as a time-driver:

- **Clock Source Uncertainty**: SysTick supports two clock sources, but their speeds are not known at compile time, requiring vendor-specific runtime translation.
- **Interrupt Limitation**: SysTick can only trigger an interrupt at zero, complicating setting alarms for specific points in the cycle.
- **Dual-Core Challenges**: On dual-core devices like the RP2040, each core has an independent SysTick timer with no cross-access.
- **Perturbation Issues**: Modifying the counter register while counting can perturb the overall tick count, affecting timing accuracy.

0 comments on commit 53f3681

Please sign in to comment.