Using `Delay` via shared references

Open
#435 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
rust
Domain
embedded-iot

Research direction

Start with this issue and the linked rust-embedded/book issue 246, then review how Delay methods currently take &mut self. Compare the listed sharing approaches and determine whether the project can state a recommendation or needs an API change. Done means an agreed, documented direction for sharing Delay across multiple users.

Written by the indexing model from the issue text.

Description

This is mentioned in https://github.com/rust-embedded/book/issues/246: what is the recommended way to share a Delay?

Currently all the Delay methods take a mutable self reference, e.g. Delay::delay_x(&mut self, val: u32). This makes it pretty tricky to use a delay in more than one place since you only get one (at least in atsamd-hal). A couple possible solutions I see:

  • HAL crates make their Delay be cloneable (possibly !Send/!Sync in these cases) or otherwise provide a way to get >1 impl Delay objects
  • Users provide a impl Delay type that is a RefCell around a Delay. That is what I currently plan on doing, but it's kind of icky (10+ extra steps to borrow_mut a delay is deadly)
  • Change these function signatures to take &self rather than mut, and HAL crates internally keep a RefCell or something to make this work. Also icky, since your delays become failable.
  • Driver libraries always use Countdown instead of drivers

So, I'm just curious what the recommendation is

Dominant language
Rust
Stars
2.7k
Forks
282
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rust-embedded/embedded-hal

All issues in rust-embedded/embedded-hal

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.