Stateful prelude
- Dominant language
- Rust
- Stars
- 188
- Forks
- 41
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 12
Description
The prelude is currently stateless. It provides a set of free functions and may be called at any time. Functions that apply on objects with multiple instances take the index of the instance as parameter.
This issue proposes to have a stateful prelude instead. The `main()` function would take the peripherals as parameter:
```rust
fn main(p: Peripherals) {
// ...
}
```
Buttons and other peripherals are then accessed only through this object instance. Methods on objects with multiple instances implicitly get their index through the `self` parameter. Object may also have a state to track and check invariants.
Advantages:
- Objects may enforce well-parenthesized register/unregister calls for listening to repeated events, thanks to their state.
- And more generally, objects may detect reentrancy issues like an event triggering a write while a write was already processing, overwriting the handler of the outer write with the one of the inner write.
- Objects may use buffers to minimize the number of syscalls. For example repeated one byte reads/writes.
Disadvantages:
- The user must manage ownership of the peripherals and split them as necessary. This might be acceptable given that's how `svd2rust` already works.
The initial design could be:
- Add a `stateful` (or better name) feature.
- With `stateful` feature, the `main` function takes an `Api` argument which is a (non-exhaustive?) struct with all enabled API.
- The field structure follows the applet API.
- Fields are Send and Sync (or maybe just Send) and the user needs to use `Arc` (and `Mutex`) if needed.
Contributor guide
Assessment
This issue has not been assessed yet.