Modular RTIC roadmap

[korken89]

Here is the draft roadmap for the modular RTIC. The PoC implementation already checks a majority of the check-boxes here in different phases, so I don't think there will be much real work that needs to be done.

Please come with feedback in the meetings so we can keep this up to date.

RTIC Modular Rewrite Roadmap (Work in Progress)

Phase 1: Architecture and Diagnostic Foundation

• Define new crate structure (maybe based on the thesis?:
  • rtic-core, rtic-sw-pass, rtic-macros, rtic-dist-*, etc).
• Define the pass API:
  • Each pass receives a typed app representation
  • Returns Result<TokenStream, DiagnosticSet>, where DiagnosticSet tracks errors back to the user code for each pass
• Set up a shared RticError enum and diagnostic collector
• Integrate syn::Error and proper span tracking for user-facing diagnostics
• Ensure broken DSL input results in clear, actionable compile-time errors

Phase 2: Compilation Pass Infrastructure

• Implement multipass macro harness
• Add feature-gating for enabling/disabling individual passes
• Implement passes for:
  • #[init] and #[idle] functions
  • Shared and local resources
  • Hardware task declarations and bindings
• Implement a software task pass (e.g. modeled after rtic-sw-pass)
• Ensure passes can emit multiple errors with accurate spans
• Create developer-friendly error output (maybe a helper somehow, such as a cargo rtic-check command)
• Add regression tests for expected errors and invalid inputs (UI tests)

Phase 3: Backend and Distribution Architecture

• Design BackendTrait for abstracting hardware-specific behavior (e.g. pend interrupts)
• Implement a reference backend (e.g. Cortex-M)
• Create a distribution crate that:
  • Assembles the passes and backend
  • Defines the procedural macro entry point
• Ensure hardware-specific code only lives in backends or distribution crates

Phase 4: Testing and Tooling

• Build example applications:
  • Minimal app with init, idle, and hardware tasks
  • Application using software tasks and shared resources
• Create tests for macro expansion and error output
• Add CI jobs to check that examples compile, macro output is stable, and errors are correct
• Create a template/helper to scaffold new RTIC distributions

Phase 5: Pilot Integration and Feedback

• Port a few existing RTIC applications to the new architecture
• Evaluate gaps, friction, and developer experience
• Adjust pass boundaries, backend traits, or DSL syntax as needed
• Write documentation for contributors, including how to:
  • Write a new pass
  • Build a new backend
  • Extend/create a distribution crate

Ongoing

• Keep the roadmap and changelog (needs to be created) updated
• Review architecture and pass interactions in weekly meetings
• Maintain high-quality examples and error coverage
• Track and resolve developer pain points during adoption

[perlindgren]

Nice! As mentioned the PoC implementation covers many of the mentioned checkpoints. Naming is always difficult (and documentation needs to be updated accordingly).

For an earlier version of the PoC, we developed a new pass from scratch, along with a new backend. Both were completed in a couple of hours, no major hickups. The codegen for the the new pass was only changing the structure (so target agnostic). We need examples with hardware dependent codegen as well. The distro part (for the backend) was really minimal, its just a few traits to implement. Most time went into understanding and navigate the structure.

Docs and tutorials both for devs and end users are of course important. I think the rust-doc generated documentation could serve quite well at api level along with step by step guides and usage examples would make it easier to approach.

[TheOpenDevProject]

Where are you actually building this, would love to contribute to it

[AfoHT]

Where are you actually building this, would love to contribute to it

Here on github, this issue being initial roadmap. All contributions welcome!

[TheOpenDevProject]

@AfoHT We've decided to start taking on this work as a company and will be coming with PRs in the coming months

[AfoHT]

@AfoHT We've decided to start taking on this work as a company and will be coming with PRs in the coming months

Exciting!

Are you able to join us to plan ahead on the regular Wednesday meeting at 20:00 CET? RTIC matrix room I mean