805: Preliminary Xtensa support r=Dirbaio a=MabezDev
Based on the work in #804.
I hope non-upstream target support is acceptable :).
Co-authored-by: Scott Mabin <scott@mabez.dev>
- Adds a executor for the Xtensa arch
- Light sleep implemented with assembly, so we don't pull in the
xtensa_lx crates (yet)
- lock behind a nightly feature due to Xtensa asm support not upstream
817: Added a pubsub channel implementation r=lulf a=diondokter
This is similar to Tokio's Broadcast channel, except that it doesn't allocate.
The publishers and subscribers are dynamic. They use an &dyn channel reference because it's really annoying to have to specify the mutex and const generics every time.
Do we need fully generic types as well?
Co-authored-by: Dion Dokter <diondokter@gmail.com>
Co-authored-by: Dion Dokter <dion@tweedegolf.com>
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".
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`.
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.
This commit removes the else branch in TaskStorage::spawn, and returns
explicitly from the if statement's branch, similar to what
TaskPool::spawn does.
This commit contains a suggestion to rename TaskStorage::spawn_allocate.
The motivation for this is when reading through the code I was
expecting something else to happen in this method, due to 'allocate' in
the method name.
The normal `spawn()` methods can be called directly by the user, with arbitrary hand-implemented futures.
We can't enforce they're only called with `async fn` futures. Therefore, make these
require `F: Send`, and add a "private" one only for use in the macro, which can enforce it.
