[Discussion] `digital` marker traits, such as `digital::StronglyDriven`, `digital::OpenDrain`, `digital::OpenCollector`, etc.

Open
#49 1 comment 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 the Rust BitBangedI2c example and the proposed digital marker traits in this discussion. No repository file or test is named, so first determine where the digital trait API belongs and whether the design has been decided. Done would require an agreed trait design rather than an isolated implementation.

Written by the indexing model from the issue text.

Description

discussion

Many MCUs (the STM32s especially) implement a plethora of different output options for their GPIO pins. A driver generally has specific output requirements for its pins -- but enforcing these with API traits will mean there will be many traits available, all implementing similar or identical APIs -- i.e. OutputStronglyDrivenPin, OutputOpenDrainPin, OutputOpenDrainPullupPin, etc.

Advantages

  • One API for high-level pin mode (IoPin, InputPin, OutputPin), with additional traits providing fine-grained configurability
  • Unusual combinations easy to express (OutputPin + OpenDrain + PullUp)

Disadvantages

  • Possible huge proliferation of implementer types
    • The actual pin driving code will likely look similar for all, but initialization will be different. Does this force too much duplication/boilerplate?
    • Could this be handled by a builder-like pattern? i.e. pin init functions which consume a type with/without the marker trait, change the config, and return a type without/with the trait?
  • Possibility of expressing impossible bounds (i.e. OutputPin + StronglyDriven + OpenDrain).
    • Mostly a problem from the driver writer's standpoint, and it will become quickly clear that no available HAL provides the type needed

Example driver usage

pub struct BitBangedI2c<D, C> {
    sda: D,
    scl: C,
}

impl<D, C> BitBangedI2c<D, C> {
    pub fn new<D, C>(sda: D, scl: C) -> BitBangedI2c<D, C>
    where
        D: digital::IoPin + digital::OpenDrain,
        C: digital::IoPin + digital::OpenDrain,
    {
        BitBangedI2c { sda, scl }
    }
}
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.