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`.
- Scary pointer math is now contained in the tasks and events
- ppi now sets the tasks and events immediately and the struct is now zero-sized
- StaticToOne is renamed to ZeroToOne
- Used DPPI tasks and events now panic when enabled twice
- 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
456: Fix L4 clock setup for MSI and PLL to allow RNG operation r=Dirbaio a=lulf
Example is tested on STM32L475VG.
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
448: Dummy pin implementation for Saadc internal vdd sampling r=Dirbaio a=jacobrosenthal
For instance, for reading the battery input voltage on the nrf
Api ends up looking like
`let channel_config = saadc::ChannelConfig::single_ended(saadc::VddInput::default());`
I ~haven't confirmed a sane reading yet~, but this compiles so is ready for bikeshedding
Update: It looks like Ive got sane readings
Co-authored-by: Jacob Rosenthal <jacobrosenthal@gmail.com>
