Prepare the releaseUpdate dependencies version Bump espup version Check that the MSRV hasnt changed: cargo msrv Check SemVer changes with: cargo semver-checks check-release Update Changelog Create the tag and release: git tag vx.y.z && git push --tags Create a new GitHub release: https://github.com/esp-rs/espup/releases

Initial setup Check https://github.com/rust-lang/rust stable branch for the release merge, example: https://github.com/rust-lang/rust/pull/131695 git remote add upstream https://github.com/rust-lang/rust git fetch upstream stable git checkout upstream/stable git submodule update --init to get everything in order Rebase From the stable branch, checkout the new release branch

We should have a new-and-improved version of the book available to correspond with the release of esp-hal@1.0.0 In order to do this, we must first decide what should be in the book, and what should instead be in documentation and/or other resources :)Some ideas from ivmarkov: https://github.com/esp-rs/rust/discussions/235#discussioncomment-10760357 Let's please come up with a game plan for this sooner than later, as this kind of techincal writing always seems to take longer than expected What is our plan with no_std-training?There are a few issues already: https://github.com/esp-rs/no_std-training/issues, we dont mention that we can use stable... BQ: IIRC there was the idea to replace our examples in esp-hal with something more interesting - if we do that we could also add some markdown documents and replace the training?JB: I would still like to do this, but there seems to have been a fair bit of resistance when I have brought it up in the past for whatever reason SM: imo the no_std training is valuable, but might need some love. I see it as the "discovery" book equivalent for us (maybe we should rename it that?)

esp-rs work prioritization A list of all milestone issues (across all projects) is available here: https://github.com/orgs/esp-rs/projects/2. The general priority is as follows esp-halbeta feedback / bug issues should be triaged/resolved, please add relevant issues to the beta.1 milestone Please keep up with reviews in esp-hal (especially for community contributions), they rack up quite quickly if left for too long :D Goes without saying, but no need to work on anything else in esp-hal, the other projects below have higher priority than feature requests or enhancements to the hal After that, I think making some headway on the book milestone is a good idea. These section issues are a bit brief at the moment, but even contributing ideas, talking points or some ideas about the structure are all valuable

The current structure has resulted from organic growth over the years, but cracks are starting to show and it's becoming increasingly difficult to add new functionality in some cases One major issue is the Flasher struct, which has become a bit of a dumping grounds for various functionsThis probably could be split up; how we approach this is still unclear to me There are various cyclic dependencies between modules which should be resolved This makes maintenance and extension more difficult than it needs to be, and is generally just considered bad practice from an architecture viewpoint Some types probably need to be shuffled around a bit, as not everything lives where it probably should We are leaking some types from dependencies which are not 1.0 as well, which needs to be resolved

Beta release plan esp-hal, + esp-* crates releases (see https://hackmd.io/wJL4-5j6QMOqpXVZ-uUl-A#esp-hal) tagging of all packages (for docs purposes)I suggest we name all of them crate-v0.0.0, the current exception to this rule is esp-hal which just has v0.0.0, I think we should change that to be consistent with the rest Run deploy docs on preview Run deploy docs on production, provided above works well Merge the PR that closes https://github.com/esp-rs/esp-generate/issues/128

Triage-Meeting Host Replacement 10.03 Jesse 12.03 Sergio 17.03 Bjoern 19.03 Sergio

For context, please read the relevant issue: https://github.com/esp-rs/esp-hal/issues/2969 Additional issues with the CI label: https://github.com/esp-rs/esp-hal/issues/2080 https://github.com/esp-rs/esp-hal/issues/2440 https://github.com/esp-rs/esp-hal/issues/2971

0.23 Release plan Required PRs https://github.com/esp-rs/esp-hal/pull/2935 https://github.com/esp-rs/esp-hal/pull/2701 https://github.com/esp-rs/esp-hal/pull/2940 (or we just set 1.84 as latest?) https://github.com/esp-rs/esp-hal/pull/2880 Nice to have if they're ready https://github.com/esp-rs/esp-hal/pull/2941 https://github.com/esp-rs/esp-hal/issues/2509

read_bytes should be blocking on all drivers?Should UART's read_bytes return errors? Or, if it should be blocking, should it return why it stopped receiving (error, timeout, buffer filled up, ...?)cc: https://github.com/esp-rs/esp-hal/pull/2935, https://github.com/esp-rs/esp-hal/pull/2882, https://github.com/esp-rs/esp-hal/issues/2807, https://github.com/esp-rs/esp-hal/issues/2730 Possibly marking transaction as unstable: https://github.com/esp-rs/esp-hal/issues/2820#issuecomment-2583021949 https://github.com/esp-rs/esp-hal/issues/1668 As justification for the below points, beta is fairly well-defined (e.g. https://en.wikipedia.org/wiki/Software_release_life_cycle) and we should honour this; labelling a release as beta is sending a message to users, which will set expectations. The important part here is (emphasis mine): A beta phase generally begins when the software is feature-complete but likely to contain several known or unknown bugs.

Rationale While the v3 releases of cargo-espflash and espflash work reasonably well, there are a number of outstanding issues which need resolving, and it is not especially extensible with regards to supporting new functionality/features. With our current efforts to stabilize the HAL I think it's important to provide high-quality tooling along with the stable release when it's ready. This further enhances the developer experience and provides more incentive to use our software. Brainstorming These are possible changes to be made for the new major release. We don't necessarily need to address all points, some will require some further investigation and/or discussion. Experiment with storing chip metadata in a serializable format which can then be used to generate targets automatically, so that we don't need to write any/much additional code to support new devicesThis may not be feasible, however is worth exploring IMO Perhaps we can rework our traits (and/or add more) to make this process simpler, too

GH list of Self Hosted Runners:From the org profile > Settings > Actions > Runners > Standard GitHub-hosted runnersYou need to be admin in the organization to see this list List of runners CI & Services Wiki VM runners BrnoHow to hardcode USB device links You may request SSH access to the VMs to Tomas Sebestik

Community notes Book upgrades Explain concepts and FAQ instead of crate specificsI.e reducing size of Futures, stack overflows etc How to patch crates from main branch for esp-hal etc (all crates should be patched) Vendored builds in esp-idf crates Examples should be more like mini projects, not tests (all in agreement here) STD changes going forward Status marker for community support

Please add any topics you would like to discuss while the team is in Brno together. [x] esp-generate [x] Example extraction tool (?)JB: I think we need to completely rethink our approach to examples. There are too many, I don't think a lot of them are particularly useful, I suspect a number of them have not been updated to appropriately reflect changes in the HAL, and we can probably better organize these e.g. in a similar fashion to ESP-IDF [x] What should we do about espflash? I don't think any of us are particularly interested in further development here, there are a number of issues open, and we are not seeing many/any community contributions This is being used as a library in probe-rs AFAIK, perhaps we can work towards making probe-rs our recommended tool and avoid the headaches that come with application development? Not sure if this is feasible/desirable. At the very least, we probably need a maintenance release of this at some point, especially cargo-espflash which currently requires --locked to install

Including an illustrated collection of what not to do. This document is a work in progress. A word to the reviewer Code review is not easy, and not a quick task. If you feel you've spent more time looking at code than necessary, take your time and look at it some more. There is a difference between things "looking all right" versus things being actually correct. Take your time to understand what changes, why it's being changed, and what the consequences are. It's easier to update a pull request if necessary, than it is to mitigate the fallout of a sneaky bug. Both the PR author and other reviewers can make mistakes, too. Our task is to double-, or even triple-check their work, so being diligent is important. If the PR author responds to one of your concerns saying they don't think it's right, make a small experiment to decide which one of you is correct.

The purpose of this document is to help us decide where to focus our development efforts, while not abandoning projects and leaving the community to fend for themselves. It may make sense to move some libraries into larger repositories, e.g.) many bare-metal libraries could live in esp-hal. Whether or not we want to do this is up for discussion, and how far we will take this will need some debating. There will need to be some discussion with the community about what to do with certain repos, e.g.) the esp-idf-* repos. NOTE: Some repos have been filtered out, generally because they do not contain any Rust. (These columns are referring to the repositories, not the projects)

esp-hal API guidelines Construction / Destruction of drivers Avoid methods like free(self) -> Self instead, the driver should use the PeripheralRef API.See: https://docs.esp-rs.org/esp-hal/esp-hal/0.16.1/esp32c6/esp_hal/peripheral/index.html Add Drop implementations to drivers that reset the peripheral to idle state. (with the exception of GPIO, imo, but we can discuss that) Drivers that consume optional numbers of pins should use the builder pattern to do so (see SPI for example) JB: I would also like to see anything with more advanced configuration use this pattern! We're already doing so for UART, for example

If you have not already, please watch the video I shared on Teamshttps://www.youtube.com/watch?v=PJjmw9TRB7s This is not a definitive guide, but I think it provides at least a very solid foundation to build from Other resources out there too, do some homework :)e.g.) https://google.github.io/eng-practices/review/reviewer/ Remember why we're reviewing code in the first place Code quality is important, but experience/data show that code reviews do not do particularly well in this department, so don't obsess! Design decisions are important!Challenge everything! Come up with alternatives, weigh the pros/cons Understand why decisions were made in the first place

There are quite a few drivers that need serious help, IMO:ADChttps://github.com/esp-rs/esp-hal/issues/326 https://github.com/esp-rs/esp-hal/issues/449 https://github.com/esp-rs/esp-hal/issues/902 https://github.com/esp-rs/esp-hal/issues/1203 DMA https://github.com/esp-rs/esp-hal/issues/489 https://github.com/esp-rs/esp-hal/issues/954 https://github.com/esp-rs/esp-hal/issues/1235

Overview This document describes the self-hosted runners and test infrastructure required for hardware-in-loop testing of esp-hal. Infrastructure We have a number of self-hosted runners with devkits physically attached.These runners are configured at the organization level (ie. esp-rs). See Brno-office-machines-inventory See Self Hosted Runners HackMD note Currently only RISC-V devices are supported (this is a limitation of probe-rs, semihosting and embedded-test)