Trait RticBoardEntry 

pub trait RticBoardEntry: Board {
    type Pac: 'static;
    type Core: 'static;
    type Executor: 'static;
    type Runtime: NodeDispatchRuntime + 'static;

    const DISPATCHERS: &'static [&'static str];

    // Required method
    fn init_hardware(
        device: Self::Pac,
        core: Self::Core,
    ) -> (Self::Executor, Self::Runtime);

    // Provided method
    fn init_hardware_with_deploy(
        device: Self::Pac,
        core: Self::Core,
        _deploy: &DeployOverlay,
    ) -> (Self::Executor, Self::Runtime) { ... }
}

Board-side hook for RTIC integration. The nros::main!() proc-macro (216.B.3) generates a #[rtic::app] module that calls Self::init_hardware from inside the framework-generated #[init] body and wires the returned pair into RTIC #[local] storage.

Distinct from super::BoardEntry (board-owns-spin) and [planned] EmbassyBoardEntry (216.C.1, executor-owns-spin via embassy_executor::Spawner).

Required Associated Constants

const DISPATCHERS: &'static [&'static str]

RTIC dispatchers = [...] list, declared at the board layer so each chip pins its own interrupt slots (e.g. &["USART1", "USART2"]). The proc-macro splices this into the generated #[rtic::app(dispatchers = …)] attribute.

Required Associated Types

type Pac: 'static

Chip Peripheral Access Crate handle (e.g. stm32f4xx_hal::pac::Peripherals). Whatever the RTIC #[rtic::app(device = …)] attribute expects as the device peripheral struct.

type Core: 'static

Core peripheral handle. Typically cortex_m::Peripherals on Cortex-M chips but kept abstract so nros-platform doesn’t take a transitive cortex_m dep that every POSIX / Zephyr / RTOS consumer would inherit.

type Executor: 'static

Executor type the board hands back. Concrete board impls plug in nros::Executor; the assoc type keeps the layering clean (nros-platform does not depend on nros). The proc-macro stashes this value in RTIC #[local] storage.

type Runtime: NodeDispatchRuntime + 'static

Dispatch sink the proc-macro wires into RTIC #[local] storage. Required to implement NodeDispatchRuntime so signaled callbacks queued from RTIC tasks reach the registered Node pkgs.

Per Phase 216.A.2, NodeDispatchRuntime already carries signal_callback + dispatch_strategy; the RTIC runtime impl uses DispatchStrategy::Deferred and routes signals through a heapless::spsc::Producer into an RTIC software task (see Phase 216.B.2).

Required Methods

fn init_hardware( device: Self::Pac, core: Self::Core, ) -> (Self::Executor, Self::Runtime)

Run from inside the proc-macro-generated #[init] body. Returns the (Executor, Runtime) pair the macro stashes in RTIC #[local] storage. The board impl owns clock / pin / transport bringup before constructing the executor + runtime pair.

Provided Methods

fn init_hardware_with_deploy( device: Self::Pac, core: Self::Core, _deploy: &DeployOverlay, ) -> (Self::Executor, Self::Runtime)

Like init_hardware but applies a deploy-metadata overlay (Phase 244.D1) to the board’s compiled-in net/locator Config before opening the executor. nros::main!() calls THIS from the generated #[init] body, passing the [package.metadata.nros.deploy.<board>] block.

The default ignores deploy and forwards to init_hardware, so existing RTIC boards are unchanged. Boards with a baked net Config (the bare-metal firmware boards) override it so each Entry pkg can pin its own ip / locator / gateway — required when two RTIC firmwares share one board on the same QEMU network (e.g. the talker-rtic / listener-rtic pub/sub pair).

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementors