with the upcoming version of heapless we are able to initialize all internal
queues in const context removing the need for late initialization
this commit also removes the "nightly" feature because all the optimization
provided by it are now enabled by default
192: removes the maybe_uninit feature gate r=japaric a=japaric
and stop newtyping `core::mem::MaybeUninit`
this also fixes CI on nightly
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
189: write generated code to disk for easier inspection r=japaric a=japaric
now that the generated code is actually readable let's make it easier to access
this commit also documents how to inspect the generated code via
`rtfm-expansion.rs` and `cargo-expand`
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
191: generate resource proxies only when needed r=japaric a=japaric
only `static mut` resources need proxies
just a codegen optimization
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
175: document internals r=japaric a=japaric
note that this assumes that RFC #155 has been implemented
[Rendered text](https://japaric.github.io/rtfm5/book/en/internals.html)
Do not merge this before PR #176
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
now that the generated code is actually readable let's make it easier to access
this commit also documents how to inspect the generated code via
`rtfm-expansion.rs` and `cargo-expand`
176: implement RFCs 147 and 155, fix#141, etc. r=japaric a=japaric
This PR:
- Implements RFC 147: "all functions must be safe"
- Implements RFC 155: "explicit Context parameter"
- Implements the pending breaking change #141: reject assign syntax in `init`
(which was used to initialize late resources)
- Refactors code generation to make it more readable -- there are no more random
identifiers in the output -- and align it with the book description of RTFM
internals (see PR #175).
- Makes the framework hard depend on `core::mem::MaybeUninit` and thus will
require nightly until that API is stabilized.
- Fixes a ceiling analysis bug where the priority of the system timer was not
considered in the analysis (TODO backport this into the v0.4.x branch).
- Shrinks the size of all the internal queues by turning `AtomicUsize` indices
into `AtomicU8`s.
- Removes the integration with `owned_singleton`.
closes#141closes#147closes#155
Additionally:
- This changes CI to push v0.5.x docs to
https://japaric.github.io/rtfm5/book/en/ -- we need to do this because our
official docs are hosted on https://japaric.github.io/cortex-m-rtfm and we
need to keep them on v0.4.x until we release v0.5.0
- I propose that we use the master branch to develop the upcoming v0.5.0.
- I have created a branch v0.4.x for backports; new v0.4.x releases will come
from that branch.
r? @korken89 @texitoi, sorry for doing all the impl work in a single commit --
I know that makes things harder to review for you.
Suggestions for compile-pass and compile-fail tests are welcome
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
This commit:
- Implements RFC 147: "all functions must be safe"
- Implements RFC 155: "explicit Context parameter"
- Implements the pending breaking change #141: reject assign syntax in `init`
(which was used to initialize late resources)
- Refactors code generation to make it more readable -- there are no more random
identifiers in the output -- and align it with the book description of RTFM
internals.
- Makes the framework hard depend on `core::mem::MaybeUninit` and thus will
require nightly until that API is stabilized.
- Fixes a ceiling analysis bug where the priority of the system timer was not
considered in the analysis.
- Shrinks the size of all the internal queues by turning `AtomicUsize` indices
into `AtomicU8`s.
- Removes the integration with `owned_singleton`.
170: check task priority at compile time r=TeXitoi a=japaric
before we were checking the priority at runtime. The compile time error message
when the priority is too high is kind of awful though.
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
158: implement RFC #128: #[interrupt(binds = ..)] r=korken89 a=japaric
closes#128
r? @korken89 or @TeXitoi
suggestions for tests are welcome! (2 of the 3 tests I added hit bugs in my implementation)
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
