1477: embassy-embedded-hal: Add i2c transaction to I2cDevice r=Dirbaio a=CBJamo
Not sure why this was a todo before, but this seems to be working fine in my limited testing.
Co-authored-by: Caleb Jamison <caleb@hellbender.com>
1457: TL Mbox read and write for stm32wb r=xoviat a=OueslatiGhaith
Hello,
This pull request is related to #1397 and #1401, inspired by #24, built upon the work done in #1405 and #1424, and was tested on an stm32wb55rg.
This pull request aims to add read and write functionality to the TL mailbox for stm32wb microcontrollers
Co-authored-by: goueslati <ghaith.oueslati@habemus.com>
Co-authored-by: xoviat <xoviat@users.noreply.github.com>
1473: Protect default implementations for FirmwareUpdater and BootLoader r=lulf a=rmja
It seems as if the arm compiler can does not care about whether the bootloader symbols are undefined if the default() function is never used. The x64 compiler does care however, so this change ensures that we can instantiate the types from tests.
Co-authored-by: Rasmus Melchior Jacobsen <rmja@laesoe.org>
It seems as if the arm compiler can does not care about whether the bootloader symbols are undefined if the default() function is never used. The x64 compiler does care however, so this change ensures that we can instantiate the types from tests.
1440: rp: Pin fix, improve fifo handling r=Dirbaio a=CBJamo
Went to actually use this code and found two issues:
* The config for the pins got dropped in the shuffle.
* I found that when using more than one ws2812, only the first would get data. I'm pretty sure the data was shifted out before the task got back to push the next word. So now the fifo gets filled, then we wait.
Co-authored-by: Caleb Jamison <caleb@cbjamo.com>
Co-authored-by: Caleb Jamison <caleb@hellbender.com>
1463: Allow for an optional user-defined entry macro when targeting RISC-V r=Dirbaio a=jessebraham
In [esp-hal](https://github.com/esp-rs/esp-hal) we use our own custom runtime crate, [esp-riscv-rt](https://github.com/esp-rs/esp-riscv-rt). This PR adds the ability to optionally specify an entry macro when using `embassy_executor::main`. The following forms are both accepted:
```rust
#[embassy_executor::main] // uses `riscv_rt::entry` by default
async fn main() {}
#[embassy_executor::main(entry = "esp_riscv_rt::entry")]
async fn main() {}
```
I attempted to get this working without needing to quote the entry macro argument, however I was not able to get this working. Based off some reading I did this may not be possible, however I am rather inexperienced with proc macros. Happy to change this if anybody has any insight.
Co-authored-by: Jesse Braham <jesse@beta7.io>
1465: rp: continue clock rework r=Dirbaio a=pennae
vastly reduce the code size of initial clock config (over 700 bytes saved!), at the cost of about 48 bytes of ram used to store the frequencies of all clocks in the system. also stop exporting unstable pac items for clock config, fix a few settings that were out of spec, and add missing features (most notably gpin source information).
Co-authored-by: pennae <github@quasiparticle.net>
gpin clock sources aren't going to be very useful during cold boot and
thus require runtime clock reconfig. once we get there we can use this
for reference. or maybe we can't, only time will tell.
we'll take static ownership of an entire pin (not just a limited
reference), otherwise we cannot at all guarantee that the pin will not
be reused for something else while still in use. in theory we could
limit the liftime of this use, but that would require attaching
lifetimes to ClockConfig (and subsequently the main config), passing
those through init(), and returning an object that undoes the gpin
configuration on drop. that's a lot unnecessary support code while we
don't have runtime clock reconfig.
don't recalculate clock frequencies every time they are asked for. while
this is not very often in practice it does consume a bunch of flash
space that cannot be optimized away, and was pulled in unconditionally
previously. while we technically only need the configured rosc, xosc and
gpin frequencies it is easier to store all frequencies (and much cheaper
at runtime too).
