rust-embedded / rust-embedded/cortex-m

Vector Implementation

Open
#569 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
1k
Forks
202
Avg merge
6d 2h
Merged PRs (30d)
2

Description

In the cortex-m-rt docs it recommends PACs create a Vector type like so:

pub union Vector {
    handler: unsafe extern "C" fn(),
    reserved: usize,
}

and this is exactly what PACs do. I'm curious why it is like this? The reserved variant being typed as usize when it should always be 0 and constructed like:

Vector { reserved: 0 }

is very odd to me.

Why not define Vector like this:

pub struct Vector(#[allow(unused)] *const ());

impl Vector {
    /// Create a vector with the provided function pointer.
    pub const fn handler(f: unsafe extern "C" fn()) -> Self {
        Self(f as _)
    }

    /// Create a vector that is reserved.
    pub const fn reserved() -> Self {
        Self(core::ptr::null())
    }
}

and use it like this:

pub static __INTERRUPTS: [Vector; 2] = [
    Vector::handler(Foo),
    Vector::reserved(),
];

and why is this type not provided by cortex-m-rt so PACs don't have to redefine it every time?

I imagine there is some low-level issue with representing the function pointer as a unit pointer that I don't know of.

I am currently using my proposed Vector implementation and it does work, I'm just not sure if it is correct.

Thanks!

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.

Research direction

Read the cortex-m-rt documentation and the PAC Vector definitions referenced in the issue first. Check whether the proposed pointer representation preserves the required vector-table behavior and whether cortex-m-rt should expose a shared type; done means a documented decision on correctness and API ownership.

Written by the indexing model from the issue text.

Assessment

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.