It currently contains whoever was first to write some code for the crate,
even if many more people have contributed to it later.
The field is "sort of" deprecated, it was made optional recently:
https://rust-lang.github.io/rfcs/3052-optional-authors-field.html
Due the the reasons listed there I believe removing it is better than
setting it to generic fluff like "The Embassy contributors".
813: Document remaining public APIs in embassy crate r=lulf a=lulf
This also includes the README.md in the toplevel crate documentation, fixing a few formatting issues with it as well.
Please review the mutex in detail in case I've misunderstood/missed a few things there.
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
814: Extract setting of lora modulation params r=lulf a=danbev
This commit suggests extracting the lora modulation parameters into a
separate function which can then be called from both the do_tx, and
the do_rx functions.
Co-authored-by: Daniel Bevenius <daniel.bevenius@gmail.com>
This commit suggests extracting the lora modulation parameters into a
separate function which can then be called from both the do_tx, and
the do_rx functions.
811: Sync subghz peripheral support with stm32wlxx-hal r=lulf a=lulf
* A few more registers exposed
* Fix for "sleeping"
* Updating comments
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
806: Add embassy-cortex-m crate. r=Dirbaio a=Dirbaio
- Move Interrupt and InterruptExecutor from `embassy` to `embassy-cortex-m`.
- Move Unborrow from `embassy` to `embassy-hal-common` (nothing in `embassy` requires it anymore)
- Move PeripheralMutex from `embassy-hal-common` to `embassy-cortex-m`.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
- Move Interrupt and InterruptExecutor from `embassy` to `embassy-cortex-m`.
- Move Unborrow from `embassy` to `embassy-hal-common` (nothing in `embassy` requires it anymore)
- Move PeripheralMutex from `embassy-hal-common` to `embassy-cortex-m`.
807: Rename channel to mpmc r=huntc a=huntc
I've renamed the channel module for the MPMC as `mpmc`. There was a previous debate about this, but I feel that the strategy here avoids importing `channel::channel`. The change leaves `signal::Signal`, but I think that's ok. It is all a bit subjective of course. The bottom line for me is that I really like the term `mpmc` - it means something to me and aligns with broader naming e.g. in Tokio.
Co-authored-by: huntc <huntchr@gmail.com>
I've renamed the channel module for the MPMC as mpmc. There was a previous debate about this, but I feel that the strategy here avoids importing `channel::channel`. The change leaves `signal::Signal`, but I think that's ok. It is all a bit subjective of course. The bottom line for me is that I really like the term mpmc - it means something to me and aligns with broader naming e.g. in Tokio.
