You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Rework hal initialization
* Turn sw interrupt control into a virtual peripheral
* Return a tuple instead of a named struct
* Fix docs
* Remove SystemClockControl
* Move software interrupts under interrupt
* Re-document what's left in system
* Update time docs
* Update sw int docs
* Introduce Config
* Fix tests
* Remove redundant inits
* Doc
* Clean up examples&tests
* Update tests
* Add changelog entry
* Start migration guide
* Restore some convenience-imports
* Remove Config from prelude
Copy file name to clipboardExpand all lines: documentation/CONTRIBUTING.md
+5-3Lines changed: 5 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -84,11 +84,11 @@ By taking these extra steps to test your contributions, you help maintain the hi
84
84
85
85
Ensuring the quality and reliability of `esp-hal` is a shared responsibility, and testing plays a critical role in this process. Our GitHub CI automatically checks the buildability of all examples and drivers within the project. However, automated tests can't catch everything, especially when it comes to the nuanced behavior of hardware interactions. So make sure that the example affected by your change works as expected.
86
86
87
-
Further steps that can (or should) be taken in testing:
87
+
Further steps that can (or should) be taken in testing:
88
88
89
-
* Using [xtask], build examples for the specified chip.
89
+
* Using [xtask], build examples for the specified chip.
90
90
* Build the documentation and run the doctests if they have been modified using the `build-documentation` and `run-doc-test` commands in [xtask].
91
-
* Run the [HIL] tests locally if changes have been made to them.
91
+
* Run the [HIL] tests locally if changes have been made to them.
@@ -122,13 +122,15 @@ This will use `rustfmt` to ensure that all source code is formatted correctly pr
122
122
*[Link your PR] to any relevant issues it addresses.
123
123
*[Allow edits from maintainers] so the branch can be updated for a merge. Once you submit your PR, a Docs team member will review your proposal. We may ask questions or request additional information.
124
124
* Make sure you add an entry with your changes to the [Changelog]. Also make sure that it is in the appropriate section of the document.
125
+
* Make sure you add your changes to the current [migration guide].
125
126
* We may ask for changes to be made before a PR can be merged, either using [suggested changes] or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
126
127
* As you update your PR and apply changes, mark each conversation as [resolved].
127
128
* Resolve merge conflicts if they arise, using resources like [this git tutorial] for help.
128
129
129
130
[Link your PR]: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
130
131
[Allow edits from maintainers]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-forkmember
0 commit comments