# Embedded Working Group Meeting 2023-12-05

* [Coordination Repository]
* Meetings: Tuesday 8pm Europe/Berlin time
* [Join the Chat]
* Today's date: 2023-12-05
* [Nominated issues](https://github.com/search?q=org%3Arust-embedded+label%3Anominated+is%3Aopen&type=Issues)
* [IRC logs]

[Coordination Repository]: https://github.com/rust-embedded/wg
[Join the Chat]: https://matrix.to/#/#rust-embedded:matrix.org
[IRC logs]: https://libera.irclog.whitequark.org/rust-embedded/2023-12-05

## Attendance

Write your GH username or Matrix handle here!

* adamgreig
* dirbaio
* greengenie
* newAM
* mabez
* emilgardis
* cr1901

## Agenda

* Announcements
* call for blog posts https://github.com/rust-embedded/wg/issues/720
* embedded-hal 1.0.0-rc.2 released
* svdtools 0.3.6 released
* svd2rust 0.31.2 released
* Embedded HAL
* Rename DelayNS to Delay? https://github.com/rust-embedded/embedded-hal/issues/541
* Discussed this in depth, still not really clear what the best result is, so probably won't rename
* embedded-hal-mock to rewg or r-e-c?
* If HAL team members are keen on this they can, but it doesn't seem like there's much interest atm
* cortex-m-rt extra section example soundness https://github.com/rust-embedded/cortex-m/issues/498
* cargo-binutils release?
* Yes, when CI failures are resolved
* C-m-pac-interface: rename, test
* mutex-trait: awaiting deprecation rfc
* book: tooling page updates
* bors: ops docs
* rustc targets: awaiting feedback

## Last Week's Minutes

* Announcements
* svd 0.14.5
* svd2rust 0.31.1 (big syntax-breaking change: all accessors are now methods, not fields)
* call for blog posts https://github.com/rust-embedded/wg/issues/720
* Embedded HAL
* Counting down to release on Dec 28th
* Triage new issues?
* set rust-version to msrv https://github.com/rust-embedded/embedded-hal/pull/490
* merge https://github.com/rust-embedded/embedded-hal/pull/531
* merge https://github.com/rust-embedded/embedded-hal/pull/534
* maybe undo before 1.0 release
* discussed recently opened issues
* can't use core Duration for delay, because it's big and requires more operations to perform arithmetic; we don't want to impose that on all end-users and can't let users pick because it's the driver that chooses what trait to use; we hope to one day have a better answer but for now we're punting on it
* should rename get_max_duty_cycle, will do that
* can't unify spi traits as they have different semantics
* spi delay granularity was a more involved discussion
* it seems like drivers using delay at the start/end of a transaction is not the best API, plus we didn't want to support ns-level delays because on linux they'll be rounded up to 1us
* instead it should be "configuration", e.g. something the user sets up, alongside spi clock and mode etc
* perhaps in the future we'll have SpiDeviceWithConfig that takes a config for each transaction that sets spi mode, clock speed, etc
* or some more SpiBus sharing impls that can be configured to apply a different mode for each SpiDevice
* however, this led to talking about the DelayUs trait maybe supporting ns
* which perhaps it should do
* in which case we might as well add DelayNs to SPI operation too, and it will round up, and that's perhaps better than not having it at all
* we still discourage wrapping transactions in ns delays and prefer it be configuration, but we don't have ways to make it configuration yet, so perhaps for now drivers can do that
* so the proposal is to rename DelayUs (SimpleDelay/DelayNs/???), add delay_ns, then add delay_ns to Operation too, but document the limitations
* cortex-m-rt extra section example soundness https://github.com/rust-embedded/cortex-m/issues/498
* cargo-binutils release?
* C-m-pac-interface: rename, test
* mutex-trait: awaiting deprecation rfc
* book: tooling page updates
* bors: ops docs
* rustc targets: awaiting feedback