Agenda for 2020-01-14 meeting

[therealprof]

8-9 PM CET (Berlin time) on #rust-embedded:matrix.org

Public Google calendar that includes these weekly meetings

Agenda

• cortex-m exposes unsafe cache invalidation operations as safe "Invalidate Cache" operation is unsafe cortex-m#188
• The road to 1.0:
  • Proposal to reshape svd2rust generated code: Move generic.rs contents to other crate svd2rust#427
  • Change PAC API exposed by svd2rust to reduce chaining (and formatting woes)
  • Change the way we manage embedded-hal (aka gettting rid of unproven feature flag): [RFC] Changing the way we handle addition/changes to the traits embedded-hal#163
  • Clarify / Document / Redesign the Peripherals::{take, steal} API cortex-m#186
  • https://github.com/rust-embedded/cortex-m-rt/issues/237
• Transfer https://github.com/japaric/msp430-quickstart to rust-embedded?

---

This meeting is open for anyone to attend. If you'd like to bring up any issue / topic related to embedded Rust leave a comment in this issue so we can add it to the agenda.

[jonas-schievink]

We can also discuss rust-embedded/cortex-m#186 and https://github.com/rust-embedded/cortex-m-rt/issues/237 if we have time (they're also part of the road to 1.0).

[jonas-schievink]

Speaking of changing the svd2rust generated code, I was thinking of changing the API of the register writers so that they make use of traits instead of endlessly chaining fields and values as method calls. So something like .field().set_bit().field2().variant(Field2::Yes) would become .field(true).field2(Field2::Yes).

This makes the written code look somewhat cleaner IMO, but the real motivation is unblocking #289. Rustfmt makes the method-chaining-based API look very unreadable since it puts each method call in its own line (#289 (comment)).

[therealprof]

@jonas-schievink Updated accordingly. Feel free to update the issue yourself.

[thejpster]

Although of course you don't have to chain them.

w.field().set_bit();
w.field().baud(19200);

I agree that w.field(true) is nicer though. Maybe adding w.set_field(true) is more backwards compatible.

[almindor]

I might be wrong but isn't w.set_bit() constant (compile time) while w.set_bit(true) makes it a runtime expense?

My understanding was that that's the reason why things like Iterator::rev() don't have a param.

[jonas-schievink]

No, both are entirely up to the optimizer. svd2rust marks all of those small functions #[inline(always)] to help with that, but that is also just a (strong) hint to the compiler. In practice both should always be optimized out though.

[hannobraun]

Speaking of changing the svd2rust generated code, I was thinking of changing the API of the register writers so that they make use of traits instead of endlessly chaining fields and values as method calls. So something like .field().set_bit().field2().variant(Field2::Yes) would become .field(true).field2(Field2::Yes).

I don't currently have a strong opinion, but I'd like to note that the proposed style requires the user to import the parameter types, which can be a hassle.

(I just realize what I said doesn't apply to the example as shown, but I believe it's still valid in general, unless I misunderstand the proposal.)

[jonas-schievink]

@hannobraun That's a good point actually! I think it does match other Rust builder patterns well though.

There might also be a tradeoff regarding compile times here. Do the methods compile faster, or the trait-based approach?

[almindor]

The more I think about this the more I think we should keep it as-is. Changing functional well understood code to workaround a formatter issue seems backwards.