473: Replace rustflags with build.rs extra-link-args. r=Dirbaio a=Dirbaio
Rustflags apply to ALL the crates in the graph, while we only need
them for the toplevel crate which is the only one getting linked.
Rustflags are not equal for all crates, this caused cargo to re-build the
same dependency crate multiple times uselessly. After this change, deps
are reused more, making builds faster.
Note that this only applies when sharing the target/ dir for multiple crates
in the repo which is not the default.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
461: nrf: add initial nrf5340 support r=Dirbaio a=Dirbaio
Thanks to `@diondokter's` work on DPPI this was quite easy! :)
TODO:
- [ ] Add config option to enable 128mhz
- [ ] Add config option to unlock APPROTECT automatically.
- [ ] Add a way to boot net (config option or API?)
- [ ] Support WDT (there's WDT0, WDT1. Needs some refactor)
- [ ] Support NVMC
- [ ] Support TEMP
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
Rustflags apply to ALL the crates in the graph, while we only need
them for the toplevel crate which is the only one getting linked.
Rustflags are not equal for all crates, this caused cargo to re-build the
same dependency crate multiple times uselessly. After this change, deps
are reused more, making builds faster.
Note that this only applies when sharing the target/ dir for multiple crates
in the repo which is not the default.
471: Update stm32-data r=Dirbaio a=Dirbaio
Updates to include https://github.com/embassy-rs/stm32-data/pull/98 to check I haven't broken anything.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
467: docs: fix some `cargo doc` warnings r=lulf a=numero-744
There are still 3 warnings (below)
```
Documenting embassy v0.1.0 (embassy)
warning: unresolved link to `channel`
--> src/channel/mpsc.rs:241:22
|
241 | /// [`channel`]: channel
| ^^^^^^^ no item named `channel` in scope
|
= note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
warning: unresolved link to `Task::spawn`
--> src/executor/raw/mod.rs:105:12
|
105 | /// with [`Task::spawn()`], which will fail if it is already spawned.
| ^^^^^^^^^^^^^ no item named `Task` in scope
warning: public documentation for `spawn` links to private item `Executor::spawn`
--> src/executor/raw/mod.rs:156:17
|
156 | /// cause [`Executor::spawn()`] to return the error.
| ^^^^^^^^^^^^^^^^^ this item is private
|
= note: `#[warn(rustdoc::private_intra_doc_links)]` on by default
= note: this link will resolve properly if you pass `--document-private-items`
warning: `embassy` (lib doc) generated 3 warnings
```
Co-authored-by: Côme ALLART <come.allart@etu.emse.fr>
462: Add the `embassy_traits::i2c::WriteIter` trait r=Dirbaio a=ithinuel
This trait makes the parallel with `embedded_hal::i2c::WriteIter`.
It allows to fetch bytes to write from an Iterator rather than requiring an allocation for an array.
It is provided as an extra Trait to avoid breaking existing implementations of `embassy_traits::i2c::I2c`.
Co-authored-by: Wilfried Chauveau <wilfried.chauveau@ithinuel.me>
This trait makes the parallel with `embedded_hal::i2c::WriteIter`.
It allows to fetch bytes to write from an Iterator rather than requiring
an allocation for an array.
It is provided as an extra Trait to avoid breaking existing implementations
of `embassy_traits::i2c::I2c`.
457: nrf91: support running in both S and NS mode. r=Dirbaio a=Dirbaio
- Cargo feature `nrf9160` is now `nrf9160-s` or `nrf9160-ns`
- "fake-PAC" renames everything appropriately so there's no need to spam cfg's everywhere.
With `nrf9160-s` you can now run code without flashing any weird SPM/bootloader. Tested on nrf9160-dk.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
459: Update stm32-data to main r=Dirbaio a=lulf
I'm getting some issue updating to latest embassy rev, trying to sync it with latest stm32-data to see if that helps.
Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com>
437: Initial support for STM32F767ZI. r=Dirbaio a=matoushybl
This PR adds support for the STM32F767ZI, it adds examples and RCC setup.
It is greatly based on the F4 source code and the f7-hal.
This PR is based on the pending PR in stm32-data: https://github.com/embassy-rs/stm32-data/pull/92
I am looking forward to your feedback on improving it and adding support for more peripherals and devices in the F7 family.
Co-authored-by: Matous Hybl <hyblmatous@gmail.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
427: New nrf PPI api (with DPPI support for nRF91 & nRF53) r=Dirbaio a=diondokter
- Added _ppi and _dppi features to distinguish between the new and the old peripheral.
- Removed ConfigurableChannel and added capacity numbers to the channels
- Replaced the PPI api with a new one using the DPPI terminology (publish & subscribe)
- Updated all tasks and event registers for DPPI
My proposal for the new API.
Tested on my nRF52840 and nRF9160.
Biggest changes for nRF52 is that there's no longer a distinction made between fork task and normal task. You now subscribe tasks to a channel and at runtime it is checked whether or not there's still room for another subscription.
Same for events.
There are differences between the PPI and DPPI though:
- With the PPI you have a limited amount of tasks and events per channel, but a task or event can be used on multiple channels at the same time.
- With the DPPI you have an unlimited amount of tasks and events per channel, but every task or event can only be used on 1 channel.
This is all checked at runtime.
Currently you need to track which tasks and events are assigned to a channel in order to unassign them. For the PPI this data is stored centrally in the registers, so it would be easy to create e.g. `clear_all` and `get_subscribed_tasks` functions. But for the DPPI that data is stored decentrally and so would need some manual tracking.
If there are requests for tracking functionality, then it should be able to be made relatively easy. But for now this API is fine I think.
Co-authored-by: Dion Dokter <dion@tweedegolf.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
Moving `new_*` to the version-specific mod allows doing the correct
register writes right there in `new`, without needing abstractions
like `enable_all`/`disable_all`.
