Add FW-Compatible Bare Metal Support

[JustinKovacich]

This update does a massive refactor on the underlying Simple Someip components to allow compilation on bare metal with no allocations and allowing traits to be used to handle alternative socket implementations.

[Copilot]

Pull request overview

Copilot reviewed 51 out of 53 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 51 out of 53 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 51 out of 53 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 50 out of 53 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 50 out of 53 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 50 out of 53 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[JustinKovacich]

Will a user be able to compile this on bare metal? What do adoption steps look like?

● Honest answer: partially yes, with significant gaps. Let me be specific about what works today and what doesn't.

What compiles on a true no_std target today

cargo build --no-default-features --features bare_metal:

• ✅ protocol::* — full SOME/IP wire format encode/decode (zero-alloc)
• ✅ e2e::{E2EChecker, E2EProtector, E2EProfile, ...} — the per-message protect/check operations
• ✅ transport::* traits (TransportSocket, TransportFactory, Timer, Spawner, LocalSpawner, ChannelFactory, InterfaceHandle, E2ERegistryHandle)
• ✅ static_channels::* no-alloc channel pool primitives + define_static_channels! macro
• ✅ AtomicInterfaceHandle
• ✅ traits::{WireFormat, PayloadWireFormat}

What does NOT compile on a true no_std target today

Look at Cargo.toml:
client = ["std", "dep:futures"]
server = ["std", "dep:futures"]

The client and server features force std. So:

• ❌ Client::new_with_deps / Client::new_with_deps_local — requires std
• ❌ Server::new_with_deps — requires std
• ❌ EventPublisher — requires std
• ❌ SubscriptionManager — requires std (uses std::sync internally even though most state is heapless)
• ❌ E2ERegistry — uses HashMap, fundamentally std
• ❌ StaticE2EHandle — gated on + std for the above reason

The bare_metal feature is honest about its contribution (no-alloc channels, atomic interface handle), but the Client/Server engines themselves are not bare-metal-ready today. A cortex-m / RISC-V
firmware target without std cannot drive a Client run-loop.

Adoption paths today

Path A — std-on-embedded host (Linux on Cortex-A, Hifive Unmatched, container):
simple-someip = { version = "0.8", default-features = false,
features = ["client", "bare_metal"] }
embassy-sync = "0.6"

1. Implement TransportFactory + TransportSocket over your UDP stack (smoltcp, embassy-net, raw socket, etc.).
2. Implement Timer over your runtime's sleep.
3. Implement Spawner (or LocalSpawner for single-task).
4. define_static_channels! { name: MyChannels, oneshot: [...], bounded: [...], unbounded: [...] } sized to your workload's high-water mark.
5. Provide an E2ERegistryHandle (use StaticE2EHandle if std is on, or provide your own).
6. Build a ClientDeps, call Client::<MyPayload, _, _, MyChannels>::new_with_deps(deps, false).
7. spawner.spawn(run_fut) and proceed.

This works. examples/bare_metal_client/ demonstrates it end-to-end (the example name is somewhat misleading — it's actually "trait-surface bare-metal-shaped, but std-hosted").

Path B — true no_std cortex-m / RISC-V firmware:
You can use the protocol layer + traits + static_channels, but you have to write your own session loop because Client/Server are unreachable. Concretely:

1. Use protocol::Header + Message to encode outgoing requests.
2. Use protocol::MessageView + e2e::E2EChecker to parse and verify incoming bytes.
3. Use static_channels-backed OneshotPool / MpscPool directly to wire up request→response correlation.
4. Drive everything from your own embassy_executor task.

You're getting wire-format library + channel primitives but not the orchestration layer. That's still useful for many firmware embedders, but it's not "drop in Client::new_with_deps and you're done."

Path C — workspace example as a starting template:
examples/bare_metal_client/src/main.rs shows the full Path A wiring including custom MockFactory, MockSocket, MockTimer, Spawner — copy-pasting these and replacing the mock with a real network backend
is the realistic starting point.

What's missing for true no_std cortex-m

To actually support the cortex-m no_std story, the work needed is:

1. Port E2ERegistry off HashMap to heapless::FnvIndexMap (~1 day).
2. Drop std from client / server features (loosen lock-handle traits and SubscriptionManager defaults; ~3-5 days, mostly hunting std::sync references and replacing with the trait abstractions).
3. Add a no_std CI gate (cargo build --target thumbv7em-none-eabihf --no-default-features --features client,bare_metal) to keep regressions out.

That's cortex-m readiness — phase 18 worth of work; the trait-surface scaffolding and the static-pool channels are in place, but the Client engine itself still requires std.

Bottom line for a prospective adopter

• "My target is Linux on Cortex-A and I want zero-alloc after init": ✅ Works today via Path A. Roughly half a day of integration work for the four trait impls.
• "My target is no_std cortex-m and I want to drop in Client::new_with_deps": ❌ Not today. You can use the protocol library and channel primitives but must write your own state machine.
• "My target is no_std cortex-m and I want the full Client engine": That's a future port; the trait surface from this PR makes it tractable but the work isn't done.