Meeting 2024-05-21

[jamesmunns]

This is the agenda for the meeting today. Please feel free to add items you'd like to add as comments here.

[Ben-PH]

I would like to discuss the possibility/logistics/plans/etc around adding some time-oriented traits. rust-embedded/embedded-hal#602 is something I started work on today, and would like to get a read on how others feel obout the initiative.

[jamesmunns]

Lots of discussion, recommendation was to:

• get embedded-time and/or fugit maintained (or a fork that is maintained)
• Write an RFC for inclusion of traits in embedded-hal, particularly discussing design tradeoffs for app, HAL, and driver users
• Discuss in the RFC what does/doesn't make sense, follow up on any feedback, get consensus (or not).

[Ben-PH]

I also caught on that such a project sheuld be a rust-embedded/emdedded-time of some sort.

[Ben-PH]

• At a cursory glance, fugit is already adequately maintained. esp-hal is a well resourced project, and they depend on fugit for their time-tracking implementations
• embedded-time certainly needs revitalisation of some sort. I'm not aware of the context of this projects status, so can't give much comment there. I'll follow up when I have more to add.
• I've put in a significant, and perhaps controversial PR which (minor) version bumps fugit, and migrates const genericts to typenums. I don't expect this to go through, at least not without extensive engagement, but the story of its acceptance/rejection will provide context for the broader ecosystem.
• I start putting together the RFC today.

[Ben-PH]

RFC is up: #762

[sourcebox]

rust-embedded-community:

• what's missing for a 0.4 release of usb-device? There's an important fix for large config descriptors.
• can this be merged? Adding TRANSFER.md instructions for transferring to the REC rust-embedded-community/meta#24

[ryan-summers]

Hi @sourcebox, I primarily handle usb-device. There's nothing blocking a 0.4 release except for the lengthy time it takes to propogate downstream into dependant crates. Because of that, I was holding off for a bit to see if anyone else had breaking API changes they wanted to propose before I released. I haven't seen any though, so I'll look into a release shortly.

[jamesmunns]

cortex-m-rt v0.7.4 yank and v0.7.5 release:

• Add link_section = ".HardFault.user" to _HardFault cortex-m#535
• Prepare for cortex-m-rt 0.7.5 cortex-m#533

We also might need to merge this to fix CI first:

• CI: select probe for on-target test cortex-m#534

[jamesmunns]

dion:

Basically, the macros crate was updated but not released and the updated cmrt crate still depended on the old macros version. This caused the hardfault handler to give an unsound exception frame argument.

If you use the exception frame, the cpu would hardfault again, which locks up the cpu

[jamesmunns]

jannic:

And the missing link_section will cause a linker error for non-trivial examples if the trampoline is enabled.

[jamesmunns]

Outcome: get the @rust-embedded/cortex-m team to review and merge these PRs, release as soon as we are able to.

[BartMassey]

Short update on Discovery Book plans and status:

• As discussed previously, the Discovery Book needs some love.
• We discussed this pretty extensively at RustNL. There was a reasonable consensus there. There are notes from that around.
• I'm behind as usual. I'm writing an RFC for the initial phase as we speak. I'll get it posted ASAP and we can discuss next week.
• I have larger documentation plans in the works. Help will be wanted soon.

[jamesmunns]

Link to RFC: #759