Shared type definitions (e.g. MHz, bps...)
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- embedded-iot
Research direction
Start by reviewing the time definitions in stm32f30x_hal::time and stm32f103xx_hal, then compare them with the embedded-hal crate. Determine whether a shared type module belongs in embedded-hal or a separate crate, and which hardware types are in scope. Done means the location and scope are agreed and the shared definitions are specified for implementation.
Written by the indexing model from the issue text.
Description
I want to create this issue to discuss a shared place to store necessary hardware type definitions. These could be stored in the embedded-hal crate, but could also easily be in their own crate. I just think we should discuss a shared place to store these outside the processor specific crates.
There are many type definitions that can be useful when working with low-level sensors. At the moment there are no shared place that such type can or are stored. A couple of very handy types are currently in stm32f30x_hal::time (and also replicated in stm32f103xx_hal) for dealing with time.
An easy first step is to create a type module for embedded-hal and extract the types defined in stm32f30x_hal::time and potentially add more later if necessary.
I'm not sure if there are other definitions apart from time that should be abstracted out. I don't think this issue should be about physical types (e.g. cm or m/s), but should focus on shared types that are necessary for interacting with hardware.
- Dominant language
- Rust
- Stars
- 2.7k
- Forks
- 282
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rust-embedded/embedded-hal
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
rust-embedded/embedded-hal#742 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
rust-embedded/embedded-hal#747 · 5 comments · 1 reaction ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
rust-embedded/embedded-hal#746 · 2 comments · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
rust-embedded/embedded-hal#745 · 1 reaction ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
rust-embedded/embedded-hal#744 · 1 comment ·
All issues in rust-embedded/embedded-hal
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
kwakseongjae/auto-hwp#319 ·
-
area:cli bug filter-quality good first issue priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
bevyengine/bevy#25861 ·
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
enhancement remote
Difficulty 2/5 1-3 hours Newbie friendliness 68/100