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).
if rosc really does run at 140MHz in high at div=1 then these values
were not correct and would've exceeded the chip spec. the HIL test
device seems to run fast (150MHz) so they're still not quite correct,
but rosc has high variance anyway so it's probably fine.
exposing pac items kind of undermines the unstable-pac feature. directly
exposing register structure is also pretty inconvenient since the clock
switching code takes care of the src/aux difference in behavior, so a
user needn't really be forced to write down decomposed register values.
the datasheet says that the xosc may be run by feeding a square wave
into the XIN pin of the chip, but requires that the oscillator be set to
pass through XIN in that case. it does not mention how, the xosc
peripheral does not seem to have any config bits that could be set to
this effect, and pico-sdk seems to have no (or at least no special)
handling for this configuration at all. it can thus be assumed to either
be not supported even by the reference sdk or to not need different
handling.
solvers usually output fbdiv directly, using vco_freq to get back to
fbdiv is not all that necessary or useful. both vco_freq and fbdiv have
hidden constraints, but vco_freq is a lot less accurate because the
fbdiv value resulting from the division may be off by almost a full
ref_freq's worth of frequency.
also fixes the usb pll config, which ran the pll vco way out of (below)
spec.
