# RustWeek 2025 Embedded Unconf

## Attendees

* WG members
* Adam @adamgreig, WG team lead
* Daniel @therealprof, WG team lead
* James @jamesmunns, Rust leadership council (T-l-p), WG resources team
* Bart @bartmassey, WG resources team
* ~~Henk @hdoordt, WG resources team~~
* Christian @sirhcel, WG linux team
* Jan @jannic, WG triage team
* Scott @MabezDev, WG HAL & RISC-V teams, Espressif
* Noah @yatekii, probe-rs
* Dion @diondokter, tweede golf
* Tamme @tdittr, tweede golf
* Tiago @tiagomanczak, Infineon
* Bradley Nelson, Infineon
* Bjoern @bjoernQ, Espressif
* Daniel @bugadani, Espressif, probe-rs
* Juraj @jurajsadel, Espressif
* Kirill @playfulfence, Espressif
* Mathias @mbrossard, Arm
* Wilfried @ithinuel, Arm
* Julius @jgust, Volvo Cars
* Koen @bergzand, Ariel OS
* Kaspar @kaspar030, Ariel OS
* Emmanuel Baccelli @emmanuelsearch, Inria / Ariel OS
* Alexandru @alexandruradovici, Tock OS
* Cliff @cbiffle, Oxide Computer / Hubris
* Wouter @wassasin, Sarif
* Manuel @mhatzl, Ferrous Systems
* Eric @ericseppanen
* Arnav @guptaarnav, Valar Atomics
* Rock @rockboynton, Anduril Industries
* Daniel M @cyrevolt / @orangecms, oreboot / LinuxBoot / Fiedka / Platform System Interface
* Karin @jkarinkl, Ariel OS

## Agenda Items

* WG Membership, structure, & leadership
* **Interested:** AG, TM
* We'd like more members and also volunteers for leadership
* The structure may need to change, especially if we move out of the project
* Possibility for corporate members or only individual?
* WG and the Rust Project
* **Interested:** AG
* Does RustSoc happen, do we move into it, what does that look like, what do we do if RustSoc doesn't happen, how much of our perceived value is linked to being associated with the project?
* Collaboration with industry and other projects
* **Interested:** TD, DM, MB, BN, TM, KS, EB
* What outputs are useful?
* embedded-hal and other shared ecosystem traits? (BN)
* architecture crates?
* training material like discovery book? (TD)
* documentation? (TD)
* tooling like svd2rust? (TD)
* What outputs could exist and be useful? More types of documentation or standardisation? Other tooling? More libraries?
* Advocacy, collaboration, funding
* Documentation
* **Interested:** TD, CM, MB, CLB, JN, DM, NH
* We want to keep updating the discovery book
* Should we have some "prescriptive" documents for how to participate as a vendor/project/...? "Release this PAC", "Release a good SVD", "what a HAL should look like"...? (TD)
* Documentation targetting more experienced embedded developers looking to start with Rust (in theory the Embedded Book)
* Our website / landing pages / showcase / discoverability
* Something like https://tweedegolf.github.io/drive-rs/ ?
* Documentation for integrating Rust into existing projects?
* Technical topics
* **Interested:** DM, WC, CM, BN, JG
* DMA abstractions: how to model DMA buffers, safety of things being written by DMA behind the scenes (JN) (BN) (SM) (RB)
* MMIO abstractions: do we need a new write_mmio/read_mmio? What are the safety conditions, does shared ownership need to be observed, what data races are possible, etc (JN) (CLB)
* static mut topic from last year (DM) (CLB) https://github.com/rust-lang/rust/issues/53639
* WG crate topics:
* **Interested:** TD, BN, WC
* How to introduce new traits to embedded-hal? (TD) (BN)
* svd2rust updates from last year
* cortex-m-pac topic from last year
* Unify our RT crates at all?
* Things we'd like from upstream
* **Interested:** TD, DM, WC
* Compiler support for security extensions (TD, DD, TM, JG, BN)
* Compiler support for PIC on Cortex-M (DD, CLB)
* Post-build scripts (TD, DD, TM, MH)
* Test/coverage documentation (TD, TM, MH)
* Build-std (TD, DD, CLB, SM) - FYI: https://rust-lang.github.io/rust-project-goals/2025h1/build-std.html?highlight=Build-std#build-std. build-std is also an the all-hands agenda on saturday, 12:00, room 14 https://docs.google.com/spreadsheets/d/1G07-f2pwAzEztZMpuxcCW3EWFS1pEX4ShNbsg91Qqjw/edit?gid=630500878#gid=630500878
* Any asm improvements? (DM)
* Further floating point method support in libcore (DD, RB, CLB)
* Support in Cargo for multiple targets in one workspace (RB, TD, DD, CM, WG, TM, JG, MH, KS)
* Better configuration mechanisms (DD, RB, MH, WG, CLB, TM, JG, SM, KS)
* Improved multi-core support (TD, CLB, TM, JG, SM, BN, KS)
* Testing: no-std standard test runner, multiple runner support
* Things upstream might want to discuss
* RustSoc
* Volatile 2.0 (JN)
* Cfg in asm, named registers in asm, target feature gating for asm in thumb platforms (DM, CLB, TM)
* Write-only return places (DD, WG)
* Moving arch intrinsics into std (DD)
* Further ideas
* Support for E-H traits across separately-compiled programmes (CLB, WC, JG)
* Debuggers (also async, WC) (CLB, TD, DD, DM, RB, MH, TM, JG, SM, NH)
* VM firmware and other non-bare-metal embedded - enough interest for a new interest group or team?
* Abstract over log/defmt (TD, CM, DD, MH, RB, WG, TM, JG, NH)

## Schedule

### Friday 16th May

0930-1030: Introductions, planning, scheduling
1030-1300: Session 1: Industry collaboration, WG participation. Feedback from volatile. Things we'd like from upstream.
1330-1430: Lunch
1430-1730: Session 2: Documentation. Breakout for logging unification. Breakout for DMA/MMIO discussion if necessary.
1530-1600: Break
1730-1830: Drinks & depart

Remaining to schedule: Logging. Technical topics.
Breakout: debuggers? support for e-h traits across separately compiled programmes?

### Saturday 17th May

0930-1300: Session 3:
0930-1030: RustSoc meeting at All Hands for those interested
1330-1430: Lunch
1430-1730: Session 4:
1530-1600: Break
1730-1830: Drinks & depart

- HIL testing breakout
- Industry breakout: how to collaborate, what to ask of vendors, what industry finds useful from wg
- Docs breakout: more detailed book outline
- Logging unification if people are interested
- Potential WG structure to allow non-team-affiliated members
- Views on Rust Soc and future of the WG
- Discuss how to get people who know rust to get started in embedded
- Shape of PACs
- Potential new teams:
- Application Processor firmware (e.g. System firmware, VM firmware)
- FPGA / ASICS Integration with Embedded Rust
- Testing team
- DMA recap
- Ways to nicely/safely share data between interrupts in sync code

## Minutes

### Industry collaboration and WG participation

* Build an ecosystem first, then silicon vendors will come
* Tell vendors what they need to do. Have an SVD, have contact details for bug reports for it. Provide a HAL and implement the embedded-hal traits, ideally in pure Rust rather than binding to C. Work with us to add new traits if needed for things we don't have them for. PAC generation tool, we can list options but discourage making new ones.
* Need a single document we actually publish for this. Clarify what parts are bleeding-edge and in flux, and whihc parts are established consensus. List what parts are still being worked on: PAC generation, HAL structure. Be clear which parts are good: Cargo, embedded-hal, ...
* Some vendor PAC generation is different from necessity or because svd2rust doesn't do what they need. Need to keep options for flexibility and different PACs. Perhaps we can standaridse at another level, e.g. traits for PACs.
* svd2rust doesn't meet everyone's needs and not everyone is happy with its design, but now lots of experimentation has happened is it time to harmonise on a single design?
* PAC traits to allow a variety of PACs to exist in a way that's still inter-operable?
* Perhaps a point for industry members to join the team and shape svd2rust and other tooling. Perhaps add a note to the project soliciting contributions and support from users. Perhaps an RFC process to solicit feedback from external users.
* ArielOS have a webinar with ST coming up, so ST are definitely aware of Rust and Embassy. ArielOS are happy to take a message to ST.
* Another point on whether the PAC is the right level for compatibility vs HALs. Perhaps HALs are the better point, but maybe the varying PAC generators cause unnecessary friction.
* James notes there is another silicon vendor who is interested but not publically, so having somewhere to point people at would be useful.
* Perhaps we should be talking to the foundation to set up consortiums so that it's easier to talk to companies in an official capacity. That might be the right level for business-to-business conversations to happen.
* Does svd2rust just need to be better to compete with other PAC generators? We can still have traits to allow competition.
* Perhaps unify with device-driver syntax for describing hardware and generating code. Generate documentation, generate backlinks to the information source.
* Noted that Microsoft are collaborating with various open-source rust embedded efforts and slowly upstreaming things. Impression is that for most standard chips the pieces are all there and the basics are pretty clear.
* We can hopefully push for stabilising build-std and that may help with "bring your own target".

* WG participation:
* Not clear from outside that we need more help or how people would get involved.
* We are mostly on our Matrix room and it's accessible from other circles
* It's hard to find even the Matrix channel. Discoverability is hard.
* Chat is not ideal for people not in European time zones
* The weekly meetings are also not very discoverable.
* Clarify even on the agenda where the meeting takes place.
* Clarify how people can help and what help we need. Maybe the team structure is not helping us right now as it makes it harder for people to join from scratch. Do we allow people to join outside of teams? Can people be in the team but without push access to crates.io etc?
* It would be good to have a roadmap and milestone planning.
* We could use the Zulip for async planning. We have a channel in the rust-lang zulip.

### Feedback from Volatile 2.0 Meeting

* There are now two plans for MMIO: the old read_mmio/write_mmio methods on pointers, or a new plan to fix volatile so that it provides the necessary guarantees. Seems like the latter has more support right now. There was a lot of discussion for how that could work. There wasn't time for a discussion on DMA in the end. There was discussion on synchronisation between atomics and volatile access. Probably these accesses will become both volatile and atomic.
* They would welcome a proposal from us about DMA (so long as it can fit into their models for volatile now). Doesn't sound like it will happen by itself so suggestion is we should try to hammer out some version of that.

### Things we want from upstream

#### Target management

* Specify targets in Cargo.toml outside of .cargo/config.toml?
* Multiuple targets per crate/workspace?
* Target triples getting confused. risc-v triple is probably going to force some of this.
* Tooling doesn't read the cargo config so doesn't know about configured targets
* Oxide looking at adding support for rust-analyser to be able to run discovery command specified in cargo.toml
* Espressif also suffer from workspace feature unification
* cargo metadata table is not stable in cargo.toml which might let us mark features as mutually exclusive etc
* want to run unit tests on host and quickly swap to running the same tests on target, no configuration for default runner
* How can we have tier 1 without host support?
* Noted that many of these desires require changes in Cargo which does not have much bandwidth for big feature work

#### More powerful configuration management

* Discussions are happening about features that take values

#### Multi-core support

* Support for asymmetric multi-core
* What should the standard approach be for starting the second core, loading different firmware images...? Can we come up with a generic model?
* Various groups (rp-rs, arielOS) have a fairly workable model with passing a closure that gets run on the second core
* Harder in asymmetric chips where you need separately compiled binaries

#### Post-build scripts

* Lots of use cases for this
* Combining multiple firmwares for multi-target support
* Could linkers be involved? Wild exists and might be interested in better ways to deal with linker scripts.
* Sign binaries, encrypt them, generate compliance documentation, ...
* Building for multiple targets in one invocation might be too much of a change for Cargo as it stands now. Will Cargo be the thing that survives?
* Discussed maybe using cargo-embed for things like this but it's not the part of the build that they want to be involved with.
* A new cargo command like 'package'? But cargo commands are generally third party add-ons which might make it hard to be sure we have consistent results.
* Should we coordinate on some higher-level tool that embeds or drives cargo?
* Often e.g. build bootloader and application and sign them and package them together. Keep Cargo building the individual firmwares and some higher-level tool perform the packaging.
* Noted that cargo build will build all crates in a workspace, so you can already do multiple builds.
* Noted that wrapping cargo is not ideal from a teaching point-of-view
* Might need to separate the "ease of use for newcomers/hobbyists/students" and larger-scale professional requirements
* xtask exists but isn't very efficient or standardised
* Might want to inject dependencies from build.rs. Do we need Cargo hooks from build.rs?
* Suggestion for moving this forward is to have a central place for people to say what problems they are trying to solve and hopefully work out some common way to start fixing those problems. Maybe it turns out this isn't a Cargo problem but we'll see.

#### Things to go into core that we miss

* Further methods on floats
* Maybe some PRs have already landed, is it a bit better already?

#### Security extensions

* Want somewhere to have a priority list on security extension support we'd like to see stabilised
* This can then link further into upstream issues
* How do we feed those details back to the relevant people upstream?

#### build-std

* Basically what's on nightly already does what we need, it's just not stable
* Used for panic-immediate-abort, size optimisations, fp feature flags, ...

### Debugger chat in breakout room

- Async await trace gathering
- where are the tasks? e.g. Embassy should/would know
- what are tasks waiting on?
- why it's hard
- how we might be able to collaborate
- why async causes the stack to be a tree
- Building things on top of probe-rs as opposed to pushing things into it
- unknown downstream users, APIs may break for them
- e.g. Oxide builds on top of probe-rs
- OpenOCD
- application specific debugger hooks and why probe-rs should probably support them
- how would you query for threads?
- Kernel aware debugging - can we improve it?
- Stack overflow / size debugging - can we improve it?
- linking/building
- metadata in ELF?
- generating image/memory layout
- programmatic linker APIs vs static/generated traditional linker scripts?
- why even ELF? it is a historical artifact, could be any other intermediate format
- dedicated section for debugging in [awesome-embedded-rust](https://github.com/rust-embedded/awesome-embedded-rust)?

### Documentation

Right now we're a confusing thing to come to. Lots of books and not clear what to start with. Website doesn't help.

Could do with a list of missing/outdated documentation that needs work.

Should we run a survey to get more details of who actually needs documentation and what level they are looking for?

#### Discovery book

* The old book covers stm32f3 and microbit v1, which are to be gotten rid of
* The new book is microbit v2 only and is basically ready to go
* New chapters still being added. Missing some interrupts discussion and DMA.
* Then look for an RTIC and Embassy chapter and be done.
* Will make the old book archived today.
* Book sprint was OK but not well attended. Could we do more?
* It seems a popular idea among meeting attendees. Will try and organise some.

#### Nomicon

* Missing a lot of materials
* Start by adding an appendix with missing items and request PRs
* Once enough material accumulats we'll re-edit it together into a full book

#### Other documents

* rust embedded book
* Also not very updated. Should we keep it and update it or should we refocus it inot a single book?
* OS tutorials
* Currently library guidelines exist for normal rust, could we have something like this for embedded rust? it would be a big effort, so who will step up and lead it?
* Policy for new e-h traits. At what point are they "good enough" or cover enough? What lessons were learnt going from 0.2 to 1.0? Document what things we had to change going to 1.0. Similarly policies for async.
* Noted there are details in both the migration guide and issues per-trait explaining why traits were removed.
* Template generation for lots of boards/chips?
* Curate list of training materials
* Industrial showcase? List of companies happily using embedded rust, testimonials, use-cases, number of devices shipped...

#### Website

* Foundation and project people are also interested in some website revamp.
* Our website looks uninviting. Bookshelf is hard to find and use.

#### Templates

* Interest in having some central list of templates for quick-start
* Probably maintained separately yb various groups e.g. embassy, rtic, rp-rs, ...

#### Action items

* Create discussion topic for book sprints
* Deprecate old discovery book

### Docs Outlining & Industry Collab Docs

* Start new documentation topic for industry that want to use embedded rust and what we recommend to them. Check who would like to participate or if there is anything else we should do. Could there be any funding for this too?
* Do we want to also be doing some advocacy? Collect success stories and showcase them?
* James recently made a blog post outlining industrial use of Rust (especially embedded)
* What top-level documents are important?
* Something for chip vendors who want their arch to be supported
* some discussion about the potential liability risks of having a showcase with corporate use-cases.
* Can we also standardise some further document formats for metadata we can use for codegen etc?
* Perhaps a side-cart or extension to SVD scheme to allow additional metadata?
* Discussed how HAL vendors might characterise their offering
* Can we show a level of support? Basic/intermediate/advanced
* Testing of this maybe?
* Some kind of scoring to encourage support?
* How can we actually do this collaboration? Perhaps start a draft tomorrow and then collaborate on it online afterwards.

### Embedonomicon Planning

* Add content loosely and then refactor it together
* Collect talks with best practices or tips and tricks
* Cliff's presentation from RustWeek / its blog entry
* Chrome EC team presentation on tips and tricks for embedded
* Removing all panics
* Check no formatting in release binaries
* Does it contain high-level things and tips-and-tricks or is it the deep stuff?
* Chapters
* Best practices
* Tips and tricks
* Case studies and links to other projects demonstrating certain techniques and large application structure
* Cryptzoology
* DMA
* MMIO
* Our linker scripts
* Singletons
* Typestate programming
* alloc, heapless

### James thoughts for top level docs

* Docs for learners
* By user profile
* Docs for "new to rust, new to embedded"
* Docs for "know rust, new to embedded"
* Docs for "new to rust, know embedded"
* Docs for "know rust, know embedded"
* By another dimension
* I want to learn some embedded rust w/o buying hardware
* I want to buy some well supported hardware
* How do I choose what hardware to buy
* How do I learn async (embedded flavored)?
* By entrypoint
* "How do I go from zero to blinky?"
* "How can I get an overview of what embedded Rust is like?"
* "How do I add support for a chip that I'm interested in?"
* "How do I write a driver for external components im interested in?"
* "How do I structure a complex project"
* By material kind
* "Teaching material"
* Training
* Workshops
* "Reference material"
* general theory
* suggested practices (for HALs, etc.)
* "thinking in async"
* "unsafe practices"
* "Discovery material"
* Listing of drivers
* Listing of HALs
* A way to "browse" what exists already
* Docs for corporate collaboration
* "If you're a silicon vendor"
* How to write idiomatic components
* PAC, HAL, e-hal impl
* Using existing tools to support this
* General suggestions for structuring a HAL
* How to interact with existing community projects
* Find existing projects
* How to provide useful information
* SVDs, register metadata, reusable IP blocks
* Datasheets
* "If you're a component vendor"
* Writing drivers with things like device-driver?
* "If you're a company that is interested in using Rust"
* How to evaluate the state of existing components
* How to find help for training, consulting
* Building/testing (in CI, HIL, etc.)
* Other major entrypoints?
* A better "landing page"?
* Gives some high level info
* Also gives discovery to other docs
* Not overwhelming
* Follow-up calls to action for:
* Companies evaluating usage
* Individual learners
* Silicon vendors
* Explanation of how to find/join/collaborate with embedded-wg?
* What is expected
* What we need help with

### WG restructuring

- Want to allow people to be members without being in a specific team and make it easier to join
- Want to avoid awkward situations where people want to be members but we barely know them and they hvaen't contributed much
- Example from xorg where potential members wrote a short application, if approved they get voting rights
- So require some credible articulation of their interests and involvement in rust embedded
- some membership committee votes to approve
- Noted right now requests to join can be quite a surprise or happen without discussion
- In riot to become a maintainer, existing maintainers propose a maintainer, starting as a junior maintainer with mentors
- Endorsement scheme for new members?
- Can ask recent members what could have been better?
- DE says current WG is too formal
- [CNCF contribution ladder](https://github.com/cncf/project-template/blob/main/CONTRIBUTOR_LADDER.md) as a potential model
- New charter
- Mentorship for new members
- Process for people to progress in maintainership eg CNCF contributoin ladder
- CNCF have other templates for this stuff, https://contribute.cncf.io/maintainers/governance/
- Easy to join membership with defined route through to team membership and maintainership
- Join via a short personal description
- Members are people rather than companies
- Space for corporate participatoin without membership. "Affiliate". Acknowledged on documentation. Entry on showcase page. Send a rep to meetings.
- Need to abide by existing rust project rules
- Worry about capture by corporate team. IETF have rules about this to try and ensure it doesn't happen. So does Rust project. We'd probably look to follow the same thing.
- Rust teams also being asked to make charters.
- What level of company can be alliliated? Consultancies? Single-person companies? Users like automotive companies? Silicon vendors?
- Talked about being accredited by the rust project, eg anually, to make it official. Renews regularly. We define what's accredited. Expires automatically.
- Does the foundation/project require access to repos while accredited so they can archive/delete/become maintainers of last resort?
- they can always replace crates.io releases
- Three levels of company participation:
- 1. List of companies where we can just point at things
- 2. Them officially saying they support embedded rust
- 3. Them officially sending a rep
- Can still have official and community hals that are separate
- Noted that sometimes one company pays for someone to make a hal for another company's chips
- so it's a "supported" hal but by some other company

### Testing breakout recap

- Probe-rs HIL testing setup and new hardware with eurorack platform
- Talked about current industry projects eg Apache Lava
- Lava orchestrates and manages tests on hardware devices
- Flash wear can be an issue so some discussion about running from RAM but that doesn't always work and doesn't test flash
- ArielOS people had some experience from RIOT about distributed HIL testing but the pain of needing remote power cycling, onboard debuggers being varying quality
- IOT-lab has HIL setup for remote board access to various custom/dev boards
- defmt-test/embedded-test which probe-rs is using. flashing everything as one big firmware blob with a test runner vs flashing a whole firmware and probe-rs jumps to embedded tests one at a time and can reset in-btween etc
- currently defmt-test/embedded-test has some macro hacks
- minicov provides llvm coverage information but is too big for some microcontrollers to fit
- Links are posted in rust-embedded rustweek channel in matrix

### Industrial collaboration recap

- Embedded rust from a vendor's perspective
- As a vendor who wants to support embedded rust, what to do first? second? after that?
- provide svd
- have contact point for svd feedback
- ...
- templates, bsps, etc
- Mathias has a photo which he'll write up in more detail
- Based on experience, a suggested embedded rust support flow. Generate PAC -> check you can flash adn execute with probe-rs -> biuld actual HAL
- James wrote a guide in Embassy FAQ that covers similar steps
- Should the WG offer a specific service of a vibe check for a vendor's chips, i.e. summarise the existing community support and community perception of quality of existing resources. Some sort of "please reach out to us first so we can help you get started and avoid mis-steps".
- Could the WG have a technical contact for companies?

### DMA chat recap

- yesterday it was decided volatile should also sequence with atomics (with relaxed ordering)
- today volatile doesn't guarantee access size or instruction choice and isn't well defined
- rust plan to add strong guarantees about volatile so we can rely on it
- dma can be modelled as another thread with shared memory and we use volatile access with fences to synchronise

### Log unification

Problem:
log and defmt are incompatible and both sometimes don't fullfill all requirements people might have.

If there were a way to make one user interface with pluggable encoding and pluggable output machinery, that might be able to solve all our issues.

Solution:
We didn't really find one.

There may be ways to improve on defmt though.
Defmt does a lot of things already that a user might need.
It has pluggable output machinery, but it misses the layer in between.
If defmt could expose the middle part where we still know about the strings and also know things about the string interning and it would allow for a pluggable encoder, people could build their own middle layer that does:
- Log using fmt
- Use the standard defmt encoder
- Use the defmt string interning, but export using their own custom encoder (e.g. to export to XML0)

We should look at the DEFMT internals to see if this part could be opened up and if so we should ask if the DEFMT team would be open to that idea.

### Docs on helping people who know rust to get into embedded

- Who does discovery book target?
- Where do we point experienced Rust people who want to get started with embedded?
- Why not point them at the discovery book and a micro:bit v2
- Just because people don't know about it?
- People with an idea of a sort of thing they want to build and need to find out how to build it
- Current resources focussed on people who take an engineering route
- Discussion further about who we're talking about and who we target with the different books
- Is this a book to come after discovery book? Does it focus more on designing projects, eg sensor selection, pcb design, mcu design...
- Is this a Rust book or just embedded electronics?
- But right now people just go to arduino hardware and then program it in c++/arduino
- Plenty of examples out there for doing projects
- We may need to ask people who are setting out to do this what problems they run into
- Could we add a chapter to discovery with pointers to go forward?
- We have the showcase, should we point people to projects there? or ask showcase projects to add more detail about their experience?
- rust/c++ cardiff meetup had an embedded meetup with bevy people who might be good to ask
- dorkbot might be another example
- User research helps discover things like whether the userbase prefers videos or reading for learning material
- Update final chapter of discovery with some pointers to further material about embedded development?
- links to projects e.g. rmk keyboards
- links to things like kicad, suggested mcus wiht usb/wifi/whatever
- Arduino has a lot of specific examples, relevant to exactly the right hardware, easy to copy-paste
- Do users actually want to learn how things work or just get stuff working?
- not everyone is desperate to write drivers!
- We're talking about reference documentation but do we want more examples?
- Do we want to re-launch the weekly driver initiative? Or something similar?
- Maybe for eg all Adafruit Quiic boards? Could even be collated into one metapackage that provides drivers for all types of board.
- Karin pointed out Diataxis concept with action/cognition and acquisition/applicaiton axes for tutorials/how-to-guides/explanation/reference, we seem to be missing how-to guides more than anything.

Conclusions:
- Tamme will talk to people he actually wants to target and check what they want
- Consider writing some how-to guides
- Further driver dev to work towards good coverage of adafruit quiic
- migrate a-e-r to tamme's driver list