Merge #668

668: Add minutes for 2023-04-04 r=newAM a=adamgreig



Co-authored-by: Adam Greig <adam@adamgreig.com>

minutes/2023-04-04.md

@@ -0,0 +1,64 @@
+# Embedded Working Group Meeting 2023-04-04
+
+* [Coordination Repository]
+* Meetings: Tuesday 8pm Europe/Berlin time
+* [Join the Chat]
+* Today's date: 2023-04-04
+* [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-04-04
+
+## Attendance
+
+Write your GH username or Matrix handle here!
+
+* adamgreig
+* dirbaio
+* eldruin
+* newAM
+* almindor
+* cr1901
+* datdenkikniet
+* jannic
+
+## Agenda
+
+* Announcements
+    * @adamgreig won't be running meetings for 3 weeks (until 2nd May)
+    * [`defmt-brtt`](https://github.com/datdenkikniet/defmt-brtt) (datdenkikniet)
+* Embedded HAL
+    * New serial Read/ReadUntilIdle trait, buffered/unbuffered
+        * Continued discussion
+        * Perhaps it's fine to only have buffered APIs, but should they have some way to see how many bytes are available / should it be possible to use them without blocking until data is available?
+        * Proposed closing the unbuffered PR (349), plan for only a buffered API, but not sure if that's embedded-io's Read, or something more uart-specific, or what
+    * Update SPI to new transactional API
+        * Merged!
+        * We could consider a closure-based API in the future, but
+          for now the slice transactions is the way to go.
+* svd2rust
+    * Various recent work on ordering derivedFrom fields to support the Keil/Arm SVD tools https://github.com/rust-embedded/svd/pull/220
+
+## Last Week's Minutes
+
+* Announcements
+    * e310x svd2rust version update https://github.com/riscv-rust/e310x/pull/28
+* Embedded HAL
+    * New i2c merged: https://github.com/rust-embedded/embedded-hal/pull/440
+    * SPI new transactional API: https://github.com/rust-embedded/embedded-hal/pull/443
+        * We discussed this at some length
+        * It seems there are still some use cases for the closure-based API that are not met by the slice API
+            * Some chips require CS kept asserted while various things happen eg MAX3421
+            * Some displays might want to read-modify-writeback a lot of data inside a transaction
+            * If the user-provided data needs conversion (eg u16 to u8 with endian swap) this is more efficient inside a closure
+        * But, most use cases are probably fine with the slice API (or even the plain write/transfer APIs)
+        * And the slice API is very compatible with Linux spidev, while the closure one may need hacking if it can work at all
+        * Possibly we start with the slice API and consider adding the closure one alongside later, for drivers that specifically need it
+    * serial Read, ReadUntilIdle: https://github.com/rust-embedded/embedded-hal/pull/349
+        * Discussed the distinction between buffered/unbuffered further.
+        * Should read() always return immediately or can it sometimes block?
+    * embedded-can https://github.com/rust-embedded/embedded-hal/issues/447 
+* Tools
+    * svd2rust unsafe api discussion ongoing https://github.com/rust-embedded/svd2rust/issues/714#issuecomment-1478278195