Meeting 2025-04-29

[adamgreig]

This is the agenda for the next meeting. Please add anything you'd like to discuss below!

• Meetings: Tuesday 8pm Europe/Berlin time
• Join the Matrix chat
• Nominated issues
• IRC/Matrix logs

Ongoing member cleanup: #832

[rmsyn]

SD/MMC trait RFC:

• tracking issue: [RFC] [proposal] mmc: add types + traits for SD/MMC peripherals embedded-hal#661
• pull request: sdmmc: add HAL traits for SD/MMC peripherals embedded-hal#662

Requesting review + feedback on the design and implementation. Very open to any changes people would like to see.

[newAM]

hash32 is close to a 1.0.0 release. hash32 is a notable dependency of heapless that provides 32b hashing algorithms for the indexmap and indexset types.

• 1.0.0 changelog: https://github.com/rust-embedded-community/hash32/blob/b69fd5205d8d20e00447a823bfa5454338aa35e7/CHANGELOG.md
• 1.0.0 release discussion: roadmap to v1.0.0? rust-embedded-community/hash32#17

If you use hash32 directly or indirectly I would appreciate reviews / feedback before the 1.0.0 release!

[jonathanpallant]

If I'm reading your changelog right, are you about to raise the MSRV to 1.85?

[newAM]

Sort of, the MSRV is still 1.56. hash32 contained a copy of core::hash::BuildHasherDefault with a const method, which is now const in core::hash::BuildHasherDefault as of 1.85.

I don't anticipate this being a problem for ferrocene + heapless 1.0 because the heapless 1.0 release likely won't happen before ferrocene reaches 1.85.

More discussion is here: rust-embedded-community/hash32#30

[jonathanpallant]

I discussed this with the team, we agree with you.

[BartMassey]

I know I asked on Matrix and then never followed up — uggh — but I would still like to discuss the possibility of making link.x in cortex-m and maybe other embedded crates idempotent. I think this would be an improvement, in that by putting -Tlink.x anywhere and everywhere we might ensure that it is always somewhere. I don't know how easy or even possible it is, being ignorant about linker scripts.

[romancardenas]

The RISC-V team has been working towards making your suggestion possible: rust-embedded/riscv#274 rust-embedded/riscv#275

[jamesmunns]

@BartMassey have you been able to capture a repro of this issue? It's not something I've actively seen before, might be good to analyze what went wrong before we make any changes based on it?

[BartMassey]

The RISC-V team has been working towards making your suggestion possible: rust-embedded/riscv#274 rust-embedded/riscv#275

This isn't quite the same, but is definitely related and is cool nonetheless. Thanks!

[BartMassey]

@BartMassey have you been able to capture a repro of this issue? It's not something I've actively seen before, might be good to analyze what went wrong before we make any changes based on it?

It seems to happen mostly on Macs, which I don't have. I have not reproed it on Linux, nor gotten any reports that make me think I should be able to.

I'll try to gather more details before the meeting if I can find time. There are a couple of issue reports on the Books, and also some student issues I have lying around.

I was suggesting idempotency because it seems "mostly harmless": easier to achieve one-or-more than exactly-one, and they are likely all the same anyhow.

[jamesmunns]

I'd like to try and compile a list of "known papercuts" in embedded Rust today as a conversation for the all-hands, and try to compile a single document/blog post of items triaged into roughly:

• Has a PR, needs to be merged/upstreamed/stabilized
• Has buy-in that it should be fixed, needs someone to solve it
• Needs research into how to solve it/fully explain the issue
• Totally unknown how to solve it

Even for "well known" stuff like:

• Format bloat
• Async stack size doubling
• Async code size bloat

[rursprung]

one thing which regularly seems to come up on matrix (and which i also hit several times) is that it's currently not possible to have one cargo workspace with packages with different targets. this is e.g. relevant when building a postcard-rpc application (picked as a random example, many more exist): as shown by your own example code there are (a) a generic library, (b) a binary targeting the host and (c) a binary targeting the embedded system.
currently there's no way to have all three of them open in a single workspace.

it'd be great if it'd be possible to have a normal cargo workspace with all these crates in them, open it in an editor and cargo run the different packages from the workspace.

in that case it'd then also be possible to have crates targeting different embedded targets (e.g. because your application supports multiple embedded targets and has a shared library).

tracking issue: rust-lang/cargo#9406

[HaoboGu]

Another thing is the weak linkage feature or externally implementable consts. Related issue: rust-lang/rust#134451
rust-lang/rust#125418
rust-lang/rfcs#3635
rust-lang/rfcs#3632

When writing a lib, it's quite common to have some constants that you want your user to set or you provide a default value for it. Generic constants doesn't work for some cases, for example, you might have a static channel defined in the library, but want the channel size customizable by the lib user.

Now the common solution is to use cargo features like:

https://github.com/embassy-rs/trouble/blob/7d72e8d0cf4558bb54f0a1ab43cdb88fabe160a8/host/Cargo.toml#L94-L100

which is not flexible and convenient.

There is also workarounds like: https://github.com/jamesmunns/toml-cfg/ but I hope there's better solution for it.

[sourcebox]

Currently, optimization settings can be only set per crate. This is problematic if you just want to debug a small portion of code or a single module because changing the setting for the whole crate can lead to massive increase in code size making it sometimes not even fit in flash anymore.

In GCC, there's the option to use #pragma GCC optimize in conjunction with #pragma GCC push_options and #pragma GCC pop_options to switch optimization for certain parts of the code.

[rursprung]

as discussed on matrix there are various embedded crates (mainly HALs) which would benefit from having "enum-like" features. e.g. a "chip" feature to select which chip is to be used (rather than currently having mutually-exclusive features which is against the rust/cargo best practices).

the following links were mentioned on matrix:

• https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618
• https://github.com/jamesmunns/toml-cfg

[jonathanpallant]

Turning on support for, eg M Vector Extensions, is not really supported. I put it in the platform documentation and was told it shouldn't go there because it's not stable. So we need somewhere to document unstable platform things, and we need a stable mechanism to opt in to these extra features our processors may (but may not) have.

See also f64 FPU, DSP extensions, etc.

And that's without considering whether precompiled libcore should use them.

[jannic]

Just in case there's some time left, some tickets to look at:

rust-embedded/qemu-exit#32
Likely an easy one: dirbaio, can it be closed?

rust-embedded/svdtools#243
Is this controversial or can it just be merged? (Current merge conflict is only affecting Cargo.toml and easily fixed.)

rust-embedded/discovery#598
Update CI to ubuntu-24.04

rust-embedded/discovery#584
Looks sensible - any mac user present to verify this?

[adamgreig]

Discussion around allowing #[cfg] for asm!() macros rust-lang/rust#140279

[BartMassey]

Amanieu asked me a year ago to file an issue related to this common pattern, but I never got around to it.

use panic_halt as _;

We do this kind of thing a lot in embedded code. However, our crate should be linked against everything listed in Cargo.toml regardless of whether it is used directly by our code — something is stripping out unreferenced crates. Fixing this would mean no useless uses, presumably.

If somebody wants to figure out where and submit this issue, go for it. Otherwise, I'll do it real soon now. After a year. Sigh.