Merge pull request #757 from rust-embedded/2024-05-14

Add minutes for 2024-05-14

Author: Dirbaio

minutes/2024-05-14.md

@@ -0,0 +1,138 @@
+# Embedded Working Group Meeting 2024-05-14
+
+* [Coordination Repository]
+* Meetings: Tuesday 8pm Europe/Berlin time
+* [Join the Chat]
+* Today's date: 2024-05-14
+* [Nominated issues](https://github.com/search?q=org%3Arust-embedded+label%3Anominated+is%3Aopen&type=Issues)
+* [Discussion topic](https://github.com/rust-embedded/wg/discussions/747)
+* [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/2024-05-14
+
+## Attendance
+
+Write your GH username or Matrix handle here!
+
+* adamgreig
+* dirbaio
+* jamesmunns
+* Adam Hott
+* hdoordt
+* sirhcel
+* nastevens
+* alevy
+* newAM
+* therealprof
+* bartmassey
+* jannic (late)
+
+## Agenda
+
+* Announcements
+    * svd2rust 0.33.3 released
+    * tracking issue to discuss postcard 2.0 https://github.com/jamesmunns/postcard/issues/128
+* RustNL recap
+    * https://hackmd.io/p6bQ0OzqTj-R9ra11LvP8A
+    * Roadmap for WG work
+        * Keep working on supported targets and foundational crates like embedded-hal
+        * Improve documentation, tutorials, examples, libraries to ensure many more
+          people can become embedded Rust developers
+        * Improve visibility and discoverability of our work, especially considering
+          specific target audiences
+        * Coordinate with vendors
+        * Ensure we have a good experience for hobbyists coming from platforms such as Arduino,
+          including GUI-only installation experience
+    * Working group meetings and structure
+        * We'd like to remain part of the Rust project and on the whole they'd like something like that too
+        * There's a proposed "Rust Application Organisation" (name TBC) to collect Rust _users_, which we might also become involved in
+        * We should be involved on the Rust Zulip more to improve communication with Project members
+        * Proposal for a new sub-team who are responsible for directly interacting with the Rust Project and have a weekly meeting on Zulip (maybe not every week, depending on what topics come up)
+    * Use of volatilecell and PAC singletons
+        * We need to stop using vcell, move svd2rust and cortex-m to chiptool-style pointers in structs which generate offsets for register access
+        * Still want to split c-m into PAC/HAL layer (and perhaps -asm)
+        * Concluded to propose removing owned singletons from svd2rust, make this a HAL concern instead
+        * Proposal for new MMIO functionality in Rust itself, e.g. mmio_read/mmio_write on ptr,
+          and in the interim we could emulate this in cortex-m with inline assembly
+        * Also add an mmio_fence function
+    * Rust + Bluetooth
+        * Work in progress on TrouBLE with some tasks assigned
+    * PAC/Arch/Runtime crate interactions
+        * Agreed on previous plan to make cortex-m-pac-interface with interrupt trait so that PACs don't have to depend on arch or runtime crates
+        * Looked at how Risc-V is split (-pac, -peripheral, -, -rt)
+        * Discussed interrupt macro syntax options to be able to separate it from the PACs,
+          current conclusion is something like `#[interrupt(pac::Interrupt::UART0)] fn foo() {}`
+    * Binary data structure representations
+    * Documentation
+        * Discussed a plan (see hackmd link above) for discovery book:
+            * Split and archive the old f3disco and mb1 books
+                * Pros
+                    * Prevents creating new issues for the old books
+                * Cons
+                    * Is there actually a need for maintaining the older books?
+                    * What about just keeping them (along with their issues) "archived" (issues closed) in the same repo?
+                    * In combination with hosting the older books as-is (see below)
+            * Update current book for full mb2
+            * Discussed having a simple BSP that's part of the book (or its own crate) to keep the first examples easy, moving to direct HAL use later in the book
+            * Might be able to obtain funding to pay students to help with some chapters
+            * Need better CI
+        * Also want to create a new FAQ page with common questions
+        * We should check where else users are asking questions, such as Discourse
+    * HAL reference examples
+    * Probe-rs
+        * Lots of things to work on and roadmap items planned, see doc for details
+    * Discussed embedded pain points with Rust project
+    * Future of static mut
+        * We discussed the `grounded` crate
+        * Rust wants to more or less deprecate the use of static mut, it already generates a warning and will
+          be forbidden in the 2024 edition
+        * `grounded` offers some well-documented wrappers for many common use cases
+        * We decided to keep developing/documenting grounded as-is for the immediate time being, with a plan to move it into the wg libs team soon, and potentially see some structs move into Rust itself later
+    * Binary code size discussion
+        * Various code size pain points discussed
+        * RFC opened to add a new flag to std allowing size optimisations
+* Embedded HAL
+* Documentation
+    * Discovery book
+        * Issues [#568](https://github.com/rust-embedded/discovery/issues/568) & [#567](https://github.com/rust-embedded/discovery/issues/567)
+        * Permission to resources team for @hdoordt and @bartmassey?
+            * https://github.com/rust-embedded/wg/pull/756
+        * Keeping the previous books hosted?
+            * Pros
+                * Keeping these variants still easily accessible
+                * Catching unknown links under https://docs.rust-embedded.org/discovery/, tell about the new book and still guide to the older variants
+                * Being friendly and not letting aspiring Rust embedded devs with already some cognitive load on their journey just hit a 404 wall
+            * Cons
+                * Some work for embedded WG
+        * Referencing known-good documentation for architectures not covered in the book like std-sync and std-async (on ESP32)
+            * See for example https://github.com/rust-embedded/discovery/pull/559
+            * Providing some guidance in contrast somewhat somewhat overwhelming _Awesome Embedded Rust_ for beginners
+* Actions-rs deprecated for GitHub Actions
+  * Issue [#754](https://github.com/rust-embedded/wg/issues/754)
+      * Do we need separate issues per-repo, or "just do it"?
+      * Preferences for rust-toolchain versus just rustup?
+      * Anything (checks, dependabot, etc) that should be included/excluded from all repos?
+  * Decided nastevens will go through repos currently on actions-rs and do simple migration
+      * Then use what's learned from this migration to propose CI template if it makes sense
+* risc-v CSR access unsafe or not? https://github.com/rust-embedded/riscv/issues/209
+
+## Last Week's Minutes
+
+* Announcements
+    * embedded-hal-bus 0.2 released with AtomicDevice
+    * Target docs for thumb targets PR underway: https://github.com/rust-lang/rust/pull/124404
+    * @thejpster stepping down from wg and leadership council
+    * next week's meeting is skipped, resuming the week after (on 14th may)
+* Embedded HAL
+    * AtomicDevice use of portable_atomic means build fails on armv6 https://github.com/rust-embedded/embedded-hal/issues/598
+        * add atomic-device feature, enable AtomicDevice if feature is enabled or cfg(target_has_atomic..), add atomic-critical-section and atomic-unsafe-assume-single-core (or portable-atomic-...?) which proxy to p-a and also enable atomic-device, document this, release as 0.3
+* Tooling docs update: https://github.com/CodingInGreen/tooling
+    * what to add?
+* Maintenance of STM32 Discovery Book?
+    * Is our most complete book
+    * Does not seem to be in widespread use anymore
+    * Board has changed version
+    * Two books is a lot
+    * Conclusion: don't worry about the stm32 book, mark it as more clearly archived/read-only/deprecated