RustWeek unconf 2026

[diondokter]

Let's use this as the place to collect all results from the unconf. This is for future reference and for people who couldn't attend.

[diondokter]

Vendor support discussion:

https://hackmd.io/@diondokter/r1bLaEnkfg

[jonathanpallant]

I want to note that derive-mmio and safe-mmio also exist and are valid options for creating a PAC.

[qwandor]

Actions from platform abstraction discussion:

• Look into mutually exclusive features / better support for global config flags.
  • If there's some support in cargo, other tooling (e.g. rust-analyser) might be able to support it better.
• Better cargo errors / diagnostics for when they are misused.

For supporting multiple targets:

• Some way to support multiple perspectives in an editor, either in one instance or in separate instances. If this were supported in a consistent way in cargo then editors would likely integrate with it.
• Being able to configure a different default target per binary / crate in a workspace (via .cargo/config.toml or similar) would be helpful.
• Some way to depend on multiple instances of the same crate, with different sets of features (something like generics).

[datdenkikniet]

Link to the pre-RFC for mutually exclusive features

[Wassasin]

With regards to new releases for embedded-storage, a breaking release is not a major issue; both HALs, storage drivers and filesystems can implement all traits (the same holds for any other embedded-hal trait). But do try to make a breaking release worth the effort.

[Wassasin]

We also briefly discussed the merits of https://github.com/diondokter/unified-storage. Please contribute if it is of interest to you.

[Wassasin]

Dion will make a minor release with non-breaking changes by temporarily reverting the breaking changes.

[SeanLyonsTI]

Notes from UB for Embedded discussion:

• What are we trying to detect: Interfacing with hardware or interfacing with C/FFI/asm blocks
• Classes of bugs that could be detected: non volatile to access MMIO, mixed access to a given memory address from the Rust and FFI
• Should talk with Nia Espera who did a similar talk on Miri to understand how that was done (FFI in Miri at 8000 segfaults per second)
• What we want: We want miri to be able to look at the FFI boundary and then warn us when we do something unsound on the rust side afterwards
• Need to investigate ideas about how to run Miri at all on embedded
• What are the alternatives? Clippy is being extended, but it cannot detect this with without annotations.
• Trust in soft says they have a static analyzer for Rust, but this is a paid product. ref: https://www.trust-in-soft.com/

[tdittr]

Mock out assumptions of C calls in #[cfg(miri)], document where the assumptions come from

[jnkr-ifx]

Timer and Alarm Trait: https://hackmd.io/@jnkr-ifx/S1Lplv3kGg

[diondokter]

Crate released: https://crates.io/crates/embedded-hal-timer

[diondokter]

PR using the crate for embassy-time: embassy-rs/embassy#6168

[qwandor]

Multi-binary / multi-target build systems, and binaries with different sections: https://hackmd.io/@CyReVolt/r1oXkK3yze

[Rondom]

403 Forbidden

[diondokter]

I attended the all-hands binary size session.
Notes here: https://hackmd.io/@nia-e/SyeEXgq1fe

Not everything is relevant to embedded though.
Polymorphization is interesting though.

Outliner has been touched upon. Nikita Popov thinks there's not much interest in the outliner in the LLVM project, so it's unlikely to become better.

Cutting parts out of the std is being asked by Rust for Linux. Not clear if that's gonna be helpful for embedded.

Build-std is 'close' and would open up more avenues of optimization.

[tdittr]

Hardware-in-the-loop testing

• Tamme presented his https://github.com/tweedegolf/embedded-conformity & https://github.com/tdittr/conformity-shield/
  • Goal is to measure and/or inject behaviour of the DUT
  • Using probe-rs as a library, the DUT and the testing shield can be flashed simultaneously
  • Ideally, the test outputs fine-grained output for more nuanced differentiations, for example back-to-back I²C reads or writes
  • Downside vs. loopback tests is that another device is needed
  • Synchronization between DUT and Tester is done via RTT, Tamme originally hoped to do without debugging, but it is required in order to detect panics
  • Firmware lives at https://github.com/tweedegolf/embedded-conformity
  • Hardware Rev. 1 had some bug, Rev. 2 works but only at USB Full Speed, root cause t.b.d, but Rev. 3 won't have any bugs ;)
  • Tamme wrote a list of traits that should be tested
  • There's interested in Cryptography tests, e.g. to see if they are constant time
  • The PIO on the RP2354 can clock at 200 MHz https://github.com/gusmanb/logicanalyzer is a 24-channel 100 Msps logic analyzer built using RP2350 (in C)
  • Manuel gave some insight on whether this testing is relevant for safety-critical Rust
    • Essentially, the crux is in writing requirements, which is a significant effort
      • Many companies have their requirements already inside an external database, so linking to the external source might be an option there
    • For coverage tracing, source instrumentation can influence runtime behaviour, so in safety-critical applications another test is run without instrumentation to ensure the results are consistent
  • One problem is assigning which device is which, there is a .toml file in embedded-conformity, where you can write down the serial number
    • One possible improvement is letting probe-rs identify the ICs and if there is only one possible solution, auto-assign the serial numbers
    • Or traverse the USB tree and find which ICs are on the same parent node
  • On testing other protocols: For ethernet, testing on the (R)MII level would probably require an FPGA due to speeds, but if things on OSI Layer 2 and above are to be tested, connecting a USB to Ethernet adapter to the PC running the test is probably easiest
  • For CAN, Julius mentioned they are injecting into CANH/CANL using a RP2040 and will probably open-source that soon
  • Tamme would like to see a collection of blog posts etc. about HIL testing in embedded Rust

Thanks to @joelsa for the notes

[bergzand]

RTOS <-> binary blob interfacing discussion

Raw notes here: https://hackmd.io/cmB9pp70SMS_yMeDjyQ9lA

Question 1: There are existing non-Rust RTOSes, how to run Rust on there?
Question 2: There are existing binary blobs, how to run them on Rust?

• Embassy has into this issue with some Wifi stuff, some Vendor binary blobs require some sort of Threading/RTOS to be there
• The other way around is also common, you are stuck with an RTOS for legacy/vendor/compatibility reasons and want to integrate Rust code there
• A classical example for peripherals that only have binary blobs available is connectivity/bluetooth stuff or Crypto cells

In order to make this interop eventually work, we will need some glue code in between
How to make that work? We can either push the vendors…
What has already been done?

• For the cyw peripheral on the Pico, that's wrapped into a crate with the binary blob included, but this binary blob is something else, because it is just sent to the cyw IC and communication is then just done using datalines

• A better example is on the ESP32 where they created some traits / macros that need to be implemented to use wifi, bluetooth.

  • It is a C binding with some Rust code on top to make it more ergonomic to use out of Rust
    Interrupts probably need to be wired to the code

• A good advice to silicon vendors would be: If you want to have a blob that needs scheduling, please create a trait that needs to be implemented for it to work, here is an example how that could look like.

Next proposed steps for us

To achieve the end goal of a document with recommendations that can be passed to silicon

@bergzand: there exist three rough classes of blob types
@mbrossard: It might be better to just collect typical patterns that exist and create a taxonomy to seer what exists and what's missing.

If the existing patterns involved reverse engineering, this shows that something is missing.
Do we have enough public cases (because some SoC etc. might be behind NDAs) that we can build a complete enough picture? We have enough examples to come up with at least one or two patterns. Then we need to categorize what we actually need to represent those patterns.

• Collect existing patterns and crates
• See if there is a common pattern that can be reused
• Create a document to display a list of common patterns identified, inside Embedonomicon if acceptable, e.g. in a similar place like https://docs.rust-embedded.org/embedonomicon/soc-support.html, serving as an inspiration for vendors what they could create. In that document also list examples for different categories, "this is what we would recommend as a starting point". Start simple, extend later.
• Should we recommend a preferred strategy among the patterns if there are multiple suitable ones? Maybe even name things to avoid.
• We need someone who leads this process

Thanks to @joelsa for the notes

---

I've drafted an initial document together with @nponsard and @SeanLyonsTI a day later with initial taxonomy on different blobs: https://pad.riot-os.org/blob-taxonomy