1353: Add empty test binary for riscv r=Dirbaio a=royb3
As discussed with `@Dirbaio,` this empty test binary should cause a build to fail when it is not possible to build or link a riscv binary.
Co-authored-by: Roy Buitenhuis <roy.buitenhuis@technolution.nl>
1352: re-export main_riscv macro as main for riscv arch. r=Dirbaio a=royb3
embassy_executor::main was missing for riscv targets.
Co-authored-by: Roy Buitenhuis <roy.buitenhuis@technolution.nl>
1350: Fix duplicate package name `embassy-stm32h7-examples` r=lulf a=sgoll
This uses the correct package name for the `stm32h5` example.
Fixes#1349
Co-authored-by: Sebastian Goll <goll@hmi-project.com>
1331: Let bootloader partition be u32 r=rmja a=rmja
This is probably controversial but hear me out:)
The idea about changing from usize to u32 is to enable support for 16 bit mcu's with large flash, e.g. MSP430F5529. Its usize is only 16 bit, but its flash is larger than 64k. Hence, to address its entire flash, it needs the flash address space to be u32.
Missing from the PR is `update_len` in the verification methods. There is currently [a different PR](https://github.com/embassy-rs/embassy/pull/1323) that contains changes in those methods, and I will align depending on the merge order of the two.
The general distinction between u32 and usize is:
* If it is a size or address that only ever lives in flash, then it is u32.
* If the offset or size is ever representable in memory, then usize.
Co-authored-by: Rasmus Melchior Jacobsen <rmja@laesoe.org>
1346: fix I2C controller problems after NACK r=Dirbaio a=Juravenator
While tinkering with I2C on a NUCLEO-H723ZG, I noticed that when trying to communicate with a non-existent device you do receive a proper NACK error, but afterwards any future communications with any device no longer works as expected.
The use case is auto-detection of devices, in this case a series of Adafruit 24LC32 I2C EEPROM boards.
On closer inspection with a logic analyzer, I observed that after the NACK, any data bytes sent out by the board to the devices are just zeros. Even though the embassy code specifies the correct data in `set_txdata` in `write_internal`. Something seems to be going wrong with the controller or buffers on the board itself.
Then I noticed what seems to be a logic error in `flush_txdr`, which is called when issuing a NACK.
After flipping the if statement, I2C communications keep working as expected after issuing a NACK.
Co-authored-by: Glenn Dirkx <glenn.dirkx@gmail.com>
1342: feat(rp): add `Wait` impl to `OutputOpenDrain` r=Dirbaio a=TheLostLambda
A while ago `OutputOpenDrain` was made to implement `InputPin`, something that allowed drivers for various one-wire protocols to be written, but it's been lacking a `Wait` implementation — something that's needed to write async versions of these drivers.
This commit also adds `get_level()` to `OutputOpenDrain`, since `is_high()` and `is_low()` were already implemented, but `get_level()` itself was missing.
Co-authored-by: Brooks J Rady <b.j.rady@gmail.com>
A while ago `OutputOpenDrain` was made to implement `InputPin`,
something that allowed drivers for various one-wire protocols to be
written, but it's been lacking a `Wait` implementation — something
that's needed to write async versions of these drivers.
This commit also adds `get_level()` to `OutputOpenDrain`, since
`is_high()` and `is_low()` were already implemented, but `get_level()`
itself was missing.
1330: stm32/pwm: add complementary pwm r=Dirbaio a=xoviat
This implements complementary PWM with dead time on many supported targets. The specific dead-time programming functions are passed through directly to the user, which is a bit ugly but the best compromise I could reach for now.
Co-authored-by: xoviat <xoviat@users.noreply.github.com>
1332: executor: Replace unsound critical sections with atomics r=Dirbaio a=GrantM11235
I couldn't figure out the correct orderings, so I just left them as SeqCst for now.
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
1333: STM32: Adc V1 r=Dirbaio a=GrantM11235
Based on #947
Co-authored-by: Matthew W. Samsonoff <matt.samsonoff@gmail.com>
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
