Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Question about CAN abstractions

Open
  • Is something wrong?
#657 0 comments 3 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 by reading the CAN frame trait, especially its constructors and Frame::is_extended, then inspect the device-driver transmit and reception APIs. Compare the current abstractions with the proposed CanTx and CanRx split. Done would require an agreed API design and corresponding implementation scope, which the issue does not yet define.

Written by the indexing model from the issue text.

Description

I have a few question and possibly improvement suggestions for the CAN library

  1. Is there a special reasons why the CAN frame trait contains constructors? How would those be used, and be better than more explicit custom constructors for the actual frame types inside libraries?

  2. For device drivers, the transmit function already assumes a constructed frame, and for reception.. Wouldn't an API just expect the user to somehow take care of polling CAN frames and pass them to the driver? Maybe it would make more sense to have something like CanTx trait which only provided transmit functions, and possibly a specialized CanRx? I still think it is easier for device drivers to just assume the user takes care of polling CAN frames, and offer an API which consumes frames (probably re-using the CAN frame trait to remain generic)

  3. Any reason not to provide a default implementation for Frame::is_extended?

    /// Returns true if this frame is an extended frame.
fn is_extended(&self) -> bool {
    match self.id() {
        Id::Standard(_) => false,
        Id::Extended(_) => true,
    }
}
Dominant language
Rust
Stars
2.7k
Forks
283
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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.